You implemented Scrum, told project managers that they are now scrum masters, had the all-hands meeting where announced that you are agile now, wrote that you are Agile on your website, your sales managers say agile not less than 1 time in a minute when they talk to the customer, but… still something doesn’t work? You feel yourself like painting the wall white colour but still can see the black underneath? Do you recognize your company? I do) I feel like everyone are just “playing” agile, they do not “live” it.
Remember Agile manifesto? ‘The best architectures, requirements, and designs emerge from self-organizing teams’. But why self-organizing teams? How to build them? How do they emerge?
When I say “self-organizing teams” top managers usually think ‘teams which need no management’, ‘magic teams which work twice as much’. They behave as if we can just hire 10 nice people, put them in one room and tell them “And now you have to self-organize.’ We talk a lot about such teams, but rarely can we assemble one. Some of my colleagues even say that it is a luxury to have such teams and we just can’t afford them.
I tried to collect all my thoughts on the self-organizing teams in this post.
Recently I came across the wonderful TED talk by Simon Sinek and his speech was like “I was thinking about the same thing!” to me. But he was brilliant summarizing it. It works for any company. We are not Apple, we are not selling computers, we sell services – software development services. But it works for our company too! I spent a lot of time talking to the top managers and hr department about “why”, but now I even have a respected source to mention and a great illustration to it. So I spent some time and went through exercise – how our company can use this.
When we talk about the development process in outsourcing with my colleagues we usually “start” project with development phase: “So, we got that project and started with the team our sprint 1”. It is the most often phrase you can hear about the kick-off of the project. In the books about scrum you can find a lot about sprints, but so few about sprint 0 and preparation to the development. They start with “Ok, we have a list of features and we need to estimate them and get a backlog”. But where from we get this list of features? We start with design and then hang this design to the developers? Of course, not. We need a good Sprint 0 with a team to be able to start development. And then I discovered that we even need Sprint -1, where we go through the analysis of the project idea.
I just want to share my practical experience, which suits for the outsourcing software development company, that wants to deliver better product-oriented service. I am surprised how far from that we can be in some of our big outsourcing leaders.
I became much lazier during the last couple of years – I need to hear a good reason to start doing something. The same when it comes to work – “why?” became one of my favourite questions. I discovered how many things are done without the reason. Ask “Why do we need this new type of report?” and then repeat the question unless you get deep to the real reason. When you finally get to smth the like “Because everyone does it!” – you can show the maximum understanding of the problem on your face while leaving the room and going to the kitchen to prepare a cup of coffee and get back to reading Reddit. Try and you’ll be surprised too.
Decided to create this post as I’ve heard this question many times during the last 3 weeks. Several people asked that during the cspo training; clients asked 2 times; my boss and my colleagues could not omit this question too(3 times in total). So I want to share some of my thoughts on this topic.
Let’s imagine a scrum team, which is working on a Product. We have a Scrum master – a nice guy – and a Product owner, who has a lot of great ideas and drives the product on. The team works hard every sprint (yes, they play tennis and drink coffee several times a day. And… oh, hell… they even read facebook and watch cat videos during the working hours. So, just an average team). And one day their stakeholder/big boss comes and asks Scrum Master, “Ok, I see the team is working. You have a scrum master, a product owner… But we have a release planned in 2 months. So, tell me, who is responsible for the delivery? Who is responsible for the release being shipped on time?”
Once (ok, let’s be honest, not just once) I was thinking, “Why not to get rid of estimations?”. I heard a lot from the developers in our company that they hate estimating. That is usually a very painful process for a project manager, too. Not only because of the process itself, but because of what happens afterwards. If you worked on more than one project, you definitely know that the estimation your team created won’t be ok for business people. They certainly know that this feature is very easy and that story can be done in a day… Or, “My colleague – he is a developer himself – thinks this can be done in a week!”. They all need hours, exact numbers and deadlines. Team wishes not to provide that.
Once you start working with the team that is really great, you stop thinking about the things that make them great – their greatness just exists and you “feel” it. But “feel” doesn’t work for me – I really need to describe, classify, plan and predict. So, let’s try to describe the features of a great team, so it would help us breed more great teams. Have you ever been a part of great team? Or worked with one? Please share your experience.
What makes the difference:
If you are a project manager you definitely have ever told your colleagues “I hate these reports! Why do they require those stupid report for every tracked hour? I spend several hours to create it!” You have a weekly call with the customer on the status and have to prepare for it whole the day? You hate Mondays, not only because it is the hardest day of the working week but also because report call? You have to explain each hour spent on the project? It rings the bell? If yes, we are on the same side.
Several months ago I joined the new for me project team. They have been working on this product for more than a year. You know what it means for the mobile project – we have a tons of code created) So, one of the most severe issues guys mentioned is the crappy code – developers told me that during the first retrospective we had. My first reaction was – “So why do you create this crappy code?”. But the answer was very easy for them – “We inherited that code from the previous team, they created all this awful things!”.