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!