Through two notes out this week, Cisco shows that software agility can scale to organizational agility. This YouTube video demonstrates the software agility of their NMTG group in Israel. (Note the Rally screen shots.) This CIO Magazine blog post explores the way Cisco is breaking its internal structure into self-managing Scrums for organizational agility. This bold move could certainly be called the organization of the future.

Running the Product Council for Rally ALM has been an interesting learning experience.   Any time you take a group of VPs and directors from a rapidly growing business, put them together in one room, and ask them what your product should do, you're setting yourself up for a challenging and possibly contentious conversation.  Each person has a different set of responsibilities and motivations.

At Rally, Evan  (VP of Services) wants to make sure we're building the features that our coaches can use to help customers be successful with Agile.  Don (Sales) wants to make sure we have a competitive product that solves the problems that prospects care about.  Marc (Support)would like us to build features that solve problems existing customers struggle with.  Dan (Partners) wants to support partners who are building integrated solutions.  Mark (Integrations) needs API capabilities to support his team.

It's critical to get input from each of these different groups, but often there is no correlation between their requests.  Marc's existing users might all be clamoring for the ability to re-arrange a particular screen, but Don's prospective users are so thrilled to have the screen at all that they don't notice it could be improved.

Without good facilitation, it's easy for a group like this to get mired in conflict and disagreement.   I've found that if I don't spend enough time preparing for the meeting, it's really easy to have conflict erupt during the meeting and derail the process. 

Over many releases with this group, I've learned six things that seem to make a big difference for this group.

1. Don't go too small or too techncial.

If you ask a VP-level stakeholder to choose between a big strategic feature and a normal-priority defect, what's going to come first?  The feature.  It's easy to assume this means you shouldn't waste time on small defects or usability improvements.  This is a dangerous assumption that takes you down the path of buggy software to the valley of angry customers. 

When you mix backlog items of different sizes, the small items will tend to sink to the bottom, like the vinegar and herbs in a homemade salad dressing.  The only way to get small items to stay suspended in a salad dressing is to add an emulsifier, like mustard or guar gum.

Fortunately, Product Owners can act as a good emulsifier for your backlog.

We've found 3 categories of items that should definitely be handled outside of the product council process:  defects, small usability enhancements, and technical debt.  The first two should be managed in their own backlogs and blended just-in-time into the Product Backlog by the product owners, each iteration.  Technical debt should be managed by the technical team and blended in during each iteration.

2. Abstract solutions don't sell themselves.

If a customer tells one of our account reps they want to "track individual availability across iterations", it's easy for us to write a set of stories, vote on them, and implement them.   By default, a new product council group that's run purely democratically will do lots of these stories, but that's only because clearly defined features that the customer asks for by name are easy to prioritize.

But there's often more leverage in building features that solve more than one problem at a time.  If I can build a new feature, like "contextual highlighting", it might solve many different customer problems at the same time.

Unfortunately, nobody is asking for "contextual highlighting".  Customers are sending very concrete requests to the support team, saying they want us to "make the parent story name visible on the backlog page".  Prospects are asking sales reps generic questions on how they can "track status on larger initiatives within the release".  As a product owner, it's your job to design the abstract solution that hits all of these problems at once.

If you show up at a Product Council meeting and add "Contextual Highlighting" to the list, none of your stakeholders i's going to vote for it, except the one guy who was an engineer 10 years ago and still misses writing code.  For the rest, even if they get it after your 5 minute explanation, they're not going to remember 2 weeks later what the value.

You need to pre-sell this kind of feature, 1-on-1, with each member of your product council.  This takes time. You also need a name that incorporates the benefits so it's easy for everyone to remember why we want this.  "Contextual Highlighting for Large, Complex Projects" reminds stakeholders why the feature is a good idea.

3. Build lightweight business cases

If mob mentality is ruling your product council, it's really easy for not-so-good ideas to float to the top.  Got a stakeholder who's demanding that you translate your product to French so he can sell to the Québécois this month?  Before you launch into a project like this, someone needs to figure out exactly how big the market is and whether it's the right market to go after right now.  I require my stakeholders to produce a high-level business case (less than a page long) before we'll begin researching an epic like this.  We need to know at least:

• How many customers are requesting this feature?
• How many customers does this feature benefit?
• How many users does it benefit?
• Would this feature have a negative impact on any of our customers or users?
• What is the cost of not building this feature?

Since there's always an infinite pile of good ideas, this helps ensure we only spend time on the ones that have clear benefit.

4. Not every feature is ready for development next release

Sometimes the Product Council gets excited about building a new feature, and tries to rush it into development before we've had a chance to think through the risks.   The Agile process reduces the risk associated with this, in that a bad idea almost always gets stopped after an iteration of development.  But for me, each development hour is precious, and I can't afford to waste any development time on something that isn't definitely going to be good for our customers.  One way to think about the Product Council process is that it's designed to optimize a continuous flow of stories to the development team.

To make sure half-baked ideas don't hit the development team, we have started to stage our epics through 4 backlogs:

"Ideas" are things we've talked about, but that have never been evaluated in depth for size or feasibility.

"Exploring" items are currently being researched by Product Owners and others, but are not quite ready to be developed.

"Ready For Development" includes items that the Product Owners feel are understood well enough to be pulled into Release Planning.

"Work In Progress" items are pieces that we've started but not finished yet.  In the past, we've sometimes moved on from a feature before we get to some of the lower-priority parts.  By keeping this list visible, we're reminded that we want to finish the things that we've started before moving on.

5. Value all ideas

Every week, my stakeholders run into customer situations that could be greatly improved through the addition of a new feature.  It's easy for them to get passionate about this feature, even if we've already discussed the idea and decided that the big-picture business case isn't there.  If you allow endless rehashing of every issue over and over, the product council loses its focus, but if you don't provide a context for the issue to be raised, your stakeholder will find a way to bring it up anyway.

The "Ideas" backlog is the receptacle for these items, but this only works if it's visible during the meeting.  If the item is already in the "ideas" backlog, ask the stakeholder whether it's time to revisit the business case for the item.  

Again, there's an infinite number of great ideas and a finite amount of development resources.  The vast majority of great ideas are not the right ones to implement now.   The process needs to block the so-so ideas and only let the excellent ones through.  

But as market needs shift, last quarter's so-so idea can become this quarter's excellent idea.  Your process needs to allow re-examining these old ideas from time to time in case they've become more timely.

6. Think Roadmap, not Release

This has been a tricky thing for our group.  In the past, we oriented the Product Council toward preparing for releases.   But since we work on an 8-week release cycle, and we have limited capacity, many stakeholders have to "sit out" releases while we build features for other constituents.  Focusing the product council directly on a release makes the meeting more contentious.

So for 2009, we're restructuring our meetings more towards managing a continuous flow of work through our 4 backlogs, and talk more about prioritization at the roadmap level.

Improving the product council is an ongoing process for us.  What changes are you planning to make with your product council or stakeholder group in 2009?

I have been thinking about and recommending the practice of Slack quite a bit recently. An attendee to one of my workshops just asked me to explain again why I asked him to reduce his committed capacity from 120% to 70%. He wondered why we wouldn't strive for 100%. I started to respond and then remembered a great post on the topic I wanted to reread.

From James Shore: http://jamesshore.com/Blog/Slack%20and%20Scheduling%20in%20XP.html

The most insightful statement he makes (at least for me) is: The more often you face these issues [customer unavailability, technical debt (including design debt)], the more unpredictable your environment is, and the more slack you need in order to meet your deadlines. In the case of technical debt, you can even use that slack to eliminate the problem!

I think that the amount of capacity you leave uncommitted is correlated to how much unexpected work and doubt you have going in to the iteration. Remember, we are trying to create visibility and become predictable. So we need to not over-commit. If you have interruptions, unexpected complexity and other challenges popping up in your iteration, then your estimates are going to be less accurate. When this is true, you need more slack in your capacity to allow you to deal with all of this uncertainty.

So, I didn't feel like I could give him an exact number, but I suggested trying an experiment.

• Try not committing to more than 70% for a couple iterations.
  
• See how it goes.
  
• If you consistently finish all of your work with little time to spare, that's the right number.
  
• If you consistently finish and need to take on more work, increase to 80% and test again.
  
• If you consistently keep ending the iteration with work still to do, decrease to 60% and test again.

Zach Nies brings close to 20 years of engineering and product development experience to Rally’s innovative products. Prior to joining Rally, Zach served as Principal Architect and Director of Systems Architecture for Level 3 Communications and founded a small start up which was quickly acquired by the publicly traded Creo, Inc, now a division of Kodak. He also served as Chief Software Architect at Quark, where he provided the overarching technological vision for the company. Zach’s product vision has won numerous industry awards, including Jolt Product Excellence awards, Seybold HotPicks and the prized MacWorld Best of Show. Zach has served on standards bodies such as the W3C's HTML working group and currently serves on the board of directors for Agile Denver.

Q: How does Rally do release planning?

Zach: To prepare for release planning, we have a Product Council process to involve the business in our planning cycles. The Product Council is made of stakeholders across the business and helps the Product Owners with the prioritization of backlog items. This is a key feedback loop where the business can be part of the release and roadmap planning cycles.

We release every eight weeks and for each product line, there is a four meeting cycle for the Product Council. This includes a retrospective meeting, a meeting where everyone brings in their business cases for a specific feature or enhancement, a presentation of design continuums for epics, and finally, a presentation of the release backlog. The product backlog from the final presentation goes into release planning. For release planning, we follow the agenda recommended by our Services team and our Uber-ScrumMaster facilitates it.

The high-level agenda includes:

1.       The teams are presented, along with any other commitments individual team members might have during the release, such as vacations or upcoming time off.

2.       Issues and impediments that would hamper team’s ability to make commitment to the release are presented and cleared.

3.       All Product Owners present backlogs for each Scrum to each team.

4.       Metrics and the definition of “done” is established and agreed upon.

5.       Release date and iteration time boxes are agreed upon.

6.       Teams then go off to map out the backlog against iterations in release.

7.       Once the teams have met separately, all teams come back together and each team presents to the whole group to show how a story is laid out across iterations.

8.       Each team identifies dependencies, conflicts or issues of how stories are mapping out across their iterations.

9.       All dependencies and issues are cleared out, and stories are potentially moved around as needed.

10.   Fun event for release is then decided upon. Past events have included Wii bowling, poker night and a foosball tournament.

11.   The entire team commits to the release plan with a “fist of five”.*

12.   Finally, a retrospective on the meeting is completed.

During the release, Product Owners are working to prepare for the next release. The Product Council is where the planning and preparation that the Product Owners have completed is presented to the business.

Q: How do you do long term planning (i.e. roadmap)?

Zach: Product Line Managers build a rolling twelve-month roadmap. Then, Ryan (Rally’s CTO) and I look at the alignment of the product lines and ensure we are optimizing for the whole of the business. This happens each quarter in conjunction with Rally’s quarterly business planning cycles.

Annual business planning and quarterly planning cycles serve as the feedback loop for the planning we do for the product.

Q: How large are your teams at Rally?

Zach: We have teams of seven, plus or minus two, so Scrums are never bigger than nine.

Q: How does QA work with engineering? How are they organized?

Zach:We have one manual tester on each Scrum. This person is responsible for manual walk throughs of the application in a way that represents the end user. But, it is important to note that everyone on the team is responsible for quality. All engineers write unit level tests, along with automated functional testing. PO’s, testers, and engineers all conduct manual end to end testing of functionality.

We bug bash at the end of every iteration. During our bug bash, a person from one scrum pairs up with a person from another scrum and they get together to test new functionality built during the iteration. At Rally, we have a zero defect mentality and we always try to fix bugs before working on new functionality. Having fully tested software without any bugs is part of our definition of “done” for new work.

Q: Does Rally do TDD (Test Driven Development)?

Zach: Yes, you can find out more information on this in the interview with Bob Cotton.

Q: Do you use points or hours?

Zach: We estimate in points for stories. Points are a relative estimate of size, not duration. In order to get accurate estimates for future work, relative size is more important than duration. We then estimate tasks in hours.

Q: As an Agile organization, what is your PO (Product Owner) team’s biggest challenge?

Zach: I would say their biggest challenge is balancing all that there is to do – the preparation cycle getting ready for next release, the preparation cycle for the next iteration, the day to day interaction with engineering and making sure they are not blocked by anything, and working with the whole team to make sure what is being built maximizes customer value. The PO’s put in a lot of time and energy balancing stakeholders’ desires – the business and the users. Here at Rally, we receive a lot of feedback from users on Agile Commons and from customers through RPM (Rally Product Manager). We use RPM heavily to help us prioritize and manage our backlog.  In a way, Product Owners have to ‘slice’ their brains between different members of the team and different time scales.

Q:  Any other tips, hints, or best practices for VP of Products or Product Owners?

Zach: I would recommend that they listen to our most recent webinars on being a Product Owner on an Agile team and on Product Management. I would also stress that it is important to have a Product Council or some sort of structured way to align the feedback of the users, the business and the development team.

*Fist of five:  Simple dispute resolution technique (used in a non-threatening environment) under which members of a group raise fist (to indicate a value of 0, or disagreement) or one or more fingers (to indicate values from 1 to 5) to express their level of agreement with a proposed solution, or understanding of a problem.

1. One finger = serious concerns that have not been heard or addressed
2. Two fingers = still have unaddressed concerns
3. Three fingers = consent with major reservation
4. Four fingers = consent with slight reservation
5. Five fingers = full consent