Establishing and Maintaining Top to Bottom Transparency Using the Meta-Scrum
Agile processes and practices have gained enough attention that both IT businesses and product development organizations are engaging in large Agile implementations. These larger-scale products, programs, and projects are more complex, have more dependencies, and present significant challenges.
Agile processes and practices have gained enough attention that both IT businesses and product development organizations are engaging in large Agile implementations. These larger-scale products, programs, and projects are more complex, have more dependencies, and present significant challenges.
According to the second annual "State of Agile Development" survey, Scrum (and Hybrid XP/Scrum) is being chosen over other Agile methods 60% of the time. For larger multi-team implementations, Scrum has an advantage of providing successful scaling techniques. For example, the Scrum-of-Scrums meeting helps teams synchronize and coordinate with the purpose of executing on the Product Backlog. When the Scrum-of-Scrums is insufficient because multiple organizational units need alignment, and consent must be obtained from high levels, the coordinating Meta-Scrum meeting adds balance because the Meta-Scrum is Product Owner focused while the Scrum of Scrums is team focused. Agile principles, including "Working software is the primary measure of progress," mean we must have a focus on releases - and releases are the primary focal point of a Meta-Scrum throughout the project lifecycle. A properly executed Meta-Scrum helps drive transparency vertically into the organization.
Expectations of a Product Owner
To set the stage for what a Meta-Scrum can accomplish, we need to consider what a Product Owner is expected to do. Scrum asks for a Product Owner to equip the team(s) with a vision and a list of prioritized items of work to be implemented. Scrum also asks the Product Owner to be able to evaluate the working software increments for potential release. Scrum further asks for expected business value and projected ROI to be available so the project can demonstrate the realization of value. If not, it may be usurped by something of more tangible value. The Meta-Scrum meeting follows a similar cadence like iterations to achieve an Agile rhythm . The meeting helps influencers evaluate and validate the Product Owner's work products and plans along with the value being achieved.
A good Product Owner of a large project has a significant amount of responsibility, as described above, in order to fully enable the team. As a result, expectations and constraints evolve from the effort to deliver what Scrum asks for. These constraints and expectations are often described in the form of high level requirements, budgets, and schedules. Since many organizations have complex environments, scale, and research methods, they typically have already adopted formal processes to help them define and prepare the information asked of Product Owners by Scrum. This work inevitably leads to some commitments being made, from plus or minus 10% to 50% of what was requested.[iii] This information represents the initial plan.
Increasing Transparency with the Meta-Scrum
Scrum provides frequent feedback through the empirical process control mechanism of inspection and adaptation. An IT manager recently described his career as one of "resolving tension." The release-centered focus of the Meta-Scrum helps reconcile the opposing forces of a plan's constraints, and the current reality revealed through the transparency of Scrum. However, in spite of the simplicity of Scrum, large initiatives are inherently more complex. Costs of scaling are often underestimated, even though they are well-documented. Barry Boehm claims this diseconomy of scale is caused by the time involved in increased communication.[iv] When embracing the feedback (good and bad) available through the use of Scrum, certain assumptions start revealing themselves as flawed. Risks become reality and changes become necessary. New information becomes widely known, even though this knowledge probably existed within someone earlier. These realities are at odds with the inertia of the initial plans because they threaten the initial plan. For these large initiatives, re-planning is very hard. A Meta-Scrum meeting achieves transparency so these tensions can be resolved by helping both responsible and accountable parties understand, coordinate, and respond to the release plans, along with any changes to the release plans, with the added goal of minimizing additional venues for decisions about a release.
Multiple Product Owners
Large initiatives tend to have several Product Owners. In this case, there must be one Chief Product Owner who reconciles the priorities of the other Product Owners. The Chief Product Owner is responsible for the plan and for conducting the Meta-Scrum meeting. The participants act as (are analogous to) a Board of Directors who review and approve the plan. The participants must have the authority to make decisions. Decisions need to be binding for the people in attendance. If someone is missing, that person must act in agreement with the decisions made in the meeting.
Important Artifacts in the Meta-Scrum
Tension can be identified and resolved when the business executives or Chief Product Owner is prepared with a roadmap that represents the desires of the business.[v] The Release Plan is created during Release Planning sessions conducted with the Scrum Teams and the Product Owner. When these two are not in alignment, the Meta-Scrum becomes the driver to get resolved.
Helpful Tools for the Meta-Scrum
There are two tools I find useful for encouraging the right discussions in a Meta-Scrum. The first one is shown in Figure 1: Example of a modified RACI chart applied to multi-level planning on Scrum projects. Notice the key difference between the Roadmap and the Release Plans. In this example, when release plans need to change and do not impact the roadmap, the Product Owners have the decision-making authority. Conversely, if the roadmap is affected, the Product Owners must get consent from the executives. The chart in this example has helped executives understand the levers they have and allows the decision authority of the Chief Product Owner to remain balanced.
Another tool that has proven valuable is Jim Highsmith's Tradeoff Matrix which is "an agreement among the project team, the customer (product manager), and the executive sponsor that is used to manage change during the project (Figure 2: Trade Off Matrix)."[vi] This helps stage the discussions by highlighting previous decisions about project constraints. For example, expected quality and date of release are often fixed or at least firmly defined. I saw the tradeoff matrix effectively used when the participants in a Meta-Scrum agreed to postpone a release due to a quality issue. The executives acted as a damage control team and decided how to handle their customers. They provided a much better solution than I typically witness without a Meta-Scrum. There was not any finger-pointing or bickering. The meeting ended on time with agreed upon action items and work continued on the product with the revised release target known by all. Everyone in the organization knew that there would be no changes until the next Meta-Scrum in one week, when the executives removed further impediments, re-established consent, or otherwise responded to current release-focused needs.
Conducting a Meta-Scrum
Conducting a Meta-Scrum requires a strong initial launch to set expectations. Responsible and accountable persons must attend this meeting and be prepared to make decisions or defer authority to the attendees of the meeting. This meeting should occur every week. A person who must miss a meeting for legitimate reasons regains influence the next week when he returns. This rule is critical to the success of the Meta-Scrum. Short meeting intervals also help prevent the need for back-channel or side-channel decisions that are more appropriately contained in the Meta-Scrum. A Big Visible Chart or handouts of the Roadmap should always be available along with Agile release plans. Discussions are centered around changes to the release plans. Obstacles and impediments are raised and action plans captured. Decisions are documented and notes published. It is useful when attendees include team representatives as observers to increase transparency.
Conclusion
In summary, unlike the Scrum of Scrums (where teams synchronize and coordinate with the purpose of executing on the Backlog), the Meta-Scrum focuses on executing on the roadmap and the strategy while eliminating side channel conversations about the releases and the roadmap. It is a gap reduction exercise. It is owned by the Chief Product Owner, who owns the plan. Successful Meta-Scrums provide consistent answers to the question: "Does a Chief Product Owner's Product Backlog have consent of all the Stakeholders?" The Chief Product Owner comes in to in the Meta-Scrum with the plan, discussing what is meant by plan, roadmap, product backlog, and other terms. Whatever you use, have it clearly defined.
Indicators for when a Meta-Scrum is needed include when you:
- Need to reduce chaos in the organization.
- Need consent at highest level of the organization.
- Are balancing multiple projects.
- Require alignment in multiple organizational areas.
- Are in an environment where change happens (there are surprises)[viii]
Scrum implementations are expected to resolve extraordinary issues in complex environments. Scrum is not a silver bullet; if you expect it to be, you are in danger of calling it the "flavor of the day" in your organization. It takes courage and a willingness to inspect and adapt to unexpected realities not previously revealed. There is quite a bit of industry experience and information available for people to establish and run a Scrum team successfully. There is also experience helping multiple teams coordinate and execute together. The Meta-Scrum meeting has helped me balance forces that create tension when trying to release products successfully. I hope this proves to be a useful tool in your toolkit.
About the Author
As chief technology officer, Brent Barton plays a key leadership role in implementing the strategic vision of SolutionsIQ as an agile organization, building SolutionsIQ's premium Agile development services and initiatives, while addressing such key issues as delivering greater value to customers. Brent is a Certified Scrum Trainer, Agile coach, and an international leader in Agile consulting. He brings more than 15 years of technical experience as a consultant and mentor to his role as CTO. Through Agile methodologies he helps companies successfully build software better, and faster. Graduating from San Jose State with a degree in Mathematics and a focus on Computer Science, Brent became a Certified Scrum Trainer in 2005 and has trained over 500 people in Scrum. He presented at the Agile 2007 conference in Washington, DC. on the topic of "Incubating Innovative Products Using Agile Methods."
[ii] http://www.scrumalliance.org/articles/46-advice-on-conducting-the-scrum-of-scrums-meeting
[iii] These represent "success" ranges in typical SDLC phases in several companies I have worked with. These percentages usually reflect schedules and dates against approved business or technical requirements.
[iv] Boehm Barry, Software Engineering Economics, Prentice-Hall, 1981
[v] For more on roadmaps, see http://www.pragmaticmarketing.com/resources/scaling-agile-processes-five-levels-of-planning
[vi] Highsmith, Jim, Agile Project Management: Creating Innovative Products, Addison-Wesley Professional, 2004.
[vii] The modifications of RACI when applied to Agile in this case is revealed in the shared accountability of teams in the Sprint Backlog and shared responsibility for removing impediments
