Debugging Scrum Implementations

2 October 2013

Anurag Prakash
American Express



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:

  1. 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.
  2. 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.
  3. 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.
  4. 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.
  5. 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.
  6. 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.
  7. 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:

  1. 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.

  2. 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.

  3. 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.

Article Rating

Current rating: 4.4 (7 ratings)

Comments

Ravi Kant Srivastava, CSM, 10/2/2013 1:15:20 AM
This is grt. But the real problem lies in its implementation as u have already mentioned.
I recently heard from one manging director that " we use Scrum with our own way of implementation."
So there team doesn't have product backlog, they can add stories anytime in sprint cuz customer has asked. Estimation either goes 200% above or 50% below in short team doesn't understand the concept of estimation. And I said "wow" he then asked me what is our problem. I said rename ur process to "xyz". And before implementing Scrum.

Understand it and try to think why Scrum is being introduced.
What I believe if the team is self organised it is above the requirement of process.
Scrum is taken now as days "process to develop faster".... on this statement I have asked. "U got two burgers". Implement Scrum to eat it faster.
Scrum is a solution for many but not for all. Don't go on what we say as Scrum users...... see it in action... observe .... learn.....make ur decision..... but while implementing Scrum implement it in it truest nature
Kylie Shipsky, CSM, 10/2/2013 12:04:09 PM
Great article, Anurag.

In our organization, we are challenged by the market to constantly innovate and create new products, while at the same time by regulatory constraints, including "must comply" dates. The result is that many of our projects involve delivering new, bleeding edge products or features, within fixed dates.

We are also challenged by the fact that most of our external business partners are not using Agile, and require education to understand our product development lifecycle.

My Scrum team has learned to work within fixed constraints by focusing on delivering the greatest value in the shortest possible time, and we use that focus as a starting point to negotiate features with internal and external product owners.

We still time-box our work in 2-week sprints, and release code to production monthly, sometimes more frequently.

How does the team cope with feeling like all of our work is already "signed and sealed" before we know how we'll deliver? Our internal Product Owner continuosly balances and adjusts, where needed, our product roadmap to align with mandated dates. She frequently communicates and reinforces the product vision with the team. Sprints are loosely planned about 2-4 sprints in advance. All team members have input into what stories will be included in each sprint. During the Sprint Planning, the team discusses each story planned, agrees on the relative complexity of each story (1-5 points for our team), looks at the total number of points planned, and either commits to or adjusts the plan. As a team we understand what our commitment must be in order to meet the minimum requirements imposed by external forces, and we also evaluate what else we can do to iterate and improve our core products.

I believe that this collaborative approach to planning is the biggest factor in moving us from a command-and-control culture to one in which teams can more effectively work, achieve and evolve together--even in a fast-changing, heavily regulated industry.
Anurag Prakash, CSM, 10/3/2013 11:30:36 AM
Ravi,

Unfortunately Scrum is being adopted in many places because people have heard great things about it. Adopting Scrum required changing the way we work. It requires us to move to good Agile engineering practices and to move to a more open work environment with empowered teams.

In many organizations people don't change their practices and methods but change Scrum to suit their existing philosophy. Following Scrum rituals religiously may not cut it.

As in your case, if the organization is not committed to new engineering practices, discipline and empowered teams, then there is no reason to try Scrum.
Anurag Prakash, CSM, 10/3/2013 11:33:36 AM
Kylie,

Happy to know that your org has figured out their formula for success. Everyone needs to work out their own solution. The only comment I would have is that ideally, team members should not have "input" in Sprint planning. They should be responsible for it.
VENKATESWARAN R, CSM, 10/7/2013 6:15:35 AM
Nice. Some of it mostly fit for my project that is not at all a Scrum based but claimed to be, unfortunately.
Anurag Prakash, CSM, 10/10/2013 12:51:31 PM
Venkateswaran,

Try taking just one item at a time. See if you can get the Architect to describe the architecture in 3 or 4 sentenses. Make them write it down. Then work from there.

Clear and Clean communication can save a ton of time and cost.
Krishnaraj CK, CSM,CSPO, 10/24/2013 6:59:28 AM
Point 7 "Are the teams organized per software module?" rings in loudly for how my teams are organized now. And in the Indian context, more often than not you will notice this, simply because of geography. The teams tend to be myopic and highly focused on the small picture. This is detrimental to the overall effectiveness of Scrum even though these teams may appear to be agile. It is upto the program team to realize this counter productive team alignment and course correct.
Veronica Stewart, CSP,CSM, 11/22/2013 11:00:10 AM
Great article Anurag! I see #7 a lot in larger companies where it becomes difficult to deliver a story when the slices of functionality to complete the story is dependent on other departments that are not part of the team or are not temporarily participating in order to successfully delivery a story or feature. What happens most of the time is a story not getting completed and approved in that sprint.

You must Login or Signup to comment.