Agile Team Design – Key Factors for Success

Recently I was asked to consult a program that had been “doing Agile” for almost a year because this group was experiencing several issues with product quality and consistency of delivery. Usually, one of the first things I do when initiating a new engagement is to evaluate how the teams are configured. Often times, incorrect team setup can result in many of the common problems that new teams often face, such as the inability to deliver working product consistently. In this case, the program consists of 8 different “Scrum teams” that still operate within silos instead of in an integrated fashion. This is a common mistake that many organizations make when attempting to make the transition from traditional Waterfall approach to Agile way of doing work. Team design is one element of an Agile transformation that is often overlooked for a number of reasons. If you have encountered the question of “what is the ideal Agile team”, I have a few ideas that should shed some light into this often-forgotten, yet critical piece to the Agile adoption puzzle.

TIP #1 – Try to think outside the “HR box”

The program I mentioned earlier took their HR organizational structure and created pseudo-Agile teams from them; in essence, the program consists of a Software Scrum team, a Network Scrum team, a Quality Assurance Scrum team, etc. Those of you who are familiar with Scrum may have difficulty understanding how this could happen, but I have witnessed this type of team configuration more often than you might expect.

In some organizations, it is simply easier to apply the current known boundaries to the “new” way of doing work, without fully understanding the benefits and disadvantages of this decision. It is easier said than done, but in most cases, to optimize product delivery, it is often best to take the HR org chart off the table and try to look at what makes sense.

TIP #2 – Think end-to-end delivery

When you are looking to build a team (or several teams) that work together to produce some type of solution that enables the customers to achieve meaningful business objectives, it is essential that you start thinking like the customer. Ask yourself these questions…

1. How often do I need to utilize this product?
2. How often do I need updates to this product to continue reaping the value from my investment?
3. What capabilities do I need in this product for me to want to continue paying for it or buy more of it?

If you are able to step into the shoes of your customers successfully, you can start thinking in terms of Value Stream – the process flow that will allow your team(s) to design, build, test, and deliver the product to your customer in an effective, efficient, and consistent manner. To complement Tip #1, when you start looking at the problem from this perspective, you may start to see how the teams should look like.

TIP #3 – Examine specific team roles and skillsets

If you have a deep understanding of the best way to build and deliver the product that your customers will gladly pay for, you are in a great position take a closer look at the skills you need on your teams to make this happen. In most literature related to Agile teams, you will likely see terms such as “integrated” teams, “cross-functional” teams, or maybe “feature” teams. All of these terms are intended to communicate one thing – your team should be capable of handling all the necessary tasks that are required to take a product from inception to delivery without crossing organizational boundaries. The primary benefit of this approach is to minimize wasteful handoffs across teams, which ultimately results in delays and inefficiencies.

The fundamental concept of an Agile team is that the team is able to design, develop, test, deploy, and release a product to the customer by working together as a single unit. This means the team must have all the skillsets across all disciplines to get all the work done in the most efficient way possible. According to “Scaling Lean & Agile Development: Thinking and Organizational Tools for Large-Scale Scrum” by Larman & Vodde (2009), the ideal Agile team should consist of “generalizing specialists” who are capable of working on tasks across multiple functional areas (i.e. both write code and test the code); another term for this type of worker is “T-skilled”.

In summary, when setting up your teams in preparation for Agile transition/adoption, it’s important to think through how you plan to deliver value in an optimal way. Even if you don’t have a pool of highly-skilled generalizing specialists, start small and try your best to build a multi-discipline team with the people you already have. You may not get there overnight, but think about how to incrementally work towards that vision. Use the Scrum Guide as your starting point to build out your team, starting with a Scrum Master and Product Owner. Look into what skills you need for the Development team and go from there. If you can resist the temptation of maintaining status quo, you will be able to break through the barriers created by traditional silos and give your team the best chance to do their best work.