Scrum is a 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 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:
The product being developed turns out to be much harder than expected.
The use of a new technology is not economically feasible or reliable.
There is conflict among different divisions in the company regarding the product vision and target customer.
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 whether your Scrum implementation helped cause this problem or just found it.
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 company's 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.
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 special 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 the 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 that there is no need to pay attention to the clarity of incoming requirements.
Have the ScrumMaster fix it.
The ScrumMaster'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 ScrumMaster 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 they 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 workaround 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 jobs.
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.
If you have comments or questions, please write them below and/or email firstname.lastname@example.org.