Authored by Shawn Peterson
I have read numerous blog posts over the past year around the topic of why scrum is outdated, and no longer a valuable option for Agile teams. I fully understand how scrum can go wrong – I also have been in the endless unproductive planning meetings, retrospectives and standups all because “scrum requires these meetings.” However, just because it can go wrong, doesn’t mean it has no value.
Those of us who have been in the Agile world for awhile often started with scrum. We went through the ceremonies, learned firsthand what worked and what didn’t. Those still in the Agile world are the ones that got back up from failures, figured out what to change and kept moving. Therein lies the value in scrum – it provides a framework – a set of rails to start out on and learn from.
So the question comes up: if so many have already used those rails, had those failures and learned those lessons, why do we still need scrum? Many recent bloggers have stated that it is time to throw out scrum because we have learned all we can. That is a rather privileged point of view; there are still situations where Scum is a powerful tool and should be considered as a methodology.
Team with no Agile experience
There are many teams who have had no practical exposure to Agile, but decide to give it a try. Often these teams are trying an Agile approach in spite of a culture that promotes waterfall.
In these environments, money is not likely to be forthcoming to hire coaches, trainers and veterans to help the transition, so they turn to scrum. They start with all the ceremonies put forth, and if they decide to push through the failures, then they often find the right combination of sprint length (or lack of sprints), ceremonies and check-ins. This won’t look the same as it would if a seasoned coach were to help, and would not have succeeded without those initial rails.
Team that is not self-organizing
Teams do not stay the same forever. People move to other positions, or switch companies and new developers come in to take their place. With these natural changes, a seasoned developer can find themselves on a team with many junior level developers. When this happens, there can be problems with the team’s ability to self-organize.
Here you have two options:
- The seasoned developer dictates how he or she prefers the team to work. The team is expected to work in the way the seasoned developer found was best for his or her previous team. This only works if the rest of the team is comfortable calling out issues with the rhythms established. When you have a lot of junior people on the team this is rarely going to be the case.
- Restart with a methodology such as scrum. By starting with a methodology that is documented by outside parties the team starts off on more of an even footing. As they hit stumbling blocks there, they can learn what works for them as a team. The more seasoned developer can help steam them past some of the bigger obstacles, but in the end it allows the team to work together to figure out what is best for them as a whole.
The argument against Scum in the above situations is that it fails often; taking a prescriptive approach to Agile can never work. I agree with the second statement but I do not agree that scrum is a prescriptive methodology. scrum is a starting point only, and is intended to flex with the team. After all, any methodology that does not flex would not be Agile.
I know there are those in the industry who would disagree, but my response to them is simple. If you have participated in implementing scrum in a prescriptive manner the problem isn’t the methodology, it is the implementation. So as we do in the Agile world, learn from that mistake, and improve in the next iteration.
What do you think? Get in touch and let us know.