Sunday, February 22, 2015

Scaling Agile: Feeding Your Feature Teams

One form of scaling Agile is about implementing Agile principles and practices in large projects or programs in such a way that you are able to deliver business value through time-boxed iterations and maintain a sustainable pace. Large projects or programs constitute multiple releases and releases comprise of multiple iterations.  In such projects or programs you will have multiple feature teams. For example, a project I was involved some time ago consisted of more than twenty feature teams distributed across two or three sites.  When a project or program of this size is in full form and happening, how do you feed your feature teams?  How do you feed your feature teams with groomed user stories and make sure that dependencies are resolved and technical debt (and consequent rework) is minimized?
One of the critical success factors of large-scale Agile projects is how effectively we feed the feature teams so that feature teams get quality inputs in order to ensure corresponding income. This includes
a)      Identification of business epics
b)      Architecture envisioning
c)       Making timely architectural decisions
d)      Identification of technical stories
e)      Validation of designs and technical decisions through POCs
f)       Breaking business epics into user stories
g)      Release planning
h)      Dependency management
i)        Sequencing the right set of stories for feature teams
j)        Story grooming 1 or 2 iterations in advance
k)      Adhering to ‘Definition of Ready’
l)        Defining Acceptance Criteria
m)    Having Definition of Done

When all these happen, feature teams will have groomed stories that satisfy the ‘Definition of Ready’ and have a clearly defined ‘Acceptance Criteria’. Doing this is a positive step towards minimizing technical debt, and avoiding rework.  Also, this can help us minimize story cycle time – the number of iteration it takes to complete an end-to-end story that is production ready.
Who does all these?  I hear this from hard-core Scrum practitioners – “It is the PO and Scrum Masters.  We have Scrum-of-Scrums.  There are no special roles such as Architects, Designers, and so on.”
What happens when you work on a large-scale complex green-field development project based on an emerging technology? What happens when none of the technical architecture defined earlier for other products or applications cannot be reused for this project? What happens when business requirements are complex and evolving?   When all these come together, I don’t think ‘Scrum-of-Scrums’ with a chief PO or PO can spend their time in turning out all these to feature teams.
You will need a team of 1 or 2 or more architects. You will need a team of two or more solution designers.  You will need a team of more than 1 PO.  And you will need a small group of technical experts to validate designs.  Besides, all these groups need to synchronize in churning out meaningful high-level release backlog and groom stories in a timely manner so that feature teams get what they want when they start iterations.  Obviously!
Here are the advantages of this approach.
a)      Effective release planning and dependency management
b)      Validation of architectural and design decisions before stories are assigned to feature teams
c)       Effective technical debt management
d)      Reduction of rework
e)      Optimization of story cycle time
f)       Improvement in quality (feature teams get quality inputs and acceptance criteria)

One of my friends asked, “All I have are 2 or 3 feature teams. It is not a very large project. Do I need such a complex structure?”  I said, “With the current structure, are you able to feed your feature teams? If no, you may need to find ways to make that happen.  May be you need to improve the way your current team operates or make some significant changes.”
If you want to deliver working software through multiple feature teams and deliver successful releases, don’t you have to focus on feeding your feature teams? I am sure you say ‘Yes’.
How have you done this or seen this happening in your projects or organization? Are there similar or different or better approaches?

No comments: