An Agile implementation team is a cross-functional or component group of people that have everything, and everyone, necessary to produce a working, tested increment of product or solution. The increment can be business and technical feature, or non-functional based. In the A2F Framework, you will have different types of teams contributing to the product or solution, and therefore what they deliver is based on the composition of the team.

When organizing Implementation teams, there are many factors to consider such as:

  • Feature teams versus component teams.
  • What Agile framework to use (e.g. Scrum, Scrumban, Kanban, or XP).
  • Number of people on the team.
  • Part time versus dedicated resources.

In the A2F framework will discuss each factor so you have enough context help organize your Implementation Teams.

Feature Teams

Cross-functional, feature team is a team that completes many end-to-end customer features, one by one. A cross-functional, feature team embodies lean thinking by minimizing the wastes of handoff, waiting, WIP, information scatter, and underutilized people is critical. As the name implies, the team is made up of people with different skill sets, focused on implementing features of value. However, A feature team would have all the skills to perform the necessary task-level work to get the job done. In particular, assuming a three-tier architecture, team members would work on tasks related to the GUI, middle-tier, and database parts of this story. It is encouraged that the Implementation build T-Skills via pair programming, additional training, collaboration, attending brown bag session, etc. A lot of Scrum teams aim to be cross-functional, feature teams because delivering a feature requires multiple skill sets.

Component teams

Having component teams does not mean you separate the development of presentation, domain, and data management layers into separate teams. Feature teams may work across all layers, but also make use of components and services provided by others. Component teams build domain services and tools to support the feature teams. The feature teams should be consuming those services. One litmus test to consider when forming a feature teams versus a component team is dependencies. It is more lean and efficient to reduce the number of inter-team dependencies. Examples of Component based teams are security, compliance, or platform based. They often work in Scrumban, Kanban, or XP mode.

Choose Your Team’s Agile framework

Choose your Agile framework for your team can be challenging. But based on industry experience, Scrum is well suited for software development. When the software development environment is very dynamic like weekly releases, adhoc work from stakeholders – Scrumban or Kanban maybe a better. Kanban is a good fit for production support, help desk, UI/UX prep work, etc. XP is useful when the team is 5 or less people, very nimble, disciplined, and high performing.

Number of people on the team

There are general guidelines by the framework your Lean | Agile team chooses to use:

Scrum 7 +/- 2
Scrumban 7 +/- 2
Kanban Based on your Kanban System Design
XP 5 or less

Part Time Versus Dedicated Resources

The dedicated team model can result in better delivery performance than the matrixed model of personnel assignment, provided the potential downsides are understood and mitigated in some practical way. The single largest positive effect is the elimination of artificial dependencies between teams. A second powerful effect is to make the true status of initiatives more clearly visible to leadership. It has several other potential effects that can be positive, both from the perspective of overall delivery effectiveness and from the perspective of quality of working life for individual contributors.