Scrum Won’t Always Work
June 7, 2010 3 Comments
Well, this is my fourth refactoring of this post. This was supposed to be a quick one! I fully intended on this post explaining why Scrum will always work. Simple! But, as I thought through this, and kept rewriting my post, I’ve completely changed my tune.
What does it mean for Scrum to “work”? I’m going to define “working” as “delivering more to your customers with higher quality than you did before and continuously getting better”.
Does Scrum always work? In my opinion, no. It depends on the type of team that is being introduced to Scrum whether nor not it will work.
The Team that Rocks
If you have a team that is consistently delivering value, is a cross-functional “team” and not a group of individuals, is continuously improving and has a good, productive relationship with their customers where the customers define what they want and collaborate with the team, then Scrum may set them back. I believe that the additional overhead in the form of sprint reviews, retrospectives, sprint and release planning, and daily stand-ups that Scrum adds may make an already high performing team less productive. The team, in some form, is already doing something that produces the same results as these activities. For these types of teams to improve, Kanban is likely be more appropriate.
The Team that Does Not Rock
I really wanted to title this “The Team that Sucks”, but I thought that would be too offensive. Anyway…Given a team that is not consistently delivering value, is not a real “team”, or has a bad relationship with their customers, I believe Scrum will always work. The team will always be better than it was before. Typically these teams have no process (even though they think they do), so anything that brings discipline and communication will allow the team to improve. I have never, ever seen this to not be the case. I admit that at times the improvement is small, but it is an improvement nonetheless. Of course one thing that’s crucial is to have a strong, experienced coach.
As far as the roles introduced by Scrum, you will have a hard time convincing me that there are times when a product owner role is not needed. I’d have to say that the #1 problem I see in “troubled” teams is the fact that they have no idea what to work on next. What do they do in this case? They start guessing. Oh, and they never really know when they are “Done”. If I do nothing else but involve a strong product owner, that alone typically propels the team forward.
As the team matures, however, they will inspect and adapt (the essence of Scrum). Many “advanced” teams may be considered by Scrum-ists to be doing “Scrum-but”, or maybe even not doing Scrum at all, since they have adapted to be the most productive and efficient they can be. Which helps verify that Scrum will not always work.
What do you think? Will Scrum ALWAYS work?
About Andre Simones
The Lean Agile Guy Blog 
You presented a great observation of the people factor in software development. Yes, I agree, if you have a ‘professional’ team with good intentions and that works well together and with the client then Scrum is not needed per se. There might be a bit of risk that project progress, issues, and status could be a bit unclear to the outsiders.
And I also agree that for a team getting together the first time, per se again, and might need direction, then Scrum (with a good Product owner) is the way to go. But to me, there are other benefits of Scrum over other methodologies in that work would not be done unless it is on the post-it notes and from the stories list. This controls gold-plating and hopefully avoids developing things that are not needed out of the sight and approval of the product owner and even the rest of the team. Not to mention that the status of the project is there on the wall.
One final note, and maybe this a blasphemy coming from someone who also a PMP, but the PMBOK is mainly written for the construction and manufacturing industries, and for big bureaucracies like the Government / DoD, and less for software development in the private sector. As you said in a previous posting on your blog, there are things that can be learned from the PMBOK for software development.
The reason I mentioned that is to draw contrast between a line of thinking that one rigid process will make anyone do well, and another that says adjust to the people and challenge you have to get the best results.
The Agile principles and the Scrum methodology are based on the issues and experiences encountered by us humans trying to translate business requirements into code that should work as the business side believes it should.
So, my answer to your question, yes it “almost” always works, because it values the right elements in the software development experience.
My answer would be: yes, because Scrum is not so much about Scrum itself but about fundamental aspects of teamwork and software engineering. However, I don’t know if Scrum would work for a team that “rocks” as you described it as I didn’t encounter such a perfect team. 🙂
Implementing Scrum leads to different challenges that depend on the maturity of the team. It works for good teams which want to get better and which are open and mature enough to reflect their own work and their believes (uncovering hidden problems may be challenging enough). Even such teams will discover things that can be improved.
For cowboy teams, most likely implementing _any_ structured process would do the job and help to make improvements. However, to me, Scrum as a starting point has some advantages. First of all, it easy and small enough to understand the basic structures and to get started. After that, it puts focus on continuously reflecting what the team is doing rather than on just following the initial template. It will make tons of problems visible, maybe even outside the team’s range. It will question believes and old habits. All of this will probably come out of the team and not from an external stakeholder which can make it even more painful.
For me, Scrum is a toolkit. If you put it in the hands of inexperienced teams, better give them a good coach as a helping hand. If you put it in the hands of experienced teams, also give them an excellent coach as helping hand. But by the end of the day, it is just a method. If a good teams uses something that does the job, why should you touch on it at all?
You bring up very good points. Another angle that I didn’t address is the one where the culture is so anti-collaboration and empowerment, that everyone completely rebels. It doesn’t matter in these teams if there is buy in from the top. The culture of power and command and control is so engrained in the culture , it just won’t work…at least until the culture changes. Of course nothing would work in that case that requires self organizing teams, a focus on value and not artifacts, etc.
So, I still stand by my answer of: NO. However I’m also including the very dysfunctional team, along with the team that rocks.