Having worked over many years on various sized projects, similarities can be drawn irrespective of who runs the project, what the business priority is and how much budget is available. Wherever you go you are likely to face the same issues or anti-patterns when it comes to process and approach.
The focus of this blog post will be the Agile sprint process, moreover what prevents us achieving near “Production Quality” code at the end of a sprint and how in turn that code becomes “Production Ready”. I will be looking at some of the main barriers to achieving this status, and outlining where things should change, to give the project team the best chance of success.
Before going into detail, I’d like to start by explaining what I mean by “Production Quality” and “Production Readiness”:
Production Quality – I see this as the minimum acceptable level for any code package delivered at the end of a sprint cycle. To achieve this production quality, I assume that before the sprint, an inclusive game-planning session was conducted, where the scope of each story was agreed, and the acceptance criteria (inclusive of tests) were defined in agreement with the Product Owner. The “Quality” is determined, by the fact that the project team has developed and reviewed the agreed stories within the sprint, meeting all of the acceptance criteria. By achieving this, the project team are suggesting that there is available a Production candidate that can be handed over to pre-release QA and / or Business Acceptance Teams (UAT) for validation.
Production Readiness – Once the release candidate has been subjected to ‘an appropriate’ level of QA and UAT analysis, if no blocking defects have been found, and all of the functional and non-functional requirements have been validated, we can label the package as “Production Ready”. The package can now be handed over to the Release Management team, in order to schedule a deployment to Production.
Now that I have clarified what I mean regarding quality and readiness, I’d like to address the title of this post “What cost a lack of acceptance?”. If elements of the sprint process are ignored, or overlooked, whether to save time, money or to get things done; the impact can be quite high. In my opinion, these thought processes are a false economy, as you are potentially shifting the issues later in the development or release cycle; which as we know from traditional analysis; the later in the lifecycle you detect a defect, the greater the cost is to fix it. So what pressures can be experienced, that can lead to a lack of acceptance?
1. Development Versus QA Ratios – Inequality within a project team with respect to the ratio of QA personnel to that of the development team can have a significant impact on the ability of the QA team to keep pace with in-sprint tasks (such as defining acceptance tests for future sprints and providing daily feedback during the current sprint) whilst conducting more traditional QA tasks; such as release candidate testing. If this situation arises, it is likely that a trade-off may need to happen. One such trade-off could be to reduce the amount of acceptance criteria on a story. If this happens, we could be adding risk to our release schedule as only limited validation has taken place before entering final QA; leading to more bugs being found during QA, requiring additional builds and retest cycles. Having to pull developers off of in-sprint duties to fix defects, raises the cost to the project. Not only in terms of time to fix (and merge to code branch(es)), but also the potential impact their withdrawal has on the current sprint.
2. Waterfall in a sprint – I have worked on projects, which claim to be Agile, which on inspection stretches the truth just a little! All that happens is work packages are split in to 3 weeks, the developers code for 2 – 2 1/2 weeks then ‘throw over the fence’ to the in-sprint QA for testing. Adopting this approach, does not maximise the potential gains of providing regular (daily?) feedback from the QA team. The earlier in the sprint issues are found; the quicker they can be fixed, raising the perception of quality on a daily basis.
3. Lack of Product Owner buyin – If your product owner is not fully engaged with the project, this can lead to a lack of acceptance. If the Product Owner does not provide (or at least provides input) the minimum acceptance criteria at the beginning of a sprint, the team will be fighting a losing battle, as come the walkthrough at the end of the sprint, any vagueness will more than likely have been interpreted incorrectly, and thus the Product Owner may insist on instance fixes to resolve before providing sign-off for the feature in question.
5. How integrated should you be? – If during a sprint the acceptance criteria, overlooks particular integration dependencies; including the target go-live dates of dependent systems, this could impact the projects attempts to achieve production readiness. A lack of understanding of release schedules for dependent systems can lead to reputational loss of the project team with sponsors; as features will be unusable in production, thus preventing the company from rolling the product or feature out to prospective clients.
I have experienced all of these pressures on various projects over the years. They are always likely to come up during software delivery projects; but it is how far they are allowed to manifest; that will determine the size of the impact that they will have. Keeping control of these factors, should increase confidence, and promote knowledge within the team. In order for the team to succeed, it is how these influences are handled, and how close the team sticks to the agreed approach, which will play a significant part in determining whether the delivered product is fit for purpose. Keeping control on acceptance criteria, from clear definition through to implementation will provide one of the key factors of project success.