At two of my gigs, we used the Scrum development methodology. It’s an agile, spiral approach that employs continuous integration, and has the following characteristics :
- Project manager/Product Manager/other stakeholders develop a prioritized list of features.
- Work is done in sprints, typically two weeks long.
- At the start of each sprint, developers define tasks to implement the highest priority features. A task is expected to be completed within a sprint.
- Developers estimate level of effort of the tasks.
- One or more developers commit to tasks for the sprint.
- Every day there is a “stand up” meeting — no sitting, so it’s brief. Each developer summarizes what he/she did yesterday, is working on today, and, most important, identifies anything blocking work on the task.
- At the end of each sprint, there is expected to be a system that displays end-to-end, round trip functionality. It may not be release-ready, but it works. Usually there is a demo to stakeholders.
- Management re-orders the priority of tasks in the backlog as business situations change or become more clear.
Scrum is awesome! I have not found any more effective methodology for knocking out working code in a hurry.
Scrum is not perfect, however. One problem is that the frantic pace of grabbing a task and running with it does not leave folks with time to ponder, to imagine other ways of doing things that would be slicker, more compelling, more disruptive to the market. In short, a knock against Scrum is that it produces software that meets requirements, is adequate, but is not great, not innovative, not something that people didn’t even know they wanted but truly love when they see. See The Lean Mindset: Ask the Right Questions for more on this topic.
But let’s assume that in the process of defining features and tasks, we have already come up with a stunningly good idea. Even here I think that there are problems with Scrum.
One big one is the tendency for there to be a massive “integration day” near the end of the sprint. This happens especially when there are dependencies between tasks in the sprint. E.g., a UI task might depend on a new back-end function. If the function as implemented is not what the UI developer assumed, a long night ensues.
Another is the tendency for programmers to bite off more than they can chew, so they are frantically developing up to the end, without having written unit tests. I’ve heard developers say “just get it done; QA will find any problems,” which is both chilling and galling.
But the biggest problem — and let me be clear, my complaint is against Scrum as I’ve seen it done, not Scrum in theory — is that QA is supposed to be complete by the end of the sprint. QA can’t bless code until a developer turns it over, at which point the developer is supposed to what — cheer on QA? Buy them drinks so they won’t find problems??
I think this could be addressed by staggering QA and development: when developers are done, QA starts. When QA blesses, the sprint is done.
While QA is working, developers would be planning the next sprint. And they would be expected to give highest priority to resolving the problems that QA finds.
That would not be Scrum, and I’ve never seen the approach I describe put in practice. But I’ve seen a lot of folks looking for a magic wand to wave so that QA would be happy as soon as code is handed to them. So far, nobody has found that wand…