Agile Teams Need to Guard Against Self-Mismanagement

Scrum is an excellent framework that provides a team with the requisite structure to address the complexities and challenges of software development while remaining completely open in terms of defining what the product is and how it will be implemented. A key tenet with agile and Scrum is that the team is in control of their work, and a framework like Scrum provides the necessary guidance for teams to coordinate and manage their work without being directed by someone else.

As simple as a framework like Scrum sounds, execution is harder than it appears. One danger is that people start adapting Scrum to meet their current ways of working instead of changing the way that they work. For Scrum to be of value it is important to look beyond the mechanics of the framework and embrace the Lean and agile thinking and approach to work.

Consider the standard phases of development and how the work that gets queued up using functional specialists and functional departments:

The larger the project, the bigger the queues of work, the greater the variability involved with that work, and the longer the cycle time of the system as a whole due to hand-offs of these large batches of work. There is also overhead required to plan and coordinate work between functional areas and specialists.

The goal of a Lean and agile organization is to reap all of the benefits of productive, satisfying software development that delights the customer for the least amount of effort expended. We start by recognizing that software development is a complex, non-linear and collaborative endeavor and respond by:

• Discarding approaches that create WIP queues and the bottlenecks.
• Using cross-functional teams that deliver complete features (business analysis, programming, and testing) without handing off work to other groups.
• Applying practices such as pair programing and test-driven development to eliminate queues and streamline delivery by moving from linear to parallel development.
• Continuously improving by being open-minded, inquisitive and continually learning and evolving.

This means that Scrum teams should not be approaching Sprints with a mindset that they are a series of mini-waterfall projects. Teams should be focused on the outcome that the team as a whole is producing for the customer. They should be doing so by working together as a team, collectively understanding the business need, agreeing on the definition of done, and determining how to accomplish the work with the least amount of effort expended by the team as a whole. Agile development should be efficient and disciplined.

Another part of the bargain is that an autonomous team makes a commitment to deliver a certain amount of functionality in each Sprint. It’s a team commitment to deliver the Sprint content, and the daily standup is where individual make even smaller commitments to deliver in meaningful ways that contribute to the team’s commitment.

Yes, there will be times when commitments aren’t met. Individuals may take on something that is outside of their comfort zone and stretches them. Likewise, this can occur at the team level as well, and a team can fail to meet its Sprint commitment. This is not a bad thing as people and teams should be pushing the envelope; and if they are, there will be misses every once in a while.

However, there are times when teams miss when they shouldn’t. I’ve seen problems because teams actually fail to manage their work. Two major areas where teams miss on managing are in planning and at the daily standup.

Planning. Teams should not accept poorly-prepared, un-groomed User Stories into a Sprint from the Product Owner. User Stories should be clear and include the “so that” portion to explain the business benefit to the team. The User Stories should also have clear acceptance criteria. User Stories are the team’s connection to the business and teams members need clarity about the team’ work, why it is important, and the criteria to judge when work will be considered done. Ambiguity with User Stories is a productivity-killer.

Daily Standup. I’ve seen people report on a task that is “taking longer than expected,” but the team takes no action. They let a high-priority issue continue to bog someone down without addressing the problem by swarming or at least having someone else assist in getting the task completed.

There are reasons that this occurs. Sometimes people want to hang onto work because they feel that it will reflect poorly on them if they don’t complete the task. This is where it is important to stress the team over the individual, and that collaboration is valued because it improves throughput. I’ve seen many situations where teams are failing to collaborate effectively, leading to lost time and aggravation that could have been avoided.

Sometimes people hesitate to speak up because they are afraid of confrontation – either because they are personally uncomfortable with raising concerns or they are afraid of the reaction that they will get. I devised the Elevator Story as a signal for the team to take action as a matter of policy to help address this issue.

Another productivity issue arises when people treat the daily standup meeting as a status meeting. The daily standup should be more than that. In short, standups are an opportunity…

• To identify where knowledge and experience can be shared.
• To identify impediments.
• For each team member to make a commitment.
• For the team to monitor its progress (towards its Sprint commitment) as a whole.

Another problem area deals with the boundaries and roles of Scrum. More on this in my next post.