Agile Development Blog

When we started with Scrum at Rally years ago, we used to just do a design meeting every few weeks with a couple of key stakeholders to talk about what was coming up and prepare the backlog.   This worked relatively well, but as we added more discipline to our release cycle, the ad-hoc backlog planning our Product Owners were used to started to break.

If you want your team to be able to make a commitment around 8 weeks of backlog, you need to do somewhat more prep than you would with vanilla Scrum.  And if you want your team to meet that commitment, you need a mechanism to manage your stakeholders to minimize backlog churn.

About a year ago, we chartered a Product Council to solve this problem.  The Product Council is led by the uber Product Owner for each product, and consists of stakeholder representatives from all interested departments.  This team operates as lightweight Scrum that grooms the backlog for the next release, working in 4 meetings that are 2 weeks apart.

Meeting 1: Retrospective on the last Release

The first meeting falls about a week after the engineering team does Release Planning.  The Product Owners review the plans for each Scrum, talking through the stories for the stakeholders.  We’ll also highlight the work that definitely does not fit into the release.   Usually we have commitments from the development team as to what will be delivered.

We then ask people to rate how they feel about the product (what we plan to deliver) and the process (how we decided).  We tabulate these numbers, and then move on to a regular retrospective on the process – what went well over the last 8-week cycle, what didn’t go well, and what should be changed going forward.

Meeting 2: Bring Your Ideas

In the second meeting, we hang the roadmap and various backlogs on the walls – usability, platform, deferred defects, technical debt, customer requests, etc.  The Council spends about 20 minutes “walking the walls” – reviewing the roadmap and various backlogs.   People add items they think are missing, shift items forward where necessary, and talk about issues and concerns.  The purpose of this meeting is to identify those items the Product Owners should research for the next release – we usually leave with about 10 epics that need investigation.

Meeting 3: Presenting the Design Continuums

The Product Owners spend about 2 weeks researching those key epics, and come back with rough design continuums (backlogs) for each one and high-level estimates.  In Meeting 3, they present these ideas.  Sometimes an epic is too complex or unknown to be considered for the next release, or perhaps it’s too expensive to build given it’s value.  The Product Council votes to rank the different epics.

Meeting 4: Presenting the Detailed Backlogs

Based on the voting from the last meeting, the Product Owners go off and begin blending the strategic epics from the Product Council with small customer requests, deferred defects, and other small items.  In Meeting 4, we present the detailed, forced-rank backlogs that we intend to present to the development teams in Release Planning.   We talk about what’s changed and see if there are any last-minute, “Stop the line” type shifts that have to happen.  We get a fist-of-five commitment from the Product Council to confirm their support for these backlogs.

Moving forward, I’ll post more details about how these specific meetings work.

As I watched the Rockies sweep the NLCS I could not help but to think that the Rockies took advantage of Rally’s professional coaching services to help the team achieve success with their agile rollout. Let’s analyze baseball in regards to agile…

During the regular season baseball teams play in 3 or 4 game series, which can be thoughtof as an agile release. Each game in the series can be thought of an individual iteration with a timebox of 27 outs. The user stories don’t really change, a typical baseball iteration has 9 user stories (innings) with 3 story points each. The velocity of the team
really depends on the pitch count. If the pitch count is low we could consider the story to be completed faster than other stories in terms of relative sizing.

Similar to agile, the size of the team is nine players on defensive. These nine players work very closely together to complete each story and focus all of there energy on the current iteration (game). A team member grabs tasks (outs) when they feel they are able to take on more work. Team members regroup in between each inning for a quick stand-up meeting to discuss the next highest priority story (ok this is a long stretch but maybe they have a stand-up).

After the completion of the iteration there is always a retrospective (post game
conference). During the post game press conference (retrospective) the team manager acts as a scrummaster or coach and shields the team from media controversy. The manager is ultimately shielding his team from stakeholders (fans, media, owner) and focusing them on the current iteration (game).

At the end of a game (iteration) the team has completed 9 user stories and the team owner (product owner) either accepts the game or does not accept it (win/lose).

To end this fairly useless analogy we have to consider the post game celebration. Trust me the Rockies had one heck of a release party last night.

GO ROCKIES!

When multiple teams are working together on a project, there are many cross-team issues and dependencies that need to be resolved. Significant organizational change is generally needed to support agile development; often this change is more than one team can create on their own.

A Scrum of Scrums is a scrum team made up of representatives from each of several other teams. Usually the representatives are the ScrumMasters for each team, although sometimes technical leaders and product owners also participate. An Uber ScrumMaster acts as the facilitator for the Scrum of Scrums.

Just like a regular scrum team, the Scrum of Scrums works iteratively to deliver value in the form of removed organizational obstacles. Usually this group’s meetings lag just behind the regular Scrum meetings. For example, if the Scrum teams have their daily meeting at 9AM, the Scrum of Scrums might meet at 9:15AM.

Some tips to make this group successful:
1. Remove any unintentional or intentional hierarchy or power associated with this meeting. (This is only a role!)
2. Remind people of the intent and purpose: to remove escalated obstacles or resolve dependencies between teams
3. Have the SOS team create a backlog to work through iteratively
4. Engage the team in a mission/value statement exercise for clarity when stuck
5. For Daily Scrum of Scrums Meetings, stick to the point and stay after to solve problems, just like in the other daily meetings
6. Bring an expert with you or send him in your place if he is better equipped to solve the problem; it’s all about waste and obstacle eradication
7. Make SOS progress visible to the organization via demos
8. Hold retrospectives
9. Don’t give SOS power to inflict decisions on other teams

Consider this pattern when:

• You have multiple interdependent agile teams
• You have a large backlog of organizational impediments
• You are transitioning to Agile development

One of the 7 Principles of Lean Development, “Amplify Learning”, specifically targets the agile practice around “Inspect and Adapt”. In fact, the Lean Principle “Amplify Learning” is the predecessor to the agile practice. At the project level, you can think about amplifying learning in a variety of ways. Daily, we check in with one another about, “What’s happening that could be blocking us from success, and how can we adapt in order to remove that block?” And, at the end of each Iteration, a team pauses in order to demonstrate releasable tested functions (RTFs) and determine how to proceed in the next Iteration. They base their plan on a review of their successes and challenges in the last Iteration. So, what happens at the Program level when agile is being applied across multiple project teams within a Program? How do we still inspect and adapt effectively? This is where revisiting the Lean Principle “Amplify Learning” comes in mighty handy.

“Amplify Learning” means planning to experiment, checking the data around the results, and then incorporating what is learned. For Programs, this means deriving metrics that can be cross-team applicable, not just intra-team optimized. How do we accomplish this? That may require “leaning” on another of the 7 Principles: “See the Whole”.

Here are seven practices that “Amplify Learning” for Programs:

1. Use coordinated Iterations across teams to increase inspection and adaption

   Project teams within a Program manage their integration risk and sub-optimization issues by setting a common rhythm across all teams: one common Release Plan with the same number of Iterations, all of the same fixed duration, for all teams. All teams commit to the common plan in a Program-wide Release Planning meeting. Thus, at the end of each Iteration timebox, the Program Manager, Product Owner, representatives from each team, and stakeholders inspect the overall flow of the Program: Where are the bottlenecks? What resource constraints continue to grab us? What Program risks persist? Where are we slipping in quality or in function delivery at the Program level?

2. Increase osmotic communication

   Group programming and pair programming within each project team creates flow for each team. Optimizing flow for the entire Program relies on this team-level engineering discipline. When team members amplify their learning in this way, they promote rapid osmotic emergence and convergence of the useful Program-level standards and best practices. Norms across the teams buoy the stability of the overall Program.

3. Create total transparency across teams everyday

   Backlogs, burndown charts, and resource loading must be tooled and completely visible across the entire Program, regardless of the number of teams or locations of teams. A common automated Product Backlog coupled with an automated Iteration Backlog for each project team is a must. Programs require nothing less if they are to be able to amplify learning daily, from iteration to iteration, and from release to release.

4. Apply tools to maintain information and create visibility

   Programs must collect data (metrics) and incorporate learning across all teams in order to take advantage of the common rhythm of the team iterations. That means implementing tools that can manage the data, distribute the data, and then track the trends of the data iteration over iteration across all teams. A team-level dashboard as well as a Program-level dashboard has to be visible to all stakeholders across all teams. QA and documentation must have high visibility across all teams in order to plan aggressively and integrate fully for product release.

5. Hold daily Scrum of Scrums across teams

   Once each project team has had its Daily Standup, it’s time to check-in across projects via a meeting of the ScrumMasters or Coaches. In the Scrum of Scrums, a representative from each team checks in with the pulse of the team and turns to the other participants for assistance in removing impediments. Each day, the participants check-in with one another on their action commitments from the previous day. They amplify learning across teams in the Program by rigorously checking in with one another and upholding their commitments.

6. Hold a weekly MetaScrum across stakeholders

   Issues that extend beyond the authority or “radar” of the Scrum of Scrums elevate to a weekly meeting of the Program stakeholders. So, not just inter-team issues, but high-level Program-level impacts are addressed. The stakeholders commit weekly to the gnarly issues that can extend beyond the teams, the IT organization or even across divisions. Each week, each stakeholder is held accountable for having resolved the issue for which they took ownership in the previous meeting. No excuses. In this way, stakeholders inspect and adapt in an urgent, virtuous cycle, setting and meeting audacious Program goals.

7. Hold a Program-wide Release Retrospection at the end of each product release

   Once the set of Iterations timeboxes have completed, the entire Program must pause to evaluate the load and flow of the previous Release: What did we plan during the Release Planning meeting? What did we manage to accomplish by the end of the Release? What new practices did we invite during the Release? What worked well during the Release? What challenges hampered us during the Release? What trends in metrics did we notice over the course of the Release? What issues and concerns still exist? Given the Program team responses to these questions, the entire group then determines: What new practices should we implement in the next Release? What new priorities should be addressed in the next Release? How should we re-shuffle resources across teams? What goals should we set for the Release? What “inspect and adapt” practices need to be amplified?

Amplifying learning means attacking any issue, any risk, any impediment, any waste with a vengeance at any time. A Program that implements the seven practices of “Amplify Learning” listed above will reap the benefits of more reliable product releases through better planning and better responses to the uncertainties that may arise. Pause, refresh, retrospect, go. Do this daily, every Iteration, every Release across all teams and all stakeholders.