Agile Development Blog

This week, I had the pleasure of attending the seminar “The Way of Artful Making” presented by Rob Austin and Lee Devin , co-authors of the book “Artful Making”.

While I have met both gentlemen separately in the past and heard them both speak, this was one of those golden moments when I was able to hear them co-present. And for me, I loved the odd mixture in the audience: MBA students, MFA student actors, and software engineers. (Okay, guess which group I was in?)

Lee and Rob have a great “pairing” style in presenting. For those of you who don’t know them, Lee is a professor emeritus in Theatre from Swarthmore College. And Rob is a former associate professor at the Harvard Business School and is now full professor at the Copenhagen Business School.

In co-presenting, Lee and Rob take turns applying their perspectives about the look and feel of artful making. For Lee, this is about life in the theatre. For Rob, this is about great product development and, in particular, software development. So two great tastes that, as it turns out, taste great together (sorry, a reference to an old candy advertisement :)

So, what do actors and programmers have in common? Well, some amazingly fundamental things as it turns out:

• Iterative work
• Collaboration
• Innovation

Theatre work and product development both thrive on iteration and collaboration. Lee described this in terms of rehearsal and the emergent look of a play leading up to and even after opening night. Rob affirmed the value of a collaborative and iterative approach in product development and provided videos from Boeing and Bang and Olufsen showing how both companies take advantage of this approach.

What do these practices have to do with innovation? Well in both theatre and product development, Lee and Rob encourage us to embrace what should be the glaringly obvious; that is, iteration and collaboration invariably produce innovation .

What happens when you put iterations and collaboration together? Rob introduced us to a term he had learned during his study of Boeing’s use of iterations: “try-storming”. That is, instead of just brainstorming ideas (whether in theatre or in product development), take your brainstorm and try it.  Find something out about it as soon as possible. Then “try-storm” the next idea. (I think I am going to have to steal that term from him!)

I was also very fortunate to be able to sit next to Pete Behrens of Trail Ridge Consulting during the evening. Talking with him afterward, he reminded me of a few more similarities between theatre and product development:

• You need to be able to surprise people in order to create value
• If you don’t know in exact detail where you are going, it’s okay
• The ideal play/product you hold in your head is very limiting; let go of it
• In iterations, like rehearsals, each iteration may be or even will be significantly different from each other
• We’ve been able to move to being more iterative these days, more Agile, because of technology making it cheap enough to iterate
• Nothing is lost and wonders never cease as we build up each iteration from all the iterations before

Artful Making through iterations, collaboration and try-storming—all are important if you intend to be a theatre or product development organization that is truly innovative in the 21^st century. And THAT is what actors and programmers have in common.

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.

“You learn more quickly under the guidance of experienced teachers. You waste a lot of time going down blind alleys if you have no one to lead you.” -W. Somerset Maugham (1874 – 1965)

Filmed at Rally’s Agile Success Tour events, these videos detail the real-life agile implementations of software/IT executives who have taken the enterprise agile journey and are now realizing the benefits of enterprise-scale software Agility.

Our coaching and technical account teams (including Jean and myself) provided guidance to many of these panelists during their initial steps in their journey.  It gives me great pleasure to see them now become the teachers and share their expertise with the new generation of practitioners.

Don’t pass up this great opportunity to learn from the experiences of others!

click here if video player is not loading in your RSS reader

Catch the next Success Tour events in Boston, Seattle, Chicago and London this Fall
These events are free, but registration is required.

Never back down from an intelligent debate - or whatever these idiots are doing

The question over product management vs. product ownership is a huge issue that many companies face as they try to scale Agile. Dean Leffingwell just finished up a great series on Agile Journal in which he makes the case that the Enterprise Product Manager is Likely NOT the Agile Product Owner.

The Agile Journal article series is a great place to jump into the debate, but his blogging on Scaling Software Agility is also excellent and very deep – what Dean tends to call “pithy.” I am sure some of you will call foul with some of Dean’s points, but his methods have proven to be very effective with large-scale agility. I’d ask, are you skeptical based on personal bias or real Agile principles?

Here are four other resources that are great at analyzing product management and product ownership:

1. Enthiosys – I highly recommend their “Product Bytes” newsletter (Luke, Scott and Rich’s leadership here)
2. Pragmatic Marketing – They are shutting down my favorite Tuned In blog, but the others are also good and Tuned In has excellent archived topics
3. On Product Management – I love their lens on product management overall, not purely Agile
4. Accidental Product Manager – Very pithy blog on product management and timely topics

Final note to readers: Dean is a good friend of mine, and he helped me start Rally.  He is an investor and worked for us between 2003 and 2005.  Now he does his own consulting on large-scale Agile and continues writing for Prentice Hall.  I cannot thank him enough for his personal support in shaping my thinking around large-scale software development, building a network into some of the world’s best practitioners, and coaching me as an entrepreneur.  He is a passionate software craftsman.

Thanks, Dean, and very nice work on this critical topic.

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

2008 was a very good year for Rally, the Agile development movement and me personally.

At Rally, we measured ourselves by winning the third consecutive Jolt Product Excellence Award and delivering 6 product releases to a fast-growing list of great software-driven companies.

We leveraged our Agile and customer community and new products to deliver feature priorities based on our customer’s feedback and votes.

With the help of QSMA, we benchmarked that Rally customers are 50% faster to market and 25% more productive than industry averages.

On the local front we were named one of the best companies to work for in Colorado as well as awarded the Affiliate of the Year by the Entrepreneur Foundation – these are awards we strive for and help us validate we are building the type of company that can endure.

You can see the customer and financial growth that resulted from these market achievements in an announcement we issued this morning, or you can go to the Rally by the Numbers page on our web site to see the transparency we use to communicate our progress.

On the Agile industry front, the Agile Alliance had a blow-out conference in Toronto in 2008.  It was the culmination of my two years on that board and a very fulfilling experience.

We also saw this market grow with new customers and a host of incumbent as well as new competitors.

The Agile tools and applications market became real and Gartner put out a market map as a prelude to a magic quadrant; good news Rally was ranked in the “Positive” category.

What key performance indicators (KPIs) do you use in your business, and how will you improve or adapt them in 2009?

At Rally, we’ll be busy doubling our efforts to make our customers successful with Agile and effective on both prongs of short-term efficiencies and long-term growth.

Jeff Windman posted a nice little article on TechCrunch IT about Lean, Agile, Rally and Toyota.  Please join the deep and skeptical discussion.

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.

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)