For any company that adopts Scrum, there will be an initial period where productivity dips a bit while everyone understands the process, but then within a very short time their productivity will spike higher. Ayende Rahien in a recent post gets into a some excellent detail into where Scrum as a “Product” development process falls short when developing software.
The reasons for this are pretty obvious when you look at Scrum side-by-side with what we know to be best practices for software engineering. It isn’t until you understand what each bring to the table that you can see their shortcomings and then blend the two together to create a process that brings the strengths of both together to bear on the problem.
Scrum’s short iterations, frequent feedback, and quick turn-around are clear winners. It shortens the feedback cycle and makes staying focused on the highest priorities for the Product Owner much easier. It also allows for changing direction when requirements change. However, as Ayende points out, there is nothing in this that is software-specific. That’s where software engineering practices like Test Driven Development, Continuous Integration, and Refactoring come into play. These work together to ensure that the “product” is built using best practices that focus on the actual product and the idiosyncrasies of its development.
It is critical that these best practices be interwoven into your software development process – especially an Agile process like Scrum. Because without them, you are missing out on the aspects that emphasize quality. Over time, as quality declines, so too will your velocity. Ayende describes this:
“You hit the Scrum wall when you adopt Scrum and everything goes well, then, after a few Sprints things don’t work any more - to use an English expression, they go pear shaped. You can’t keep your commitments, you can’t release software, your customers get annoyed and angry, it looks like Scrum is broken.”
How many times have you gotten a few sprints into your project, and then had to put on the brakes to introduce a “go back and fix stuff” sprint? For our team, it happened a lot early on before we adopted those best practices. After adopting them, we rarely had to go back to code due to quality issues; rather, we were more likely to have to revisit code due to changes in requirements or additional features being added. Clearly this is much better – we’re now focusing on business drivers and less on technical debt.
Bottom line – don’t forget to roll into your process the details for following the software engineering best practices. Let Scrum manage what it does well – requirements and deliverables. When you include the best of each of these your product will benefit greatly.
No comments:
Post a Comment