Agile Development Blog

If you have ever wondered what to do with the growing number of features in your software applications, you are not the only one. There is some useful guidance from The Standish Group survey quantifing that only 20% of all delivered software features are “often or always used.” For a team under the pressure of today’s economy to do more with less, here is a way to conceptually cut 80% of your effort and still deliver the high-value essentials. But wait it gets better. If you do not completely elaborate, build, test or document these features, you save once. But you also save again: with the future maintenance costs, the training users, the bug fixing and the regressing these features would have required. This is clearly the biggest lever for cutting software development costs using Agile. And yet it seems to be the hardest to attain.

Features used in Commercial Software - Reported by Jim Johnson of the Standish Group at XP2002

This pairing back to the simple, important few takes tons of discipline and that level of discipline is only be made easier as your agility maturity increases. Most agile books and coaches will call this the discipline of “Brutal Prioritization.” The folks from 37Signals call it: “Getting Real.” In either case, brutal prioritization means two things:

1. Not letting the fat slip into the backlog
2. Keeping the backlog prioritized by value and risk

First, lets talk about fat or wasteful features. Please note, fat or wasteful features come from all directions from the business and customers, but also from developers, support, and product owners. Your features may be fat or wasteful if they:

1. Do not help the most important user persona in your domain achieve breakthrough results or competitive advantage
2. Have not be proven to work and are based on a hopes and prayers
3. Look like pets that someone is protecting
4. Are weak features that degrade the product because they are not complete enough to meet minimum expectations

Photo © Tristan Savatier - http://loupiote.com/ - Used by Permission

So if you are in the customer role or customer proxy role such as the Scrum product owner role, the technical product management or a business analyst role, it is your job to control yourself and help the team to keep the fat off the backlog. If you are on the agile team, it is your job to keep these roles honest about WHY these features are so valuable. This leads right to ranking the items into a prioritized backlog. (A few comments in this area would be really helpful – let’s hear what you use to spot fat features?)

(more…)

In my post “What’s with all the Agile Process Overhead? Part 1″, I reviewed the contents of the Sprint  Backlog. Hold, commit to, and track items of value there. Nothing else.

I eluded to two other perceived Agile Process overheads, one of which I’d like to peek at today: how do you allocate your time effectively?

This came about from the same client discussion that prompted the post on the Sprint Backlog. In conversation, I discovered that the team believed that they had to be 100% allocated for the entire duration of their Sprint. Hence, the lengthy, detailed nature of their Sprint Backlog. Time to back up.

Team Members determine their ideal effort availability

We’ve already covered one problem with this allocation paradigm: you are tracking the wrong thing in your Sprint Backlog if it is not showing value-add work completion. Now, here is the second villain. No-one can accurately account for all hours of every working day as “ideal effort hours”; that is, hours of completely uninterrupted, undistracted work. Ravi Jha stole some of my thunder on this with his great comment to my previous post. Heed his advice from February 27!

Teams preparing to plan their commitment for a Sprint/Iteration look at their capacity; that is, how much work do we believe we can take on and complete by the end of the Sprint? As Ravi pointed out, a good team assumes from the start that it cannot devote a full 8-hours a day strictly to product backlog value-add work. A good beginning capacity number is 6.  Why 6? Because it is not 8. Until informed otherwise, of our 8-hour work day, we believe each of us can truly be heads-down concentrating for 6 of those hours. The rest of the time will be swallowed up by interruptions, emails, unplanned meetings, and other distractions.

Now, here is the sticky part. As I mentioned in Part 1 of this series, Agile teams must also take into account slack for what they can’t know. This is different than the 6 hour number of ideal effort hours. When we make a commitment in a Sprint Planning meeting, the commitment is:

• We are committing to moving forward with what we currently know so that we can continue to learn by building a potentially shippable increment of the product.
• Our intention is to complete all of these Sprint Backlog items based on the analysis and conversation that has happened to this point.
• We think it will take these many ideal effort hours and we believe we have this many hours available.
• Everyday, we will honestly evaluate how we are doing with our commitment so that we can improve on meeting this commitment AND improve on how we make commitments in the future.

Therefore, a team, not knowing what it doesn’t know, applies a certain additional level of slack or buffer to how it commits. Call this the “Commitment – Buffer of Unknownables” (or C-BOUs). Now the team that has 6 uninterrupted hours per team member per day may additionally say, “Our C-BOU is about 1 hour person right now per day because we just don’t know this product or this process very well. We don’t know what we don’t know, though we know we want to get better.” As the team evaluates the Product Backlog Items with the Product Owner, and as they determine tasks and estimates for this work, they are keeping in mind:

• what ideal hours they will need
• what ideal hours do they have
• how much C-BOU should they hold back

By the end of the Sprint Planning meeting, a commitment then truly represents:

• Items of value we intend to deliver
• Commitment by the team to learn about commitment
• Intention to use the buffer for what they couldn’t have known
• Agreement to evaluate the C-BOU at each retrospective to see if it needs to be bigger or smaller

Some teams call for a bigger C-BOU due to the volatility of their environment. (Okay, they prefer to say their business is very “organic”.) Tracking this capacity buffer is a great way to enable getting to the root of that “organic” nature. Without paying explicit attention to the truth of unknowns and the amount of time they take, a team and the agile project management can create waste and overhead. Teams go into a frenzy mode to meet a commitment that allowed for no buffer, no unknowns. Management applies pressure to meet the commitment despite the clear and present issues that are eating up the efforrt. None of these tactics improve team commitment; they create overhead, waste, and low morale. And they add the cost of manaing all three of these.

That’s it for Part 2. In Part 3, I’ll talk about how you plan for unplanned work, without using a crystal ball :- )

[ UPDATE:  Fall 2009 Locations have now been announced for Boston, Seattle, Chicago and London ]

In December 2008, we ran the prototype to our recently announced Agile Success Tour in Austin, Texas.  This event was extremely well received, and the majority of attendees would recommend this event to their colleagues.   Given the high satisfaction level, I can almost guarantee you will not want to miss the one nearest you.  So consider registering for upcoming events in Denver, Los Angeles or New York City.  Short of living in Chicago and attending Agile 2009 in August, it has to be the best way to learn from your local peers about the actual benefits and best practices of adopting, scaling and cutting costs with Agile software development.

I was the moderator at our Austin event and while there, we captured short videos of our customers/presenters.  These customer videos give you a sample of what you can expect to see and feel in your community.

The videos include comments from:

• Israel Gat – former VP of Development at BMC
• Jack Yang –Director of Engineering, HomeAway
• Gary Allison – VP of Engineering, Convio
• Erik Huddleston — CTO, Inovis

I really enjoyed two things about the event.  First, attendees got to hear and discuss multiple approaches to Agile adoption, tooling Agile lifecycle management and the business drivers that drove their move to Agile.  Second, the interplay between local leaders, including members of the Agile Austin community, resulted in shared learning while enhancing the local professional network.  In addition to a brief presentation by Israel, these gentlemen were all allotted enough time to share their stories, answer a few of my questions and field audience questions.  Following the panel, breakout groups allowed folks to dive deep on hot topics, get introductions to Rally partners and learn about major enhancements to Rally’s services and applications for Agile lifecycle management.  Of course the event was executed flawlessly by our great marketing team including Sonya Breakstone and Michelle Burrows, and was facilitated by Julie Chickering, our Texas-based coach.

The Denver event is set for Tuesday, March 18th in downtown Denver.   This event will include:

• Peggy Reed — VP of Development at Avaya
• Lloyd Star — VP of Engineering/Development at Beatport
• Pete Fischer — Product Manager at eCollege
• Ray Bagley — Director, Product Planning & Management at Spatial

The Los Angeles event is set for Thursday, March 26th in Manhattan Beach, CA. The event will include:

• Christophe Louvion, CTO at Gorilla Nation
• Laureen Knudsen, Sr. Dir. of Program Management at Qualcomm
• David Annis, VP of Software Development at UTI from Arizona
• Chris Babcock, VP of Technology at Real Capital Markets

The New York City event is set for Thursday, April 2nd. This event will include:

• Jochen Krebs, Dir. of Program Management at AOL
• Brian Stockmoe, Sr. Dir. of Program Management at NBC Universal
• Land du Pont, Executive Dir. of Product at Conde Nast Digital
• Micah Silverman, Founder & Principal at MPower IT

So, please consider sending a senior member or members of your team to learn from and share with your local peers.  Additionally, Israel Gat is slated to participate in each of these three events, where he will share his stories and insights from BMC and other Agile organizations.

Registration is online and is limited to the first 100 people.  I do not believe there is an event with a higher return on your personal investment for these times.  Agile is proven to dramatically cut costs and increase innovation in any sized software development team.  If you are not realizing major benefits from Agile in your organization, you will feel the pull to get started at this event.

As a warm-up to these events, you might also consider having members of your organization attend or view the recordings of a new, two-part Webinar series on  Agile Cuts Costs that includes Jean Tabaka and me.