Surviving Agile Without a Status Report—Engaging With the Team

Team engagement blows away a status report.

Agile deprioritizes the status report in favor of promoting the self-organizing team. Agile asks managers to trust a team of motivated individuals and give them the environment and support they need to succeed. Without the status report, in order to best support the team, managers need something new to gather critical information on the needs of the team.

The first post in the series provided the context for why status reports no longer work for the needs of modern, Agile organizations.

This post focuses on mechanisms for a manager to engage with an Agile team as a means of intimately understanding the team’s context. With the full context, management can easily understand how they can enable the team to succeed. When most managers try these engagement behaviors, they never want to go back to the inferior status report.

The Pattern for Manager & Team Engagement

As shown in Figure A, this pattern has three key behaviors—Observe, Align, and Improve. All three behaviors require a solid foundation of psychological safety.

The Safety Requirement

Safety is necessary for the Team Engagement pattern because of the level of transparency that is expected from the team to management. Through these behaviors, we are breaking down the walls between the manager and the team that the status report has helped to build. The walls will not be removed if the team does not feel safe.

Try the following to build safety as you experiment with these team engagement behaviors:

• Set Expectations: Meet with your team ahead of the new behaviors to set expectations. Explain how the information gained will be used to support and serve the needs of the team better and not to criticize or point out problems.
• Create a Working Agreement: Form a working agreement with your teams to create rules for how the managers will engage with the team and how the team will engage with managers as the team engagement pattern behaviors are put in place.
• Build Trust & Ownership: Try techniques for moving from command and control to team trust and ownership as outlined in Overcoming the Fear of the Incapable Team
• Embrace and Celebrate the “Red”: When problems emerge or things don’t go as planned, embrace it, learn from it, and celebrate it. Remove the blame from the equation and help support the team in getting better from the experience. The act of elevating learning moments will do wonders for building safety and helping your team transparently and expediently raise the problems along with the successes.
• Obtain Coaching: Enlist the help of your Agile coach to build trust between managers and teams. The coach can act as a neutral third party to work with you and your team to identify trust gaps and identify options and experiments to close them.

Observe

A major issue with status reports is the “manage from afar” behavior that they encourage. It is all too easy to sit in an office, far removed from the team, and read a status report. The worst part is that the cleansed information in a status report does not give an accurate picture of what is truly happening. Even if the information is not sanitized, a status report is a poor substitute for the reality on the ground.

The “Observe” behavior of the team Engagement pattern requires managers to take a walk—more specifically, a Gemba walk¹. A Gemba walk is a means for a manager to get out of his or her office and observe the team in action at the real place of work. This is not a meeting in a conference room. Rather, this walk is meant to be in the team room or wherever the team performs the work to develop the product.

Gemba walks typically focus on an area for improvement. Gemba walks provide a mechanism for observation and should not be used as a problem-solving activity or taken as an opportunity to point out problems. This technique is a key means of empathizing with your teams and learning how you can serve them by improving the system within which they work. As an extra benefit, you will form a closer relationship with your team through this face-to-face interaction.

After performing a Gemba walk, you will notice a distinct difference in the richness and meaningfulness of the data you obtain as compared to a status report. You will come away with observations for improvement based on the reality on the ground. You will understand the true environment within which your team works. Incrementally taking action with your team to improve the environment in which they work based on these observations will have a significant impact on their ability to get the work done and done right. You will truly be supporting the team based on their delivery context.

Align

Status reports do a poor job of providing the trajectory of the product and do not invite co-creation.

Alignment with your team on their product strategy, roadmap, and backlog is a critical point of engagement. As outlined in the prior post, Agile Leader Pattern 6 for Building Awesome Teams: Serve the Team, one of the best things a manager can do to set up a team for success is to guide it to the right path. First, guide your team on its why and its purpose. Then, collaborate with the team on what it should build to achieve its why. Additionally, you can participate in user research and testing with the team to learn the “right” product to give users what they need.

Fortunately, Backlog Refinement ceremonies in Scrum provide a solid conduit for you to collaborate and align with the team on product direction. Figure B illustrates a sample backlog refinement cadence flow throughout a sprint. Managers can participate in each refinement activity to properly align and collaborate with their teams on product direction.

Through frequent collaboration with the team on product direction, the dependence on a status report diminishes further.

Improve

Status reports tend to focus on how well the team is performing against the baseline plan and ignore the requisite learning and change inherent in software development. Measuring against a baseline for a complex, creative, custom, and uncertain endeavor such as software development wastes time.

There is learning along several dimensions in software development:

• Scope: The team needs to learn the “Right” product that their users need. Through frequent user engagement throughout delivery, they learn the “Right” thing to build.
• Technical: The team learns the right design for the software—how to build it “right.” The right design emerges over time as the team develops the product.
• Social: The stable team learns how to perform optimally based on its unique makeup. A system of lightweight processes and tools emerges unique to the team’s context.
• Effort and Forecasted Delivery: The stable team learns over time how to relative size its work and how to forecast its delivery based on evidence of recent delivery performance.

This learning occurs in Agile through short feedback loops and small incremental changes that add up to significant evolution. Sometimes the team can iterate on their own, but at other times they need support from management to improve.

As shown in Figure C, there are four typical avenues for managers to support their Agile teams in their learning cycles—Sprint Reviews, User Discovery & Testing, Retrospectives, and Impediments.

Sprint Reviews

Sprint Reviews provide an opportunity to review the product output of the Sprint and reflect on how well it meets the desired user need and target business impact. This is an opportunity for the team to get feedback from stakeholders, users, and other interested parties on what the team produced. As a manager, this is a perfect time for you to keep a pulse on what the team is producing and give them feedback on the product output as they seek to meet desired user outcomes and business impacts.

User Discovery & Testing

As a team investigates options for addressing user needs, some options will be less certain than others. The less certain options will flow through a user discovery session using lower fidelity experiments. These experiments help the team to gain insight into whether the option will address user needs. As a manager, you can join these sessions with the team to gain empathy for user needs. This information will be critical context as you support the team in meeting these needs. Additionally, it puts a human need behind the scope, giving it more meaning than a status report could ever hope to portray.

The team may test a Sprint’s output with a group of users to see if it truly meets the user’s needs. These user test sessions provide a great opportunity for managers to obtain direct feedback on the outcome achieved and see what course corrections the team might need to make on their journey to emerge the “right” product.

Retrospectives

Status reports rarely report improvement needs. Fortunately, inspecting and adapting is core to Agile, providing managers with a wealth of information on how to support the team.

The team holds a Retrospective every Sprint to reflect on the way they work and identify ways to get better. Managers typically do not attend the retrospective. However, the team will often identify improvements that they cannot solve themselves. The team will raise these impediments to the manager for help. It is a good idea to check in with your teams after their retrospective to see if they need your support in resolving any improvement needs.

Some multi-team environments will hold a cross-team retrospective. It is common for managers to attend these retrospectives to contribute firsthand to the list of improvement needs and solution options for resolving those needs.

Impediments

Status reports are notorious for ignoring the problems that are impeding progress. The Scrum Master on a Scrum team is constantly monitoring impediments that are disrupting the flow of work. In many cases, the team can resolve these impediments, but occasionally, the team will need your support to improve the system in which they operate.

Typically, the team will raise impediments they can’t solve to you during the Sprint as they emerge without waiting on a formal ceremony or meeting. However, the team may also raise impediments in Backlog Refinement, Sprint Reviews, Retrospectives, and Scrum of Scrum ceremonies. Attending these ceremonies will provide you with additional touchpoints with the team on the wastes they are experiencing.

Conclusion

Without a status report, there are multiple behaviors you can exhibit as a manager to engage with your Agile team to Observe, Align, and Improve. These behaviors form the basis of the Pattern for Manager and Team Engagement. This pattern will provide a rich flow of information to you about the ground reality of the team so that you can best support them in getting the job done.

After experiencing the superior results of engaging directly and partnering with your team in this manner, the status report will be long forgotten.

---

Other Posts in the Series

• Surviving Agile Without a Status Report—An Introduction
• Surviving Agile Without a Status Report—Visualize the Work

---

Related Posts

• Overcoming the Fear of the Incapable Team
• Agile Leader Pattern 6 for Building Awesome Teams: Serve the Team

---

References

1. The Many Sides of a Gemba Walk, Russel Lindquist, isixsigma.com