Agile Development Blog

The other day, I noticed that the water is draining rather slowly out of my bathtub at home. That is annoying…

It means that I haven’t really kept my drain as clean as I should. Or perhaps I should be “snaking” the pipes more regularly.  One thing for sure, if I don’t get this fixed, eventually my tub will stop flowing entirely. If I try to add water, my bathtub will just overflow and I won’t be able to use it without a major plumbing expense. Ugh!

What does this have to do with my latest topic of cutting costs with Agile development? Well, I’ve been reading a great little book by Linda Booth Sweeney, When a Butterfly Sneezes. It’s a sweet, simple way to learn about systems thinking by using children’s stories for examples of various systems’ archetypes. To kick things off she uses a bathtub analogy to explain stocks and flows and how they impact one another.

Aha! That is what I care about when I am developing software!

Imagine that the faucet to my tub is all the features I am putting into my product. My bathtub is my product stock. As I add features, my bathwater level goes up. Now think of the drain as the “flow” by which I get the “stock” out to my customers.

If my drain is clogged up even a little, I can’t get the flow of features, my value, out to my customers as quickly as I’d like. And if I have a really bad situation, then I actually can’t keep adding features into my stock (my bathtub) because it will just overflow. Features (value) will never get to my customers. They’ll just end up as a major mop up for me, lots of work that doesn’t deliver anything but frustration.

So what are the clogs in my software bathtub? Defects.

A few defects unattended to will just slow down my value delivery. Not too bad. But if I allow defects to accumulate, that technical debt can bring my value delivery to a crawl. I’ve got lots of stock and yet my inattention to defects has cut off flow to my customers. Crumb.

Agile cuts costs because it requires us to keep our drain clean, not let defects accumulate. Agile guides us to not over-emphasize adding features to our tub while disregarding accumulating defect residue. Rather, we are guided to add high-quality features with a zero-defect mentality. Think of it this way -

Adding a little Scrum will help you eliminate the scum.

Now, whenever you are ready to open the drain for a release of software, there are no last minute plumbing repairs necessary to let the value flow. Keeping the drain defect-free means I can keep adding features into my stock and let them flow out anytime I want. I can even have sustainable, even continuous, inflows and outflows to and from my stock. The cost of delivery of value slowly goes down, I have sustainable and reliable flow, and all because I was willing to do a little continuous bathtub maintenance.

Don’t let defects clog your feature bathwater. Use Agile to stop the defect clogs and keep the value water flowing!

Further Reading:

• Sustainable and Successful – Top 10 Characteristics of an Agile Organization
  
• Agile Cuts Costs Through Time to Market Improvements
• Testing, Scaling and Tooling Agile – Open Space Topics from Denver

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.

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.