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.
We tend to say that at the end of the sprint, we should have a “demonstrable”. “Production ready” is a really high bar, when all you really need is something to show the business that they can react to.
We always say that things could be released to production if needed, but they likely won’t be, as we will iterate some more with input from the business.
It is hard for me to agree on your guidance for making Scrum more livable.
1. You are introducing technical dept problem here. Fast delivery covering positive path but during implementation you assume you will come back to that sooner or later.
2. Keep stories small and limited in scope – true BUT user stories for developers? I would say that this is also technical dept. This type of user story can end in technical backlog but what value does it bring for the customer?
3. Notion of “production ready” should be established by QA. Based on risk and according to company/project quality standard. And what do you mean – “free of serious defects”? You don’t have magic bowl to tell you that. The “serious defects” exist only if you prove it to be there.
And my general remark, if you hate scrum don’t use it!
After some amount of changes it won’t be scrum anymore… so why to call it that way 🙂
Regards!
I agree that if you modify Scrum to make it fit your needs or situation, the end result is likely not Scrum. I’m okay with that. My goal is agility not preserving the essence of Scrum. If your team has the discipline and cooperation needed to make standard Scrum work, I applaud you! That’s great! If not, try something else.
And I totally agree with you about adopting (modifying) framework to this be the best fit for you. Only creativity can drive us somewhere. But (there is always “but” 🙂 ), agility preserving or not preserving the essence of Scrum is not an “excuse” to introduce technical dept. That was my major point in previous post.
Doing anything but the religion of Agile is just not acceptable by the Agile zealots. This video captures the absurdity of that attitude:
http://www.youtube.com/watch?v=nvks70PD0Rs
John
The video is over the top but the point is valid. Many managers want to claim to be agile. That’s all they really care about when they should be caring about results.