Introduction
Scrum is a simple and useful approach for managing software development projects. When performed correctly, it breaks work into manageable pieces and assesses technical risk. Some teams, however, run into trouble very quickly because Scrum is blamed when it uncovers stinky issues. In many cases Scrum is highlighting an existing problem, not causing it.
Example problems that are uncovered are:
- Conflict among different divisions in the company regarding the product vision and target customer
- The product being developed is turning out to be much harder than expected
- The use of a new technology is not economically feasible or reliable
- The team lacks domain knowledge
- The project team’s rate of progress is not enough to complete the project on time
- Suppliers are unqualified and cannot deliver their commitments
- Work is declared “done” whether it is done or not
- The Scrum team is not trained or allowed to implement Scrum correctly
Scrum can find many of these issues early because real work is required to be performed in each sprint. Real work performed in early sprints can uncover issues at a point in the project when there is nothing else yet to blame. When these issues are embarrassing, or no one wants to address them, blaming Scrum can be the easiest option.
All of the example problems above are ones that a “traditional” (non-Scrum) team would likely have found if they were performing risk management and prototyping to mitigate the highest risk areas. Scrum finds similar issues early because each sprint includes some development activity where issues become apparent.
In life cycles that are not well implemented, or ones where no risk management or prototyping are performed, stinky issues can be hidden for long periods of time or conveniently mixed with other issues that might have arisen.
For example, a lack of domain expertise among developers can be nicely mixed in with “no time for writing test cases,” “too many meetings caused by Scrum to learn the domain,” “rushed design reviews,” and “the requirements changed too many times.” The longer a problem is left unaddressed, the more project issues there are to blame. No direct or logical link is needed between the item blamed and the presumed cause.
Not every Scrum implementation is perfect, and it cannot be assumed that Scrum is always innocent. There are many Scrum teams that have not learned Scrum very well or are missing some of the additional skills required to make Scrum successful. Examples are release planning, requirements elicitation, requirements writing, design, test planning, test-case writing, configuration management, and domain knowledge. Just performing Scrum without these practices highlights another stinky issue.
What to do about it
In the case where Scrum finds a stinky issue, be gentle! Whoever has been cornered didn’t expect it, and this level of accountability is very uncomfortable. Consider the following options:
- Determine if your Scrum implementation helped cause this problem or just found it.
Example 1: The selected supplier has been asked to develop a design and provide an early version of a simple database. Usually suppliers are given six months to design and code the database. This time the Scrum team asks to see a simple version to run data migration tests in the first iteration. The supplier provides data and interfaces in the wrong format and does not understand the requirement. After further investigation, it is found that the supplier was the absolute cheapest of all the ones considered. In this example, Scrum found a stinky issue very early but did not cause it.
The team develops screen shots of a new system and shows them to the customer. The customer states that all the information is incorrect and that the team has no understanding of the domain. Management gives the task to another team to “demonstrate” the companies’ expertise. The customer makes similar comments. The Scrum process is blamed for having too many meetings and focusing on academic Sprint goals rather than technical customer issues.
In this case there are two stinky issues: The Scrum team could have recognized a skill problem when working on the requirements backlog. Second, since other teams had the same problem, the larger stinky issue is how management employs, trains and maintains the domain knowledge of the staff for any project.
Example 2: The team generates a list of user stories. A few of them are clear; the remaining user stories are at best placeholders for investigation. All of them are considered high-priority and are allocated to the release with an established deadline. The Scrum team assumed that it would be able to de-scope functionality at any time or move the deadline back. Marketing and management assumed that a commitment was a commitment and that Scrum had magical powers to deliver “fast” and on time. In this case the implementation of Scrum was blamed, and this was probably a good call.There are many things the team could have done to assess and mitigate their risks, for example:
- Only allowed cleaned-up user stories to enter the release
- Included domain experts and testers in backlog and sprint reviews to check the accuracy of implementation
- Revisited priorities – it is unlikely that everything has exactly the same (high) priority
- Determined a possible incremental delivery schedule to deliver lower-priority functionality later
- Provided a most-likely and least-likely release date and provided updates at each sprint with velocity data
- Assessed and mitigated risks, and communicated them to management until the message was recognized
There is no guarantee as to what exactly management will respond to, but anything might be better than to ask for a huge delay just before the deadline.
A second stinky issue is that management assumed Scrum would fix their software development delivery problem, and there is no need to pay attention to the clarity of incoming requirements.
- Have the Scrum Master fix it
The Scrum Master’s job is to address impediments. This might involve the help of other teams and managers in the organization. If an issue is particularly stinky, the Scrum Master might escalate the issue to get additional visibility and assistance. Tread carefully; you might be seen as a troublemaker (a messenger to be shot). Bring solutions, not just problems.
- Suggest a solution to the identified problem
If Scrum is highlighting the problem, the responsible party might need help. Stinky issues such as the coordination of multiple project teams around the globe, large numbers of defects entering final test, and the lack of domain knowledge within teams might have gone unsolved for years. This might imply that management is open to constructive ideas.
- Escalate to senior management
If it is a long-term, systemic or critical problem, it might be time to communicate the issue to management. Sometimes management simply has no idea that the issue exists, and are capable of solving it. Sometimes they are aware of the problem, but it was treated as background noise until now. Sometimes they don’t know what to do and have decided to ignore it. Mention the problem, don’t give names if that is safer (let them investigate for themselves), and let them take the level of action they think appropriate.
- Work around the issue
Some organizations never address stinky issues. Be prepared for no action and develop a work-around plan. That might mean that your team has to track program dependencies, work with customers and marketing on commitments, or train suppliers in how they should do their job.
Summary
Look out for situations where Scrum (or any process) is blamed because it found a stinky issue. Break down the problem into the parts the team can address, and the parts that are underlying or systemic. Lead the way and take action rather than engage in lengthy blame battles.
Further education in Scrum is at processgroup.com/services18asdcs