SCRUM strives to have developers release 'production ready' code with each iteration, or least that's what popular guidance tells us. Unfortunately, these two words can lead to some teams questioning their compliance with the process, or worse, questioning whether or not the process is even viable. I was reminded of this recently when someone claimed they weren't following "real" SCRUM because they always had to wait for testing after the Sprint ended.
Depending on how you define "production ready", you may be setting expectations too high. "If" you can actually implement changes, test, and release them into production with each iteration, then great. However, many shops can't achieve this, and that doesn't mean they're not following the SCRUM process correctly. To understand this, we need to go to the source and see how some popular guidance may have mis-led us. In this case, we need to hear from Ken Schwaber who is credited as one of the main authors of the SCRUM process. Luckily for us he's published the details on this particular issue.
The Team consists of developers with all the skills to turn the Product Owner’s requirements into a potentially releasable piece of the product by the end of the Sprint.
- Scrum.org (http://www.scrum.org/scrumguides/)
If you compare "production ready" and "potentially releasable", you can see the difference. This may seem like splitting hairs, but the expectations for each are different. If you're going to question whether or not the process is viable based on this tenet then you need to make sure you scope it correctly. The SCRUM process doesn't really define what this means, leaving it's criteria and measurement up to the implementor. With that said, the process does try to encourage Sprint definitions that lead to complete features, which is consistent with an iterative approach. This lack of detail is actually a good thing, since it gives us (e.g. the implementors) the flexibility to define a criteria that is appropriate for our environment. Lets face it, if you've worked in more then a couple dev shops then you know the culture related to product releases can be quite varied.
The decision on whether or not to release a product can be informed by a number of factors; many of which can require resources outside the Team. Here are a few example:
- Product Testing (e.g. verification and validation of functional requirements)
- End user acceptance testing
- Security review
- Compliance review (e.g. validation of regulatory issues such as PCI, Privacy Act, Section 508, etc.)
- Alignment with marketing initiatives
- Enterprise integration testing
- Etc...
Consequently... while the Team may feel they're "Production Ready" it may be some time before the larger organization makes the same assessment. Thinking more generically about testing, lets take a look at a few common patterns seen in dev shops today.
This first pattern represents what would be required to produce an iteration of a product and test it within a single Sprint. This approach requires the testers and dev team work very closely together. Since both are pigs in the same Sprint, communication between the two parties can be very efficient allowing devs to quickly address bugs as they're found. On the down side, the team must reduce their development capacity to stabilize the product earlier in the Sprint life-cycle. For small product changes this capacity reduction can be fine, but present challenges for larger changes. While this may work in some teams it won't be practical for many. Many organizations have dedicated test teams supporting multiple Teams and Products. This makes commitment in any one Teams Sprint less practical, so these organizations may employ patterns that look more like the following:
In this pattern, the dev team communicates readiness for test as features are completed throughout the Sprint. This typically occurs near the end of the Sprint allowing the test team to start building/refining test plans, start testing, etc... In this case, the test team is not a pig, so testing will often continue well into the next Sprint.
Similar to the previous pattern, this version acknowledges those environments where the test teams first introduction to product changes is the Sprint Review.
No matter which pattern your organization follows, any of these can reasonably; and correctly; be applying the SCRUM process. If the dev team is producing complete changes, based on what was known during Sprint Planning, they're not in violation of the process. So the next time someone says your not following the "real" SCRUM process because of your release schedule, you can point them to Ken. Maybe they can try and convince him. Good Luck.
Tags: processes