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…)

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

There are several problems with traditional requirements formats

• They cost a lot of money to produce and yet you can’t sell them to your customers (waste)
• They can be monolithic (90 page use cases) and so they’re hard to manage when different pieces have different importance.  The desire to make them comprehensive loads extra work onto the development team. (strain)
• They take a long time to produce, holding up the development process and delaying the feedback that comes when users get to see working software (wait time)
• The more detailed they are, the more the team thinks they’re complete and the less critical thinking gets applied to them, leading to more defects (waste)

User stories are designed to address these issues.  A user story represents a small piece of business value that a software team can deliver within an iteration.  Here’s one:

As a customer, I want to check my order status online so that I can know when to expect my package.

There’s actually a lot in that little line – we know who the user is, what’s the activity they want to do, and what’s the underlying goal.

Ron Jeffries has said that there are actually three parts of a user story:

1. Card - the part we wrote in italics above.  It’s just a placeholder – a project management mechanism that we’ll use to remind us that at some point we probably should get around to building an order status thingy.  This part should be short enough to write on one side of an index card with a sharpie marker.  You could even word it “Order Status Checker Thingy” to emphasize that it’s a placeholder, not a requirement.
2. Conversation - When this card comes up in the stack as the top priority, the team will talk during iteration planning about the acceptance criteria that will need to be met to satisfy the customer or Product Owner that they built the right kind of “Order Status Checker Thingy”.  Sometimes the criteria are noted on the back of an index card or in an agile tracking tool.
3. Confirmation – The detailed acceptance tests that the team writes during the iteration to define exactly how an “Order Status Checker Thingy” should work, in excruciating detail

A user story is unlike regular requirements because the requirements aren’t specified in detail until the tests are written, around the same time as implementation.  Benefits of this approach:

• No inherent waste.  We’re only writing down as much as we need to document our conversations and make sure we’re all on the same page
• Encourages discussion. Your developers and testers know a lot about what they’re building.  They’re capable of thinking of important details and preventing defects and other bigger mistakes, if the process encourages them
• Easy to manage.  If you’re used to use cases, break down your scenarios and steps into stories.  You can do the important parts early and postpone the less important parts later.
• Easy to manage scope creep.  If you think of new things to do, create new stories and add them to your list in priority order.  Since you’re always doing the most important things first, you’ll end up naturally managing scope in a way you can’t when you’re working off of requirements documents.

(This is a draft – please add comments or edit the pattern itself)