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.

Have any Question or Comment?

10 comments on “Activities over roles


This is a paradigm shift most organisations and by implication people don’t want to accept. This is something I struggle with and consequently I’m forever witnessing uneven results due to partial adoption. There is a commonly held belief that agile kicks in only at certain parts of the solution process. I’m striving to reach the utopia of cross functional teams but for the organisations I’ve worked with, I’m sure I be retired by the time they realise this. Generational change is required. Sorry if this is a little off track but getting to a t type capability is some ways off for where I am. I will keep trying and could use some help 🙂


When transitioning to a new way of working we need to actively help people do so. Part of that effort is to help set their expectations about what the change entails. Another part is making the training, education, and coaching available that they need to help them make the change.


I have seen everyone on a team pitch in to test; seen ‘developers’ do research on requirements, perform data analysis, and write stored procs; ‘testers’ have written SELECT queries. What I haven’t seen is anyone except ‘developers’ write, debug, or build “code.” — Has anyone else seen this? —

Part of the argument I’ve heard in the past had to do with discrepancies in salary rates, “we don’t pay developers to do that.” Haven’t heard that in a while, but it does betray a significant difference in skills: team members with background in analysis or testing tend to communicate in one language; developers are polyglots.

“Code” is written in a text-based language. By what may be considered a close analogy, and each language comes with its own dictionary and dialects if you will. If you don’t know the language, it’s difficult to impossible to translate into that language. The analogy suggests a solution. I cannot speak Swedish, but can safely drive in Sweden because the road signs are principally graphic symbols.

If we want a truly multi-disciplinary team, we need to leverage better programming environments. There are tools which convert UML symbols into code, but those require some understanding of OOA/D (in addition to the arcane symbology) to effect. There are languages (e.g. Agilent VEE) which employ such symbols to produce executable code for rather complex engineering. What we need to leverage our full team to maximum advantage is a visual equivalent of COBOL. Than anyone, regardless of native tongue or programming paradigm, can join in the development of “code” which only the compiler need translate to something other trhan pictures. There will still be a need for words (e.g. business rules) but even those can be arranged in diagrams (e.g. fact models, ERDs).

I think that most business analysts and testers with whom I’ve worked are quite capable of designing a solution, just as programmers are capable of ferreting the core needs in a problem/opportunity. What non-programmers lack are facility in the language and consideration of the technical limitations imposed by current systems. Unfortunately, current movement toward functional programming is in the opposite direction.

So let me repeat and extend the question: Has anyone seen teams where analysts and testers begin to perform programming? and how do (or might) we create an environment which encourages that behavior?


I’ve seen teams where this happens. Testers often have coding experience as either they used to be developers in the past or they currently write testing scripts as part of their day-to-day testing activities anyway.

Getting analysts to code is a lot harder, often because they don’t have a programming background. However, it isn’t much of a stretch to help them learn testing languages such as Gherkin (from Cucumber) to capture acceptance test logic.

I’ve also seen many orgs where the existing culture made it really hard to get people to start learning new skills. This is something worth fighting for, IMHO.

Also, we should recognize that many business people “code” in domain specific languages such as MS Excel. I’ve lost track of the number of times that I’ve been told that business analysts couldn’t possibly gain programming skills only to find that they’ve created some really complex spreadsheets over the years.

Agree with you that we could do with some friendlier development environments. In the 80s we had a really healthy movement around end user computing (EUC), but that died off unfortunately. Might be a good opportunity for anyone who wants to try their hand at building a new generation of tools.


I think it is the “working collaboratively” that needs to be better explained and understood. If a BA skilled in requirements, and a skilled coder, become part of an agile team, how do they start working together? How do they gain the new skills? I don’t think osmosis will do it.

Somewhere above the point was made that training and support are important. So are you just cross-training and seeing who picks up what?

I would love to do more than I do now, but the skills, knowledge and experience to be good in any one role is considerable; after years doing mainly one thing, it would be like starting out all over again to add more skills, and one can’t be sure how valuable that would be to one person. It’s great to be a team but it’s my career.

Other thing above was about salary – how are companies paying “team members” when HR and history has determined salary by role and experience? I would hope being agile brings salary up, but I can picture some employers trying to bring it down to the lowest common level.


Great post, Scott!

Working with or in development teams can be the best job on Earth – if the team has the needed skills. Not just technical skills, which can fairly easily be obtained (if time permits) but also personal skills and those “skills” that come from simply being different people.

The best teams I have experienced have been combined from a mix of young and old, men and women, longer and shorter educations, etc., and in such teams it was natural for people to offer help to each other and to ask for help. Some experienced people were happy to teach the young ones a few things and the young ones were happy to shine with some new knowledge they brought with them from college.

But even though such a dream team’s members are helping each other it doesn’t mean that they are all doing the same tasks. They split them according to who knows what. What one experienced person doesn’t want to do because he had done it enough during his carreer, another person will be happy to try. And then the first can guide the other and both will be happy.

Some people have ambitions of one kind or another – maybe just a burning wish to work solely with analysis or project management or whatever. And it doesn’t make sense to try to force these people into a situation where they can do this only a small part of their time just because all work must be shared equally in the team. It will only make them unhappy and less productive – and destroy the dream team.

A good way of utilizing a team is to enjoy peoples differences and allow them to do different work – but together, helping each other and holding a shared responsibility.


Sorry for commenting through my Twitter account – it was a mistake. But this comment should be through the WordPress account 🙂


It’s interesting that many places that I’ve worked in some Agile method, start out with lots of ceremonial activities before finally transitioning into a high-performance teams. If we can shorten the duration that new companies spend in “finding” this zone, the faster the benefits are realized

Valentin Tudor Mocanu

In fact, in Agile a person should be rather multi-role and should have cross-functional skills. The only reason why a person will not have “all” the skills is because that is difficult to achieve. In this context, using Generalizing Specialists it is a pragmatic approach:
– it is what Agile need – cross-functional skills & multi-role >> a Specialist
– it is feasible – we can hire or train people to be Generalizing Specialists much easier than getting Masters for all skills

Marcos Macedo

I have seen this working many times. My team does continuous delivery. As we are also a DevOps team, add operation as a team skill too. The practice that more useful doing this transition is pair programming. It is hard for someone comming from analisys to code, as there are many detailed skills to master. Pair programming helps that, as he will not be alone. Also remember to rotate the pair, so a task that started with some pair would end with someone else, distributing the skills along the team.

I once had a team member comming from analisys and who was about to retire about one year after the project. He knew mostly no Java or object oriented programming. After one year working, he was suggesting design patterns to our design.


Leave a Reply

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