Structured Agile for Product Teams

I teach a structured approach to Agile, developed by the Agile Academy, and adapted for larger organisations who assemble project teams to tackle all manner of projects.

In smaller organizations, development tends to be product- rather than project-oriented.  Instead of routinely assembling (and later dismantling) project teams for major projects (who then handover to standing business-as-usual teams for support and minor enhancements), there are invariably long-lived product-centered teams who perform a mix of new development, minor enhancements, plus ongoing maintenance and second-level support.

This product-team arrangement may be the wave of the future for larger organizations as well: the case for product-teams is eloquently (and vehemently) made by Evan Bottcher in his most excellent diatribe Projects are Evil and Must be Destroyed - read it!

Now product teams -- in my experience -- face a number of typical challenges, especially balancing different kinds of work, especially:

• major development initiatives
• maintenance (bug fixing) and other support needs
• minor enhancements

In the remainder of this post I'll describe how the four-phase, structured Agile approach outlined by the Agile Academy here (similar to AUP) can be adapted to meet the needs of product teams.  At a high level:

1. Concept phase
Project version: Assess the technical feasibility of a business idea.  Draft a "project charter".
Product version: Revise and update the vision  for the product; assess requests from stakeholders (or customers) for feasibility; choose the theme(s) for the next major release.  Update the "product charter".

2. Initiate phase
Project version: Review and refine the business idea for technical development.  High-level prioritization, estimation, and initial release planning for the project.
Product version: High-level prioritization, estimation, and planning for the next major release.

3. Deliver phase
Project version: Iterative and incremental development and delivery of working software.
Product version: Same, interspersed with maintenance and support.

4. Deploy phase
Project version: Rapid and secure deployment of software to required environments.  Handover to BAU team on final deploy.
Product version: Same, but no final and no handover.

Concept and Initiate still make sense, but happen periodically
The major changes involve re-purposing the Concept and Initiate phases to encourage long(ish)-term planning for product teams, centered around the next major release of the software.  This is an opportunity for the business and technical teams to put their heads together, assess and chart a way forward.

Distinguish enhancement requests from defect reports

With standing teams it is all too easy to go reactive, and treat feature requests similarly to defect reports: part of a long list of "to dos" that must be prioritized and got to.  This feels more efficient, but it may fail to reject suggestions and to sufficiently refine and combine the best ones.

The difference from the project situation -- where the Concept phase allows the team to advise the governance body to kill off projects early and cheaply -- is that in the product case the team must advice not whether but what to go ahead with: Are we funding a cohesive and worthwhile upgrade?  This requires discernment and perspective, and going back to stakeholders with counter-offers to their suggestions that enhance the design, experience and overall integrity of the software.

Set-up iterations?
A set-up iteration, usually branded "Iteration 0" takes place at the start of the Deliver phase.  In the case of Product teams, many of the traditional tasks for a green-fields project will not be necessary.  Nevertheless, periodic Iteration 0s offer the opportunity to improve on existing processes, as well as implement changes foreshadowed by the most recent Initiate phase.

Transitioning to Agile
In transitioning an existing product team to Agile, the first Concept and Initiate phase can be usefully devoted to getting the existing processes, team, and backlog of work "over the hump" and across into an initial Agile configuration.

Often challenges will include a lack of automated unit-testing, existing patterns and dysfunctions in engagement with customers, and the difficulty of unlearning old patterns of behaviour.  Early priorities will include getting the team trained up, working cross-functionally, establishing a stable iteration cycle, including daily stand-ups, iteration planning, showcases, and retrospectives, as well as breaking work into small chunks, estimating it and delivering in small increments.

Doing just enough to get the current backlog of work going without planning a new major release (just yet) is effectively a Hudson Bay start to an Agile future.  But remember: it's only a start!

Mixing bug-fixing and enhancement work
There's no one answer to this one.  Bug-fixes are typically difficult to estimate and often urgent, and this combination can play havoc with everything else.  The aim is minimize task-switching costs while maintaining standards of service.  The thing that will help is to lift the quality of the software and thereby reduce incidents.

Fewer Severity 1 reports mean fewer "all hands on deck" interruptions.  A long-term strategy to reduce technical debt, ideally using test-driven development, pair-programming and old-fashioned smarts is a great start.  Israel Gat suggestions monetizing technical debt to make it visible on the balance sheet.

Non-urgent fixes can wait (a bit).  One approach that I have tried is to schedule a day per week for maintenance -- e.g. bug-fix Thursdays -- but this is a bit inflexible.  Another approach is to estimate and schedule the fixing of reported defects in story points.  The problem with this is that estimating how long it will take to fix non-obvious bugs is uncertain.  Mike Cohn suggests another approach: assigning a few points of velocity each iteration to maintenance (convertible to the equivalent number of hours), and tracking the hours spent for reporting and to help guide future allocations.

Minor enhancements
Product teams should be brutal in only doing the most minor enhancements during minor (also known as bug-fix) releases, since such work sucks development effort away from the major-release work and needs to be merged back in, a source of overhead.  Also, the faster response-time may train stakeholders to ask for "minor enhancements" or insist that a feature request is really a defect.

An exception may be made if you have 100% automated test coverage and are practicing true continuous deployment, in which case you've achieved a higher standard of Agility than most!

Ranking Rummy

Where Planning Poker works brilliantly to estimate the size of a task by drawing on the expertise of a group, I feel the need for a similar approach to obtain a consensus ranking (e.g. for prioritization).

Here is my approach -- which I hereby dub "Ranking Rummy" -- to this problem:

Example/procedure: Consider four stakeholders have identified five "top priority" tasks for a project, but the Project Manager has requested a strict ranking.

1. The tasks are labelled and each participant is given (or produces) five corresponding cards to rank independently and secretly -- no discussion.
2. When the participants are ready, they all reveal their highest priority card.
3. If all are in agreement, we have our consensus highest priority, and can move on to find the next highest.
4. Otherwise there will be two or more factions (groups who played the same card).  Similar to Planning Poker, the facilitator asks (only) one participant from each faction to explain his or her choice.  Then there is re-consideration, and the process is repeated until consensus has been achieved or, say, three rounds have been played.  If consensus is not achieved after three rounds, a tie-breaking mechanism is employed: E.g. majority or seniority.
5. Repeat for the remaining tasks.

As with Planning Poker, the procedure encourages initial independent ranking, and structured yet informative communication about the tasks under consideration without negotiation and/or intimidation.  

Seniority is a useful tie-breaker if your group is following a consultative (but non-democratic) approach.  For example, if prioritizing among Time, Scope and Cost, the project sponsor will typically have the final call, but Ranking Rummy would allow him or her and the stakeholders to get an understanding of each others' views and preferences along the way.

Applications

• Ranking tasks, users stories, features
• Alternative to value sliders [pdf], where a strict ranking is desired.

Please let me know how you go with Ranking Rummy.  Suggestions (and donations) gratefully accepted!

No Plan Survives First Contact With the Enemy

... or friends, for that matter.

This saying, from the context of battles, applies equally to projects where outside influences are significant.  Initial planning swiftly becomes outdated, so it wise to plan at first in only broad brush strokes -- at a high level -- perform detailed planning as we go along.

For those who have limited experience as military command consider instead a game of chess (or checkers).  One might go in with certain intentions (play aggressively, use set plays when possible), but there is no way that you can plan out the whole game in advance!  You might plan a few moves ahead, but as soon as your opponent moves, everything shifts, and it's time to re-plan.

1972: Fischer challenges Spassky

As for friends (or family), suggest a plan and they'll want to get on board ;-) too!  Your plans will shift.  In a project this is the equivalent of an internal customer or product owner suggesting a better idea mid-way through the project -- and you acknowledge that it really is better.  Hmmm ... better re-plan.