I have a theme going this week on this blog. I’ve been touching on reasons why software developers dislike agile development and Scrum in particular. But wait there’s more!
Some software engineers dislike having to deliver “production-ready” code at the end of each sprint. I can understand why. I often race through a code module (or a blog post) trying to lay a good foundation but not concerned about the details. Considerable refactoring may be needed to get the module to what I would consider to be “production-ready” (that is, completely “done”).
If you have to stop and refactor during every sprint, you might get frustrated. You’re anxious to get all of the planned functionality built out before spending lots of time on finishing touches. Delivering code that is incomplete is not satisfying and you know that building out the entire module will take multiple stories and several sprints.
Scrum doesn’t constrain us. We constrain ourselves.
I believe that Scrum offers a lot of control over the above scenario. For example, what does “production-ready” mean? There is no standard definition. Also, what exactly do you need to deliver at the end of sprint? There is no standard definition for that either.
The point is that the Scrum Master, Product Owner, and the development team have wide latitude to define what is acceptable or production-ready and what is not. Nothing inherent in Scrum requires that your source code be clean and complete at the end of every sprint. (I think it should be clean and complete at the end of a release but that’s a separate issue.)
Here’s some guidance for making Scrum more livable.
- Each story must have acceptance criteria. Focus the criteria on the functionality of the code from a business perspective, not the implementation. Leave yourself some latitude in how you solve the business problems.
- Keep stories small and limited in scope. Basic functionality, advanced functions, error handling, refactoring, and even documentation can be covered in separate stories. You’ll get a sense of accomplishment from each story even though there is more to do.
- “Production-ready” means the software implements stories as intended or defined and is free of serious defects (anything that may cause crashes or data loss to the best of the team’s knowledge). It does not mean that the software contains all the features and functions desired by anyone that may use it. Nor does it mean that the software will trap every user error condition or be as responsive as it could.
At times we blame the software development process for problems that we create. The developers, testers, stakeholders and managers need to feel comfortable with the process and the deliverables.
If you’re having trouble meeting sprint goals, maybe the goals need to change.