Introduction
Organizations move to Agile (Scrum) to get early customer feedback and deliver features incrementally. They also become Agile because it sounds more appealing than the alternative!
Either way, from my recent informal audience poll of 450 people, two-thirds are not happy with their Agile implementation and experience chronic chaos or quality problems. What is going on, and what can be done?
Agile and risk
The short feedback cycles of Agile mitigate some of the technical risks related to building the wrong thing and provide periodic milestones to evaluate requirements changes. In contrast, teams that use a rudimentary version of the Waterfall life cycle (with little or no risk management) assume the risk of discovering that they built the wrong product towards the end of the project.
When teams see Agile as a complete process solution (rather than a process framework), then the missing practices add cost, schedule and quality risks back to the project. Teams moving from Waterfall to Agile don’t eliminate risks, they transfer them. When risks are not assessed or mitigated, they become problematic, even chaotic.
“Chaos: A state in which behavior and events are not controlled by anything.” — Merriam-Webster
Agile intent
Scrum (an Agile implementation) in essence is just four practices: plan a bit, track a bit, and get feedback via a demo and a retrospective session. These are all good things, but there is more needed to manage a project.
Being “Agile” means being able to respond to change early, having the insight to get feedback, the opportunity to do it, and using the information gleaned. Agile does not mean that you can’t do a good job on requirements, design, test and planning, nor does it mean that you have to stick with only the four practices of sprint planning, execution, demo, and retrospective.
I have even spoken with teams that were instructed not to add anything to the process because that would be non-Agile. If you are getting such advice, think about your results and how good the advice is. In fact, if you don’t change the process, then retrospective data are probably being ignored, and that step should be deleted. Deleting the retrospective step or ignoring the results would be non-Agile. So that advice is non-Agile too.
Why do Agile teams end up in chaos?
Chaos is caused by work being disorganized with no end (or project goal) in sight. Some teams can survive on chaos and deliver results, but it is high-risk and usually only fun in the short term. Common causes of chaos are:
- No or poorly defined requirements to clarify what to build and the need being addressed.
- Overcommitment that leads to the avoidance of other basic practices (e.g., test and design) because they take up precious coding time.
- Few project management practices performed that lead to unmanaged risks (and chronic surprises), minimal estimation (overcommitment), an unrealistic schedule (or visibility until the last day).
- Customer and management expectations are not accurately set so that any deadline is by default risky or unachievable.
- Chaos (a smokescreen) is created to avoid accountability.
It doesn’t have to be like this
Teams that employ additional practices don’t have chronic deadline, quality, or project management problems.
Improve the result of your overall project and of each Agile step by adding practices to solve the problems you have experienced so far. A short list of examples is provided below. Look at your team’s retrospective data to see which problems have been underlying trends.
Example practices to add, but in a lightweight, Agile way:
- Backlog: Add use cases for high-risk requirements, perform requirements peer reviews, define other requirement types (such as quality attributes, constraints, data definition, functional requirements, business requirements, interfaces, and business rules).
- Planning: Adopt release planning and risk management.
- Estimation: Validate story point estimates with effort estimates, and factor in team capacity in each sprint.
- Development: Add design notes to clarify what to code, define interfaces and customer data. Conduct thorough peer reviews of code and test cases to find defects before test.
- Tracking: Track actual effort expended to determine whether that amount can be sustained and calibrate story point data.
- Testing: Add automated, regression, integration, system and acceptance testing to later sprints.
- Retrospectives: Analyze data for critical and chronic issues. Share lessons across teams with people assigned to act on common issues and share new process steps.
New practices usually come from outside of the Agile community.
Conclusion
Agile (Scrum) does many things well but it is not risk-free. Problems and chaos can be significantly reduced by adding practices. Look at your team’s results and retrospective data. What do they say?
If you have comments or questions about this article, or would like to get some helpful complimentary feedback regarding your current Agile state, contact us.
[Forward this email to your boss! Subject: Here’s a cool tip for you] Quick Link.If there are challenges your group is having that you would like us to anonymously address in future blogs let us know.
Other articles you might like:
The Process Group helps you improve your organization's capability to routinely meet deadlines and delivery quality expectations. We are certified CMMI appraisers / trainers and Certified Scrum Masters. 
