Building and Scaling Agile Teams

 Here is a blueprint that helps define how we form a new agile delivery squad and then the further augment it to multiple ones when we need to scale.

The basis of this is that you form the first agile squad based upon some really good new hires who all have an agile mind set.  All squads go through a phase of forming, storming, norming and performing so we need to get the team performing as quickly as possible.

Evolution 1 is to form the squad around a full end to end capability and ensure that ways of working are all established.  A scrum master/ agile coach would be brought in to ensure to importance of working as a unit and that the agile values, ceremonies and principles are followed.

Evolution 2 means that we introduce a new squad but augment squad 2 from resources in squad 1 to ensure that we hit the ground running and are performing. We can also share roles such as the scrum master to have alignment around process and culture.

Evolution 3 can add another 1 or 2 squads by further augmentation. Once we have 3 or 4 squads, the unit of people are often referred to as a Tribe based upon the model coined by Spotify.

In order for the Tribe to work collaboratively, we can glue the squads together with both Chapters and Guilds.

After 12 months of working well together, we can also introduce the concept of a transfer season to allow people to move around squads.

 

Team Structure & Guiding Principles

The team is known as a ‘Squad’. The Squad is a multi disciplined team all working as one team. They sit together and have all the skills and tools needed to design, develop, test and release to production.

Work as one

There is no room for a “throw it over the wall” mentality in a squad. Analysts do not throw requirements over the wall to Architects; Architects do not throw designs over a wall to Developers; Developers do not throw half-tested code over a wall to Testers. A successful squad must have a we’re-all-in-this-together mind-set otherwise the team risk not working as one unit.

Guiding principles

Squad members remain ‘static’ for a period of 6-12 months if possible.

  • This allows the team to (form, storm, norm and perform) as quick as possible.
  • The roles and personalities of the team need to be understood by each other to highlight people or process gaps so that improvement can be made.
  • The concept of a ‘Transfer Season’ can be introduced to implement squad rotation periodically

Metrics

The squad has a number of KPIs in place:

  • Cost, i.e. the squad has a known ‘run rate’.
  • Cycle time / Velocity. How many stories can be delivered in ‘x’ time period
  • Team health check. Does the squad have everything it needs to be able to deliver rapidly, predictably and to a high quality (with a low failure demand)?

 

Evolution 1 (Squad 1)

First Squad is formed with full end to end capability. The key is to use resources that have and want to work in an agile fashion before.

Architecture is bolstered to enable high-level planning (Tech Design, Service Capacity Planning, Service Readiness). This enables Solutions Architecture to take a more hands-on approach with the development team to build in a more considered solutions (Hardware/Software/Future state) view.

A Scrum Master is brought in to ensure that the agile process is followed through coaching the team, explaining the importance of ceremonies such as Sprint Planning, Demos, Retrospectives and keeping information repositories up-to-date and accurate to provide better visibility of progress, risks, dependencies and impediments.

 

Evolution 2 (Squad 1 & 2)

The team scales to fulfil increasing work requirements.

Developers and testers split across squads to ensure a rapid start up. Each squad is then backfilled with new recruits). This maintains delivery expertise and knowledge around ways of working and the SDLC.

Some roles can be also shared such as Architect, Scrum Master, and SRE to maintain sensible staffing ratios based upon learnings of optimal resourcing.

 

Evolution 3 (Squad 1, 2 & 3)

 

The team scales (again) to fulfil further work requirements.

Developers and testers split into 3 squads each from Squads 1+2, and are back filled by new recruits). Additional staffing to maintain the flow of delivery across required functions is: Architect, Business Analyst, Scrum Master, Service Designer and 2 x DevOps Engineers.

 

Scaling Teams

Scaling teams within a Squad structure can be easily achieved, however its imperative to keep each community of discipline (chapter) glued together to ensure alignment.

Chapters

Each chapter meets regularly to discuss their area of expertise and their specific challenges -for example the testing chapter, the web developer chapter. The chapter lead is also line manager for his chapter members, with all the traditional responsibilities such as developing people, setting salaries, etc.

 

Guilds

Guilds can be a little more difficult to implement, they require motivation from the team and can require some degree of coordination. Chose something technical ideally, something that the team would enjoy to work on, this way when other team members see the results and outcome, other guilds would easier to form. You can start in such areas as:

  • Performance monitoring / optimization
  • Testing automation
  • Security & vulnerabilities.
  • Services & Architecture

 

Squad Sizes

The key factor of the squad is not the size, it is its make up of skill sets. This means that different sized squads can be created depending on the organisational need. For example you may have the following sized squads:

 

 

Micro (5 People)

Mini (8 People)

Large (13 People)

These teams usually consist of:

  • 1 BA / PO who can span both roles
  • 2 Developers,
  • 1 Tester
  • 1 DevOps
These teams usually consist of:

  • 1 BA & 1 PO (or an individual who could also span both roles)
  • 3 Developers
  • 2 Testers(1 x Automation, 1 x Exploratory)
  • 1 DevOps / Platform Engineer can span both
These teams usually consist of:

  • 1 BA & 1 PO (or an individual who could also span both roles)
  • 5 Developers
  • 3 Testers(2 x Automation, 1 x Exploratory)
  • 1 SRE(Service Reliability / Security)
  • 1 DevOps
  • 1 Platform

 

 

Squad Roles and the process

The balance of the squads is key to ensuring a smooth, opitimized  flow of work throughout the process. By having the right make-up of the teams it ensures that the correct skill set can be engaged at the right time and blockers or inventory are kept to a minimum.

 

Line management

One of the key questions that I get asked is about line management within a squad model.

It really depends on how corporate or structured the organisation is, however I would encourage a vertical line management structure where the Delivery Manager has full accountability for all resources in the squad.  Horizontal line management can also work, but it’s more difficult since you can have multiple decision makers who tend not to agree on ways forward.

The above is for 2 squads but can work with 1-4 squads.

 

 

Authors

 

Links

Sidebar