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?

Sunday, February 15, 2015

Scaling Agile: Architecting Your Team Structure

We all know that in small Agile projects the team structure is simple and easy to understand as small projects need seven to ten team members to form a cross functional team. This cross functional team would have a leader and several team members including developers, testers, business analysts and database specialists for example. According to Scrum, roles such as Product Owner, Scrum Master, Team Members hold good. Also we hear Scrum practitioners saying “Scrum does not talk about Architects or Designers or Testers. All are team members.” Yes. Some agree and some don’t. That’s ok as long as teams exhibit the necessary behavior to deliver what is required to be delivered. How do we structure large-scale agile teams?  What behavior do we expect out of these teams. This blog post is about considerations for team structuring in large-scale Agile projects or programs.
Many of us wonder how we get Agile implementation going in large teams.  For this, obviously we need to scale up from one cross functional team to many. “Scrum-of-Scrums” – that’s  what we hear.  It is not as simple as that.  It is about scaling up your delivery capability or setting up a delivery engine to adopt Agile methods and deliver large projects. In order to do this we must be able to mention what we need from our proposed large-scale delivery team. That will help us structure the team to satisfy our needs.

So, what kind of behavior or expectations do we have from large-scale delivery teams that implement Agile methods?  Here is a list that helped me conceive a delivery engine show above.
1)     We need a team structure that can follow Agile principles and practices.
2)     We need our team to understand business requirements, decide architectural needs and design optimal solutions – and we need our team to resolve dependencies and create user stories.  In this process, our team must be able to develop PoCs on need basis to validate their approach.
3)     We need our team to create, maintain and prioritize product backlog.
4)     We need our team to implement user stories.
5)     We need independent verification to cover various areas of software testing such as functional testing, security testing, performance testing and so on.
6)     We need effective build and release management in place.
7)     We need a program or portfolio management team – if we need to deliver a program or project portfolio.
8)     We need a governance mechanism to provide necessary encouragement, support and timely course-correction so that our delivery engine is functional and capable.
9)     We need this system to facilitate coaching on need basis for our team members.
Every structure comes with an associated behavior. This is true for all systems including team structures. Understanding the goals and  expected behavior of your project organization and putting together a team structure is a meaningful way to architect team structures that can deliver results. What do you do? Do you follow one of the named methodologies and go by its suggested team structure? or do you think through and architect your team structure?