Activities over roles
Recently on the Disciplined Agile Delivery LinkedIn discussion group we talked about how people in an existing traditional role fit into a disciplined agile team. The challenge is that in organizations new to agile will have people who take on traditional roles such as business analyst, programmer, solution architecture, tester, project manager and so on. Yet DAD has roles such as team member, team lead, architecture owner, and so on that are different from traditional roles. Clearly this is a ”DAD adoption” challenge that we need to overcome.
At first you will build cross functional agile teams with the people you have available to you. Agile teams are whole teams, which means that the team has sufficient skills to get the job done. The implication is that you’ll initially build a team from the analysts, programmers, testers, … that are available and are willing to join the team. As they say, you go to war with the army that you have. At first an analyst is likely to focus on analysis activities, a programmer on programming activities, and so on because that’s what they know how to do. Because they are working closely with one another in a iterative, incremental, and collaborative manner they quickly start to pick up skills from one another. Over time these people who were originally specialized in one aspect of solution delivery become T-skilled generalizing specialists with a wider range of abilities. This enables them to collaborate more easily and be more effective as IT professionals.
An interesting side effect of this is that as your team becomes more experienced in working in an agile way, and as team members gain a wider range of skills, the conversation shifts from “I’m a tester, so I’m responsible for testing” to “as a team how are we going to approach testing X?” In other words, you start to focus on performing valuable activities instead of the roles responsible for doing so. This is an important shift in mindset on your agile transformation journey.