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?
Related Posts:
No comments:
Post a Comment