Agile Development Blog

#3 in our list of the Top Characteristics of an Agile Organization is Quality and Faster.

Ryan and I have been talking about quality and faster as necessary components of an Agile organization for awhile. A non-Agile view of a successful organization would have us believe that pushing more and more features into a release and to the market necessitates a loss, or at least reduction or great variance, in quality. In an Agile organization, the thinking is quite the opposite.

Curiously, when we speak of quality and faster inside Rally or with clients, we talk about each being indispensable to the other.

For a traditional, non-Agile case study, let’s look at the RCA case study Ralph Aguayo brings up in his book “Dr. Deming: The American Who Taught the Japanese About Quality.” At its height, RCA’s business model focused on getting as many televisions into the hands of consumers as possible. (Did your family have an RCA T.V. when you were growing up? Mine did!) Quality was secondary to the savings RCA could make from cheap components and speed of product to market. Cheap and fast meant greater profits. Well, as it turned out, no…

Nipper on RCA's first color tv set - the CT 100

Unfortunately for RCA, their model began to crumble when television sets started being returned due to defects, lots of them all still in the warranty period. The cost of attending to these faulty sets ended up being as much as 25% more than the cost of manufacturing the existing set.

Do you have a similar situation in your software product delivery? Are you trying to get profits by pushing features out with “defective parts” because they are “cheaper”?

And to throw another wrench into the works, are you taking so long to get these feature sets pushed out that you have too much of a delay in your feedback to find either the defects or the value of the features you pushed? In other words, is your emphasis on speed, at the expense of quality, coupled with very large feature-rich releases, exactly the wrong way to create greater value and fewer defects?

In an Agile organization, the entire organization concentrates on value delivery and quick feedback on that value.

That is, “are we delivering the right features to the market?” In turn, a real Agile organization understands, “there ain’t no such thing as a free lunch,” and they do increase throughput without the traditional expense of decreasing quality. Defects held in check through a “stop the line” mentality free-up the organization to always respond to value feedback information faster. Think about RCA. If your scarce resources are tied up in managing defects and “returns,” they can’t be working on new feature sets. Or the feature sets delivered are being pushed on defects not yet resolved.

And so, the notion of “quality and faster” is not so counterintuitive as we may have once thought.

We need faster and faster feedback loops in time-to-market in order to continuously improve our ability to deliver quality (defect-free and valuable) features back to the market. Symmetrically, we need higher and higher quality features that are not defect-ridden or dubious in value in order to respond ever faster and more innovatively to the market.

See our previous coverage of #10 Work/Life Balance, #9 Being a Servant and Leader, #8  Sustainable and Successful, #7 Contributing to the Community and the Company, #6 Collaborative and Smart, #5 Bottom-up and Top-down Decision Making and #4 Flexibility and Rhythm. Stay tuned for #2 “Creating Your Own Reality” and Corporate Vision.

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.