Scrum is easy to learn but difficult to implement, as has often been said. Companies have been putting out directives and setting direction for their teams to adopt Agile. However, everyone I have met has had tons of issues, from how to size a story to "Oh, we have a constant stream of bugs," "They pull me into firefights all the time," "The dependencies suck," and "How can I develop without design first?" Let's examine broad categories of issues.
Focus on Scrum rituals and not on engineering practices
XP explicitly emphasizes engineering practices, but they are as important in Scrum. If Scrum is viewed as a process
initiative, there is emphasis on Scrum rituals
. So even with perfect Scrum process, teams will struggle.
Here are questions to ask if your Scrum team is not churning out a consistent stream of quality output:
Can you describe the architecture of the system in three sentences? If the team or the architect cannot describe the type of architecture and the trade-offs behind selecting that architecture, then there is lack of clarity -- and that hurts Agility. A clean architecture and good design are essential to easy, low-cost refactoring, which is the key to being Agile. Emergent design with minimal design up front is the way of Agile.
Are your regression tests automated? Automated regression helps the team focus on creating new functionality by reducing the possibility of introducing bugs in older functionality. Team velocity should include effort to complete, test, and debug stories in the current sprint. If new bugs keep getting discovered after sprint completion, they will reduce the reliability of the velocity number. In addition, they will prevent quick refactoring.
How long does it take for your regression suite to run? Functional tests using the UI may take a long time to run. A regression suite that takes time to run gets used less and less. Writing the tests to a layer just below the UI may help the suite complete in hours instead of days. This enables developers to get quick feedback on each of their check-ins, enabling continuous integration.
Do you have a long Sprint Zero? And are any stories completed in Sprint Zero? A long Sprint Zero with no completed stories is symptomatic of a team that still wants to follow Waterfall. It will often use Sprint Zero for the Big Design Upfront (BDF). The challenge in Agile is to modify design practices to get to emergent design and easy refactoring. For many teams, Sprint Zero is a proxy name for BDF.
How long does it take to make decisions? Agility involves quicker decision making. There are a ton of known design patterns, software tools with user feedback, coding guidelines, and other data. The organization should be able to make decisions in a limited amount of time using effective communication and available data.
Is it easy to explain the design to a new team member? If the design is easy to explain, then it's easy to test, replace, or refactor. One idea is to create folder structures to reflect some of the architectural design. Someone looking to update or fix a feature should be able to easily narrow down to the relevant code.
Are the teams organized per software module? When teams are organized around software modules or software layers or service objects, one Scrum team will own the story but will have painful dependencies on other teams. Inter-team negotiations, inter-team estimates, inter-team deadlines, and inter-team politics may result. All of which are bad for a highly productive Agile environment.
In the case of large software with multiple teams, Scrum-of-Scrums can work, unmodified, for service-oriented architecture or simple layered architecture. But for other platform architectures and org structures, we need to carefully design the communication and coordination scheme.
Inability of management to let go of command and control
There is a reason Agile prefers "people over processes." We have found that there is no substitute for a happy, motivated workforce. One way to motivate the team is to empower its members and enable a feeling of ownership and accomplishment. In exchange for empowerment, the team provides visibility and measurement by outcome (completed stories). Empowerment necessarily implies letting go.
Here are a few questions to ask:
Are release scope, resources, and schedule fixed by higher management? A Waterfall project may go like this: Agree to a fixed cost-scope-schedule → Miss the delivery date → Re-plan, re-cost, or re-scope → Complete the project after one or more re-plans.
Since predicting the future (estimation) is not a perfect science, we realize that the triple constraints of cost-scope-schedule cannot be perfectly specified in advance. A team could work on stories and make a release when the feature set becomes a minimum viable increment. Alternatively, the release date could be fixed and the team may release whatever feature set is completed by that date.
Am I required to follow processes or use specific tools even though I do not know why? Processes and compliance requirements are usually put in place to meet quality, cost, or regulatory requirements. These need to be reevaluated. E.g., Sarbanes-Oxley compliance may still be valid, but a test gate that was required in the past may not be useful in Agile. If the team cannot question and discuss company processes, then it's an indication that the team is not empowered.
There is a large group in the Scrum community that favors open source testing. If the team is forced to use certain software tools because "we paid a lot of money for them," then that's a problem. It turns out some of the open source tools are far more flexible.
Are my sprints planned for me? Scrum turns the project into a highly visible and flexible undertaking. Without the freedom to plan its work, the team becomes a micromanaged team.
The motivation for this article
Sometimes it is not easy to relate the symptom of dysfunction to the exact cause. I wanted to create a clear list of symptoms versus causes of dysfunction, and then their potential solutions. Your experiences and comments are welcome via comments on this article or via email.