Agile Development Blog

Over the last several months, I led four breakout sessions on Agile quality at our Agile Success Tour and in the process I heard these troubling comments:

“We don’t have enough time to test, because the developers give us working builds way too late in the cycle.”

“I wish our quality was better, but it’s out of my control to change anything.”

“Poor quality must be our fault as testers, since we are the ones responsible for testing.”

“We should test more, or we should develop slower, or we should specify our requirements better – that should improve quality.”

Agile development advocates that the whole team owns quality, but clearly many teams face barriers to accomplishing that goal. I’ve been thinking about these comments a lot lately, and I think the problem is that basic and predictable human responses are getting in the way of achieving higher quality.

You can certainly improve quality through changes in process (and many of those changes are at the center of Agile adoption), but more often when people ask me process questions, I hear teams struggling with the human aspects of those process improvements. By paying attention to the ways everyone naturally avoids responsibility, you will be able to move past the barriers that contribute to poor quality.

The best model I’ve seen for how to do this is Christopher Avery’s Responsibility Process. The basis of this model is that when problems arise, every individual goes through a very predictable series of thoughts that allow him to cope with what just happened, but also block him from moving into a mindset of learning and improving.

It starts with blaming someone or something. When you move past blame, then you justify the event with a story you tell yourself. Once you move past that story, then you turn the blame to yourself and feel shame. Acting on that shames often leads to feeling a sense of obligation. If the shame and obligation become too unbearable, then you will quit or detach to escape from those feelings.

All of these thoughts prevent you from taking responsibility and ultimately moving into a mindset of learning and acting. Sound familiar?

This same pattern subtly plays itself out every day for you and your team around you, especially with issues of quality. According to the Responsibility Process, there are three keys to taking responsibility: (1) intention, (2) awareness and (3) confront.

To learn more, I encourage you to join me and Christopher Avery for our January 12th On Demand webcast, The Best Kept Secret in Agile Quality, where we will talk about :

• the relationship between quality and ownership
• the difference between accountability and ownership, and how this difference affects quality
• how the Responsibility Process can be used as a framework to continuously improve quality through a focus on people and interactions
• how to apply the Responsibility Process to your development team

I’m really excited about what we’ve put together for this and would love to see all of you attend.[Reserve your spot now by CLICKING HERE]

About the Author: Zach Nies is a golfer, expert on Agile quality and VP of Products at Rally Software Development. Subscribe today to get free updates by email or RSS.

Don't let this be your user!

Recently, my Rally colleagues Ben Carey and Ryan Martens delivered a great webinar about testing and quality.  What particularly struck me about the session was how Ben set up why we should, at a very personal level, care about testing and quality.

Enter Amy and her daughter Morgan.

As Ben told the story, Amy was a back office admin in a physician’s office. It was her responsibility to get billing out to insurance companies for the practice, and on one particular day, things were not going well.

She kept getting cryptic error messages. The batch just wouldn’t go through. Stress mounted. To add to Amy’s distress, it was nearing time for her to pick up her daughter Morgan at school. Morgan had just started school. Only 4 weeks in, Morgan was suffering some separation anxiety. Amy felt the urgency to be there for Morgan as soon as school let out. And yet, she was stuck at her desk dealing with these insurance issues.

Why should Ben be talking about Amy and Morgan in a webinar about testing and quality? Because Amy was Ben’s customer. Ben was on-site to see how his software was supporting the practice. And so, he personally felt Amy’s mounting stress in using the software HIS team had delivered and HER doctor’s office had paid for. When Amy started to cry, it was all over for Ben. He had to do something.

What does Amy and Morgan’s story tell all of us?

1. Users deserve better than this.

2. On an Agile team, quality is everyone’s job!

We often think of testing as an issue for the tester role alone.  But this stance sets a number of bad dynamics in motion:

• When we don’t fix defects, we declare doneness by “hiding” defects in a defect backlog
• Hidden defects accumulate into hidden technical debt
• Technical debt slows down our ability to deliver subsequent releases
• An ever-increasing defect backlog can be demoralizing for the entire team
• Engineering resents the business when being forced to deliver features when the engineers know defects exist
• Business resents engineering for not being better and faster at building features
• Testers resent testing left until the end because it puts business, engineering, and testing in a tight spot

So here is a thought: quality is not just an engineering issue; it is a systemic issue. That is, it is driven from the top down in a business not from within one part of the organization. A business policy about quality impacts our users by directly impacting their quality of life. Amy’s stress about picking up Morgan from school could be traced back to a testing and quality policy in engineering that was driven by a policy in the business: get features out.

As you adopt Agile, work vigorously to create rigor in your testing and quality goals. Why? Because your policy can hit hard in ways you don’t currently track. Pay attention to more than just the internal cost of technical debt. Let’s pay attention to the quality of life of our users.

The next time you are logging a defect versus fixing it, don’t forget about your Amy and Morgan.

About the Author: Jean Tabaka is a wine enthusiast, author and Agile Fellow at Rally Software Development. Subscribe today to get free updates by email or RSS.

Introducing Rally's Engineering Blog

As some of you have already begun to notice, the Rally Engineering team is now in full effect with their very own Blog.

This blog provides a great opportunity to (1) gain further insight into Rally’s development environment, (2) ask questions and interact with a high performing Agile engineering team and (3) learn tip’s and tricks from the team’s experience working in a wide variety of technologies.

I have read all their posts and there is something in there for all the rolls and levels of experience on agile teams.  It is unique because of the open authoring model for all members of a fast growing set of agile teams.

With 15 posts published, and many more regular contributions on the way, I invite you to join me as a new subscriber to Rally’s Engineering Blog (click here to subscribe and here to visit the blog)

About the Author: Ryan Martens is a fly-fisherman, founding board member of Entrepreneurs Foundation of Colorado, and Founder and CTO at Rally Software Development.

Your company is insane and you might be insane, too.

I bet you’re suspicious right now, aren’t you? You think this sensational opener is there just to suck you in and get you to read something that’s totally unrelated. Well, I mean what I said. Let me explain.

There’s this old joke. I think it’s a joke. Maybe it’s a saying. Or it could be an adage. I’m pretty sure it’s not an axiom and I know it’s not a koan. Hmmm. Might be a riddle. Anyway, where was I?

Oh yeah. The joke. It goes like this:

Q. What’s the definition of insanity?
A. Doing the same thing over and over again and expecting different results.

OK, so maybe “joke” was stretching it a little, but it is kind of pithy, don’t you think?

Why do companies want to adopt Agile methods? After all, it’s expensive and painful what with all the training and change management and readjustments and FUD (Fear, Uncertainty, and Doubt) and so forth. And why do people come to CSM courses hoping to find new ways to build software? Because they’re bored and they want to get into arguments with their management? Probably not.

I think the reason is the same for both. It’s because pretty much everybody wants better (different) results from their software development efforts. Management wants more software to sell, and they want it to be higher quality, and to arrive faster, and to be more liked by their customers.

Employees would like at least an even chance of succeeding in what they do, and they’d like to feel like they are contributing the best that they have to offer as a valued part of their company. They want to feel like an accomplished, highly skilled professional and not some interchangeable cog in a soulless production machine.

OK, fine. So far so good. Everybody is aligned. It’s win-win all around. What could possibly go wrong? Well, here comes the funny part. Nearly all companies, nearly all management teams, and many employees don’t seem to understand that getting different results is going to require doing different things, or doing things differently (I’m not sure if those two are the same or not).

When I’m teaching the CSM course or introducing Agile at a company, the minute I bring something up that is actually, obviously different from what they are doing today, somebody gets upset.

When one of my students gets upset, they start raising objections such as:

“Oh, well, we can’t do it that way at our company.” (Betcha you can.)

“That’s not how it is at our company.” (Isn’t that what I’ve been trying to tell you?)

“But what about having the complete architecture before I start? I have to have that!” (Should I do this the nice way or the mean way?)

“We can’t do all of that testing. We don’t have testers.” (Gosh, I hadn’t thought of that. I guess you’re right. Just do the Agile without the testing and you’ll be fine. I’m sure no one will notice.)

“We don’t actually have anybody who could be the Product Owner.” (Do you hear what you’re saying?)

“We have a very mature phase-gate development process that we have to keep in place as we move to Agile.” (Say what????)

“I’m a manager and I’m paid to leverage my maturity and experience by telling people what to do so they don’t make mistakes. I’ll be doing that with the Agile teams, too.” (Don’t roll your eyes…don’t roll your eyes…)

“Our QA is in a separate group and they won’t talk to us until we have a complete set of specs to give them.” (And how’s that working for you, and them, and your company?)

And on and on and on. I talk about this when I teach Agile to new teams or new CSMs and CSPOs. Then later on during the class, when they start in with this stuff, I can get away with saying:

“Oh! So you mean your company is insane. They sent you here to learn a new way to build software, but they won’t let you build software in a new way!”

This is fun because I get to call companies and my students insane in a way that’s fun and also makes a point.

What to do about this is a serious question for those of us who coach, train, consult, or champion Agile within our organizations. Teams tend to get it, but I fear that companies of a certain size tend not to get it. And they keep not getting it while their Agile adoption loses steam, fails to deliver as well as it could, and finally fades away entirely. This is where many of those “scrum failed” stories come from. What happened was that in reality, they didn’t really try scrum because they were afraid to change anything.

Your company is insane because what they wish is that you could somehow get all the benefits of Agile without making any difficult or scary changes. You might be insane because you think some things can’t be changed and we can still get the benefits of Agile without changing them. As long as either you or your company is insane, neither of you will get the benefits of Agile adoption.

I guess that’s all I wanted to say.

About the Author: Alan Atlas is a Musician, Certified Scrum Trainer, and Agile Coach at Rally Software Development. Subscribe today to get free updates by email or RSS.

Last Thursday, Ben Carey kicked-off our latest and largest webinar on the topic “How Teams Succeed with Agile Quality and Testing.”

Thank you everyone for the great compliments; a majority of the compliments should go to Ben, Jessica, Bob and the folks from SQE for the quality effort.  Thanks to these great folks, it was technically perfect, visually pleasing, entertaining, impacting and backed up by great supporting content.  If you missed it, you can see the video reply to this webinar.  You can find the supporting content under the Learn Agile part of the Rally web site.

Following that webinar, I saw a twitter post from one of our customers about the meeting they had following our webinar. This “Lunch and Learn” session allowed the team to reflect on what the heard immediately following the webinar.

“Having a post-webinar discussion with our SQA group on the #rallydev seminar. Nicely done @RallyOn & @BenCarey”

This is a great example of self educating on this topic.  It is the first of four steps that we recommend in the webinar:

1. Self-educate and discuss to set the context
2. Find an external driver for your change to keep from having drifting goals (customer, competitor, benchmark)
3. Make a commitment as a team to move forward
4. Find your first practice to adjust and adjust just that one only

If you liked the webinar and content, I encourage you to set up a lunch and learn to view and discus these topics on your team or program.  If you are interested in more depth, you might consider our next webinar in the series, Pulling Quality Forward: Agile Testing and Tooling for Embedded Software Development. The live presentation will take place on Wednesday, September 30th at Noon MDT with Zach Nies, VP of Product Development at Rally and Paul Henderson from WindRiver/Intel .  You can register on-line and learn more about the details.

I have found the quality topic to be great for team lunches.  It is can be a sticking point especially for functionally divided teams and quality has to be owned by the whole team.  I encourage you to take advantage of either of these webinars to hold a “lunch and learn” topic for your team. Maybe after your next demo and before your next retrospective.

About the Author: Ryan Martens is a fly-fisherman, founding board member of Entrepreneurs Foundation of Colorado, and Founder and CTO at Rally Software Development. Subscribe today to get free updates by email or RSS.

#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.

The LA Agile Success Tour concluded with 5 open space sessions. For my other live posts from the LA event, see:

• 5 Stories of Agile Success
  
• What Would You Ask Your CEO to Bring in Agile?

Did you find these posts valuable?  Any advice on how we can improve this for next time?

Agile 101, led by Christophe Louvion

What is your pain? Command and control, changing priorities during the sprint, hybrid process, making decisions outside the team that affect the team, improper tooling, moving resources around.

Root causes: Lack of self organization caused by lack of education, lack of an Agile driver, internal or external customer pressure, lack of executive vision, fear of change, skill set mismatches, ask teams to do things that don’t work well, lack of action items with a clear owner and clear deadlines.

Christophe had people in his breakout commit to action items. Christophe is going to call each of these people and verify if they accomplished their action items, like Lisa who committed to requesting a coach to come into their company and help them with their hybrid Agile process.

Get something small, but get it done!

Socializing Agile, led by Israel Gat

Pains: The sausage factory syndrome, the business doesn’t want to know how the software is made, but give me what I ask for when I need it. Market dynamics like drops in ad revenue and other drops in the market.

Solution: Innovation is now affordable because we can all experiment, try something in your sprint and if it doesn’t work out you only have 2 weeks invested. Read the book Innovators Dilemma by Clayton Christenson.

Risk management is important to executives, and Agile reduces it significantly. Money quantification, understand the value of what you’re delivering. Look at Capers Jones and his 2008 book Applied Software Measurement and his 2007 book Estimating Software Costs.

Agile Governance and Compliance, led by Laureen Knudsen

Pains: People live in rigid environments and don’t want to change. People don’t want to show their work because it’s too raw and there is fear around failing fast by validating your work with actual customers. There were questions about what is the earliest point to show things to customers.

Agile Collaboration, led by Jean Tabaka

Organizationally what is happening to enable collaboration? Organizations need to communicate down about vision, and the teams need to communicate up areas of process improvement. There was talk about servant leaders, and how command and control managers actually make people dumber. Most Agile teams start with iteration planning, standups and the end of the iteration demo.

Jean has a different view, called the 5 Levels of Planning.

Start with a Vision, this is the first level of planning that the leadership team owns.

Then move to a Roadmap where you talk about themes of releases. It’s important to talk in themes and the Product Council is the feedback mechanism for that process.

Then Release planning is next. It is important for everyone to be involved in the Release planning.

Then think about taking the Release theme and how the Iterations build toward that goal.

Then Daily examine what you did toward that goal yesterday, what you are going to do today, and what is getting in your way.

Each level then provides a feedback loop to the higher level of planning. At Rally everyone is involved in these 5 levels of planning within every department in the company.

Quality and Testing, led by Zach Nies (me)

Pains: Integrating testing teams in with development teams, making testing teams more effective and how to introduce Test Driven Development into the development team. An important way to integrate testing and development is to integrate and involve both roles in planning sessions. Testing should be part of the definition of done and involve testers in creating a story’s acceptance criteria.

The group talked about how to break down the walls between testers and developers, by focusing on the reality that everyone owns the quality of the software being developed. When testing is integrated into the process it makes them more effective. Finally, a few teams are trying to use Test Driven Development. Test Driven Development can’t be imposed onto the team, the key developers on the team need to lead by example by embracing TDD practices.

Part 2 in our discussion on successfully rolling-out Agile practices also comes from our Austin event where Jack  Yang from Homeaway spoke about a team-by-team approach. (See part 1 for more background on the Austin event and Israel Gat’s post on the Agile roll-out at BMC.) You can attend an event like this yourself in Denver Mar 18, Los Angeles Mar 26 or New York City Apr 2. It’s free, but you do need to register on our web site.

Please chime in with your success stories, or horror stories, on Agile roll-outs.

Implementing Agile Principles – Trials and Tribulations of a Team-by-Team Approach, by Jack Yang

I’ve had the privilege helping to roll out Agile/Scrum adoption here at Homeaway and a few other companies. At HomeAway, the process of adoption wasn’t simple – we faced a series of obstacles and false-start attempts until achieving a mature company-wide development process. Throughout the technology world there are many proponents for and against “all in” or team-by-team approach. In retrospect, given the challenges we faced as a company, the team-by-team approach was ultimately the most successful for us. I have no doubt that, given a different set of starting parameters, a large full-scale implementation throughout an organization could be successful. My belief, however, is that most teams aspiring towards an Agile process (which ever flavor it may be), start with a grass roots movement that requires careful proof of value. This may preclude the ability for a large rollout. To get a better understanding on how the HomeAway development team rolled out Agile, it is important to understand the environment of the company and how we, as an organization, happened upon trying Agile and the various barriers we faced, and continue to face, in becoming and staying Agile.

Homeaway.com, was launched in June 2006 to consolidate a cottage industry of vacation rentals and transform the industry into competitive alternative towards traditional vacationing. It is important to note that HomeAway is an aggregate of five smaller companies. The consolidation of HomeAway’s smaller companies did not happen over several years, which may have allowed for careful absorption of technology and staff. Instead, it started with a large buy-up that continued over the next three years as we continued rapid growth through acquisition. Each company brought new technologies, differing levels of development experience, and cultural backgrounds. Business units that were formerly autonomous were now required to play in a larger field that had differing often competing interests. The headquarters suddenly became the “mothership.” Satellite offices were cautious of change and each of the formerly autonomous businesses were highly profitable and had been operating that way for some time. Ultimately, however, we needed to create a consolidated brand. That meant everyone had to effectively work together. The company’s executive team focused on getting the each brand (or business) running in the same direction. This meant the development staff was now committed to many releases and ad-hoc requirements that changed often

The early days at Homeaway were challenging. My team at the time consisted of four engineers and when they tired of the poor release code quality, a brittle production environment, and long deployment times (at times, it took the team up to nine hours to finally roll out to production), we were driven to come together and commit to a different process. The team was made up of several seasoned startup veterans and a few developers new to the startup environment. We decided as a group that our ad-hoc “Agile / Waterfall” process did not work. Instead, we needed to pick one methodology and stick with it. We began with the following mission, “Follow the book to the letter to start, slow down to one single story and get it done with quality” and a philosophy that our one QA team member was the most important person on our team. I had the fortune of having a Product Owner that understood and shared in my team’s frustrations, so I had buyoff.

Within a couple of months, we were one of the most productive teams in the organization, producing quality code that carried less than 10 defects from sprint-to-sprint. Going Agile was a big part of the success, while facilitating adoption and enforcing of best practices was the other piece. Our particular product didn’t generate the most revenue for the company, but the sudden boost in speed quickly drew attention from senior management.

At this point, the management team decided to split this team and reseed the rest of the development organization with Agile members to help spread out the knowledge all at once. We hired a coach who focused on certifications for a few U.S. developers first, and then went overseas to train and convert our European counterparts. So, we essentially tried to rollout Agile throughout the organization in an “all in” approach. However, this failed on a global scale.

Here is why that approach did not work:

• The individual seeds had the monumental responsibility of convincing their new teams to do something new.
• Development managers felt they were being told how to run their teams.
• Product Owners were accustomed to using existing requirements binders and were unwilling to give them up.
• Product Owners lost the ability to ask developers “can you just fit that one feature in?” and felt like they lost control over their product.
• Evangelizing to an entire office that didn’t buy-in/understand the process resulted in many individuals paying lip service to the new process – “We’ll do it the old way when no one is looking.”
• Developers were used to hacking in features and deferring technological debt. They were now being asked to cleanup as they went along. In their eyes, this meant they weren’t moving as quickly as before.
• C-level executives didn’t see the same ramp up of quality and withdrew their support for Agile.

During this period, I was asked to form and staff up two new teams around key company initiatives. I was allowed two seed team members from my old team and then hired new employees. The failed attempt of Agile adoption across the organization put the newly-formed team at a heavy disadvantage when we elected to follow strict Scrum practice. However, the two new teams carried on, despite doubt and pushback from senior management and product teams.

Eventually, we launched the projects on time and with high quality. Using historical data, I was able to demonstrate costs on new projects and give visibility to team progress. This was a turning point for the company. With three teams having successfully implemented Agile, there was no question it could work and the first team’s success was no longer viewed as just a fluke. This time, with the support of the CTO, we resisted splitting the teams. And, the technological debts of “getting things out” and “not doing the right thing” caught up with the teams who were resistant to Agile practices. As each team got fed up with a lack of quality and inability to deliver, they began looking to the teams who were surpassing their goals and asking for help. This time change was socialized. More importantly, we were now rolling out teams in a methodical team-by-team approach, rather than trying to rollout all teams at the same time.

Here is my analysis of why we ultimately succeeded on this second attempt at rolling out Agile practices:

• Teams that ask for help are more likely to implement, as it is “their idea.” The best way to encourage teams to ask for assistance is to show them how much better it can be.
• Due to lower technology debt overhead, professionalism and disciplined work over the medium to long term will outpace “cowboy startup” teams.
• C-level management responds to hard data and winning their support the second time around was critical to our ability to implement and manage the process across our global offices.
• All Agile methodologies require discipline. From discipline comes professionalism and teams saw they were being treated as professionals instead of hackers.
• Professional teams developed a high degree of trust, making them even more effective and eliminating egos.
• As more teams come online the process of conversion accelerates.

In summary, I believe that most companies have a very traditional core belief system and value waterfall development. They tend to be afraid or not educated on the benefits of moving to an Agile philosophy. If this is true, the only way to spread Agile would be one of two ways:

1. Either through a team-by-team, grassroots approach as demonstrated above
2. Rollout Agile from the top down, with executive team support

Executive teams tend to be conservative when it comes to changing their core beliefs and will naturally wish to only “pilot” a team to begin. This obviously leads to a team-by-team approach. My view is the amount of change that needs to happen to perform an “all in” rollout within a large organization is riskier than the same approach used with a small company. The odds of failure anywhere in the system are high. However, when driving adoption, the consequences of failure were so high that we didn’t feel like we could risk an “all in” approach as we feared we would be in a worse place than when we had first initiated the change.

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.