The Limits of Scrum
I've discussed the issue of the limits of Scrum before but it has new life for me after doing a seminar last night called Scaling Scrum With Lean Software and Design Patterns: Going Beyond Scrum of Scrums. You can get the notes for this seminar by going here. This requires registration, which you can do here.
The seminar I gave starts out with the popular, useful, but limited scope notion of Scrum of scrums. Scrum of scrums is useful for coordinating several teams working on the same or related projects. It starts losing efficacy when the projects are of a different nature or timespan. Essentially Scrum of scrums is useful for:
- keeping management apprised of progress across all projects
- keep cross-cutting requirements in synch
- keep different projects technically coordinated
- assist in the re-use of code
- coordinate common infrastructure tasks
- coordinate create, maintainence and use of common components
Basically, Scrum of scrum is a good coordination device of the problems scaling software has. However, besides just managing the problems you have, it might be a good idea to eliminate the problems in the first place. This is where Lean Software Development and Design Patterns come in. A Lean approach can lower the complexity of your projects while minimizing the number of active projects at any one time. This reduces thrashing and the number of collisions between projects because there are fewer projects at any one time. Design patterns can reduce the technical dependencies between projects. In other words, don't just manage dependencies with Scrum of scrums, try to eliminate the problem you are having with other methods than Scrum.
I am always surprised about how people following Scrum seem surprised themselves that they run into difficulty. Remember, Scrum started out as a wrapper for whatever process was in use. Very often, there was no real process in use to begin with - other than doing things in an ad-hoc manner. This means that adopting Scrum was very useful in creating an iterative process that improved customer relationships with the team. However, there are five aspects to software development that are highly integrated with each other:
- The business view of the software development
- Agile analysis (discovering that what needs to be developed)
- Agile process (managing an iterative project - this is where Scrum shines)
- Techical issues (design patterns, test-driven development)
- Quality assurance issues (improving your process to eliminate the creation of errors, not just fix them)
Scrum is good, but it only directly addresses one of 5 essential pieces. Scaling scrum also focuses on just one of the five scaling issues that come to mind (there are probably more):
- number of projects
- resources required for projects
- technical dependencies between projects
- complexity of projects
- coordinating multiple projects
Lean principles and design patterns are required to assist in the others. Scrum is good. Scrum within the context of Lean using design patterns, QA as a process improvement method (also a lean concept) and using design patterns and Test-Driven-Development is better.
- alshall's blog
- Login or register to post comments


Technorati Tags:
tag with del.icio.us