This is another excerpt from my upcoming book Agile Discovery & Delivery: A Survival Guide for New Engineers & Tech Entrepreneurs. It was slated to come out in June, but that may quickly be sliding out to July based on a few things I’d like to clean up before publishing. In the meantime, sit back and enjoy this excerpt from the chapter on agile teams.
What Makes a Great Agile Team?
High-performing and happy teams tend to be dedicated, self-organizing, empowered, and cross-functional.
Dedicated teams work on one project at a time. They move far more quickly than teams working on more than one project. To learn why, visit the principles section in Chapter 6: Kanban which discusses Little’s Law. Little’s Law mathematically proves that teams get more work done when focused on fewer tasks.
Empowered & self-organizing teams have everyone on the team they need to make decisions. They determine how to get their tasks done based on what’s right for them. The team determines what to build. No two teams are alike.
Cross-functional teams have the skills they need to complete their projects. The developers have the skills to do the work (or can learn them). The team has testing skills. There is a Product Owner who understands the business case for the product. There are organizational skills on the team (e.g. a Scrum Master or Project Manager). The team may also have design or user experience skills. Strong teams also have go-to-market capabilities (Sales, Marketing) embedded in their teams.
Great team members can take on more than one role in order to move the work along (this is called polyskilling). It’s not uncommon for developers to act as testers, for example. Or for UX designers to have some front-end development skills that they can use to build web pages. A strong cross-functional team has back-ups for each skill set. They also have a learning mindset that allows people to jump in where needed. After all, we all take vacations or switch jobs now and again!
Team Size
In general, agile teams have no more than 10 people on them. Smaller teams suffer from knowledge silos when there aren’t enough people to back each other up. For larger teams, communication becomes difficult. It is ok to have larger teams if it removes dependencies on other teams. Dependencies slow teams down and create uncertainty. When in doubt, optimize for removing dependencies. If needed, teams can grow to not more than 15 people. After that, communication becomes difficult.
Forming Agile Teams
In most organizations, teams are formed by managers. You’re placed onto the team that best matches your skillset when you start. If you’re lucky, your team is stable for long periods of time and you like them. Most of the time, engineers don’t have full jurisdiction over who we work with and what we work on.
If you’re a new engineer, you may not be in a position to change the way your organization forms teams. Understanding your options may help you influence future decisions. If you’re an entrepreneur or in a position where you have influence over team formation, this section is for you. There’s a far better way to form agile teams.
You can let your people choose who they work with and what they work on.
Self-Selection
Wait, what? Let people choose who they work with and what they work on? That’ll never work! How will we make sure the teams have balanced skills? How will we make sure all the work (including the things no one wants to do) gets done? What if people feel left out? There are a million things that can go wrong. There’s no way this will work, right?
But it does. Using a process called self-selection, we can form balanced, high-performing teams over the course of an afternoon or a day. This is the process we use to form teams in my class.
I hope you enjoyed the book excerpt! If you want to know more about self-selection, there are a lot of resources on my site. Click the self-selection link above or sift through the articles in the self-selection category.
