Roles in Agile

What are the common roles on an agile team? Agile developer, agile tech lead, agile delivery lead, QA? Many of you will recognize these titles, many have filled one or more of them.

Team roles are something that are prescribed by some methodologies and sometimes they evolve on the team. Other times they are simply appointed because it feels natural to have them.

Over the years I have filled a few of these and in most instances the roles imply a set of responsibilities that differentiate them. I have thought about these roles when I have been in them and wondered lately why they have to exist.

The current client I am engaged with is in the midst of an agile transformation and the teams that have been created have been structured as Scrum teams with all of these roles accounted for. The teams have various levels of success with the transformation, mostly pretty good.

What I have come to realize is that the roles are an illusion.

There isn't any one particular role that one team member holds that can't be distributed across the team as stories. Admittedly, different team members have different skills and abilities that influence the level of success that each member would have taking on these stories. However, these differences should be mitigated with solid pairing and mentoring and would, over time, develop all of the team players to take on the tasks normally assigned to a role without requiring a particular person executing them exclusively.

The structure of the teams have been configured as they are to impose structure to allow a level of comfort to the players involved as they became knowledgeable in the discipline of being agile. The intent is that the structure will be stripped away in time while leaving the responsibilities with the team.

Whether that means the roles remain with the same people filling them is an open question. I believe that the roles themselves can melt away or effectively become hats that different team members wear on any given day.

Personally I prefer the latter option. I think the team as a whole will be more nimble and be able to adapt to change much better than if the names remain the same. If all team members have handled the responsibilties over time, with a self-organizing, revolving door, then the loss of one member due to illness, outside change or simple evolution, the team ownership of the product and process is stronger and the commitment is stronger. I also believe the quality of every person on the team will be higher than would otherwise be the case. All of this means the product is better, the team is better and consequently the organization is better.

What do you think?

Polyglot Programmers

Do you have a favorite programming language? Most developers do. Sometimes it's the first language they learned. Sometimes it's the first one they became proficient in. In many cases programmers who have a favorite language may end up favoring it and in time they end up only writing code/applications in that given language. Other times a developer may just get in a rut or habit and continue down a path with a language because it is comfortable and they feel confident working with it.

There is a problem with this approach to development.

This situation leads to a myopic view of coding and design that can limit your options when building. It is a familiar scenario mostly commonly expressed as "When all you have is a hammer everything looks like a nail." You look at every problem as a Java problem. Or a C/C++ problem. Or Ruby.............

You can see where this leads. A programming language is a tool. Nothing more. Ask a carpenter what the best tool in the toolbelt is and they will ask what you are trying to do before they answer. It's an obvious question to ask - you can't say the best tool is a file when you need to screw a doorknob to a door.

But ask a bunch of developers what the best language is and they will nearly all have an answer. Even without asking what you are trying to do. That is a problem that many developers miss.

Every programming language has it's good and bad. There are things that some languages do quite well where others struggle and vice-versa. I will refrain from stating these pros and cons to avoid the common arguments that arise as it is beside the point.

Good developers know that it is important to have many tools in the box to address the different problems they are going to have to solve and they will work at getting and staying proficient with the tools available so they can recognize when one tool fits the problem at hand better than another.

I try to keep abreast of the cool languages out there. There are always new ones to look at, old ones to refresh on, and off-the-wall ones that are just neat to play with. Some you may never use, others will get broken in daily but it is important that you have as many tools at your disposal as possible so you can build your solutions to the best of your abilities.

Another reason to learn lots of languages (as well as IDEs, compilers, platforms) is because exposure to different programming languages exposes you to different viewpoints and approaches to solve problems that you would not have were you not experimenting.

I aim to be a skilled craftsman and every skilled craftsman knows what is really important with tools. Keep them clean, keep them sharp and keep them within reach for when you need to pull them out.