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.


Have any Question or Comment?

8 comments on “Myths and Misunderstandings about Agile Teams

Jonathan Bush

Great article Scott!


To me there is one comment that really rings true. That the people on the team have a desire to increase knowledge and skills. Some of the best teams I have worked with have people who go the extra mile to understand other technologies or job functions. I’ve had .net developers learning SQL; BA’s learning testing; Architects taking over from SMs if needed.

It’s was very rewarding listening to a DBA explaining 3rd normal form to a business person who even has a hard time with an Excel spreadsheet! That was positive from two perspectives. The DBA was motivated to explain relatively complex technology and the business person wanted to learn more not only to help the project but also to broaden their skillset.


I agree with previous comment. But there are two parts to it. One the willingness and commitment of the management to support ongoing learning and development of teams and two the actual willingness of resources to embrace new skills. You can not force people to learn a new skill if that is not their career aspiration. If the DBA is willing to explain but the business person is not willing to listen/understand 3NF there is nothing you can do about it. Similarly, if management thinks their timelines/budgets are too tight to promote learning, they think they are better off hiring skilled people the story just ends there. Methodology can not do anything in this case. Methodologies are for creating and promoting ideal situations, where as reality often times likes to take deviations from idealism.


Sometimes you have to ignore management and promote learning (if only in the small and outside normal communication channels) and allow the results to sway management to be increasingly supportive. The potential payback from allowing teams to more fully embrace agile principles and practices sometimes has to be demonstrated before management fully commits. Management may never be 100% supportive, but when your team is delivering more work per iteration and the quality continues to improve, that gets “management attention” for all the right reasons.


There are many learning strategies that teams can adopt that promote learning that management doesn’t need to be involved with. People can choose to share information, then can choose to help one another, they can choose to coach or mentor each other with little or no impact to the rest of the team.

When it comes to the methodology issue, this is why DAD’s goal-driven approach is so important. Methods like Scrum prescribe a single way of doing things and then expect you to figure out how to tailor the approach to meet your situation. The challenge with this is that you often don’t know what your options are, or even that you have options, and most people don’t understand the tradeoffs that they’re making.

DAD on the other hand doesn’t prescribe a single approach, instead it gives you options and makes the tradeoffs associated with each option clear. It guides you through your choices and thus increases the chance that you’ll choose the approach that best works for the situation you find yourself in.


Not to be flippant, but its disconcerting that you needed to write this.

Bob Dobson

With respect to learning, I’ve found that Agile teams can be much more disciplined about learning in they are more likely to make that learning both transparent (“before next I have to review the CQCR pattern and determine where to implement it”) and practical.


Leave a Reply

Your email address will not be published. Required fields are marked *