Myths and Misunderstandings about Agile Teams

 

Recently on a LinkedIn discussion forum people were sharing their opinions about agile teams. Throughout that conversation I heard several statements which just didn’t ring true with me. In some cases I suspect that the problem was they were thinking they were agile when they clearly weren’t and in other cases I suspect people were sharing ill-founded rumours about how agile works. I heard that everyone on an agile team must be highly skilled, that everyone on an agile team is a “jack of all trades”, and that people on agile teams are working so fast that they have no time to learn. Let’s examine each myth/misunderstanding one at a time.

Myth #1: Everyone on an agile team must be highly skilled
Agile lore recommends that you build teams where you ideally have all the skills you need to get the job done, this is called being a “whole team”. This doesn’t always happen at first. Recently I worked with a team that was clearly short on testing skills but they were actively addressing that problem by bringing people into the team with those skills. They will also be pairing to spread the skills out once these new people join the team. Call me crazy, but doesn’t building a team with people that have the requisite skills a good strategy regardless of paradigm?

Myth #2: Everyone on an agile team is a “jack of all trades”
Disciplined Agile Delivery (DAD) suggests that people strive to be generalizing specialists (not generalists, not jack of all trades). This means that you have:

• One or more specialties (you need to be able to do something useful)
• At least a general knowledge of the software process and the business domain that you’re working in (this enables you to communicate more effectively with others and streamline collaboration)
• The desire to increase your knowledge and skills

Granted, this is different than how some people staff traditional projects where they have specialists and then incur an incredible amount of overhead to get the job done. When you are new to agile you very likely have many people who are specialists on staff, perhaps they are focused on being a business analyst, on being a tester, on being a programmer, an architect, and so on. That’s OK, as they say you go to war with the army that you have. Over time you will want to actively support, and motivate people, to learn new skills from other people on the team (see next point). It’s also important to recognize that although someone may currently be focused on a certain traditional role today, that in the past they held other roles and as a result may have a broader range of skills, albeit rusty in some cases, than they may give themselves credit for. Regardless of your situation people can easily gain new skills if they choose to.

Myth #3: People on agile teams are working so fast that they have no time to learn
Yes, agile teams focus on producing real value on a regular basis, and that is often perceived as working fast by people used to the less disciplined strategies of the traditional world. This is overwhelming at first for teams new to agile and it can seem that there isn’t time to learn or to even catch your breath. As you get better at working in an agile manner, as you “figure it out”, your team will settle on a rhythm that works for them.

Agile promotes iterative, collaborative, and experimental strategies. This promotes learning within the team, it doesn’t reduce it. Agile, and lean strategies in particular, expect the team to learn as you go. They’ll learn more about the domain, about the technologies they’re working with, about how to work effectively, and about each other. When people work together collaboratively, not alone at their own desks, they start to pick up skills from one another naturally. This is particularly true when the team adopts non-solo strategies such as pairing (I alluded to the value of pairing programmers and testers earlier). Of course coaching and mentoring are important to support learning as well as training.