One of the great things about Agile is that teams tend to stay together. This is key because the longer a team stays together, the better its members can estimate work, the better its velocity becomes, and the better team members work together. This, of course, is not always the case, but I’ve seen it occur on most teams. However, with keeping developers on the same team and working on the same product for long periods of time, keeping developers engaged is an issue. By engaged I don’t just mean in terms of having enough work to keep busy but also in terms of the type of work so they are happy.

Real-Life Stories

Story 1: Keeping It Fresh

On my first few Agile teams it was clear that having a team stay together for multiple projects really did increase velocity. The team became a well-oiled machine over time. On one Scrum team we had been together for about a year and a half and worked pretty much on the same codebase (similar to the Micro Service Architecture structure that other companies have adopted). After a while, I found this boring because there was little challenge to the day-to-day work (in terms of both domain knowledge and technical skills). Eventually I left the team so that I could find more challenging work.

Thoughts

I realize that my choice to leave the team, mentioned in Story 1, was a very individual one. For some developers the idea of staying on a team where they know the code inside and out would be ideal. But for other developers, it can get old after a while.

However, there are ways to keep developers engaged and challenged on Agile teams that work on the same product. One way is to give developers “hack hours” every week so they can work on projects they are interested in. These projects can be focused on reducing development pain points or just learning some new technology.

Another approach that I’ve seen work well is to have team members rotate certain roles on the team. Some teams, for example, rotate the Scrum Master role. This can break up the monotony, create an opportunity for growth, and make team members feel more fulfilled.

Story 2: A Lot of Free Time

When developers are not challenged at work, it can lead to some very interesting situations. Although such a situation is not specific to those working in Agile software development, I think in Agile it should be easier to identify when this is happening (Daily Stand-ups, point commitments, etc.). On one Scrum team I was on, I saw that even with Daily Stand-up meetings and other processes, several developers were not being challenged by the work our team was doing. In fact, several developers would openly work on non-company-related development during the day. I am not talking about approved “hack days” or anything like that. They were working on things related to their own outside businesses. I actually saw one developer get swamped with work while two other developers were working on non-work-related development. I thought to myself, “how is no one at the management level noticing this?”

Thoughts

In Story 2, the main issue was a lack of transparency. If developers would say “I’ll have those User Stories done in one week” and the Sprint is two weeks, then it should be obvious they have bandwidth to work on other things (defects, improvements, etc.). As members of a Scrum team, there is an expectation that we are transparent in Sprint Planning and the Daily Stand-up meetings.

One-on-one meetings can go a long way toward helping you to know if developers are being challenged or losing interest. I’ve always found these types of meetings to be very useful. It’s an excellent chance for managers and developers to touch base. It’s a chance for managers to ask if developers are happy or are looking to try something new. This is not Agile specific, but it is one way for managers to have insight into what is happening on their Agile teams. In general, teams I’ve been on that had one-on-one meetings seemed to have happier developers; of course, this is just empirical data.

It should go without saying that team members should be helping each other to complete the work for the Sprint. One way to make sure this is happening is for developers to ask for help in the Daily Stand-up meeting. This forces members of the team to justify why they can’t assist.

Story 3: Avoid Pigeonholing

Sometimes on Scrum teams developers can get pigeonholed. For example, I have been on teams where someone becomes the dedicated QA person. On one team I saw a QA engineer get pigeonholed where he became the only person on the team to run the Automation test suite we had for the codebase. This particular team was practicing BDD and we had a substantial set of automated functional tests. This one person would run the tests every day and report the failed tests. In addition to running the automated functional tests, he would also maintain the functional environment (we were using Selenium Grid and testing across multiple browsers). Over time, this became a very monotonous task.

Not surprisingly, this individual became pretty bored. For some reason our manager only wanted this person to focus on this one area of the project. This QA engineer was very talented and could have contributed to other areas of the project (writing tests, fixing defects, etc.). It was unfortunate because this individual had a lot of experience that could have benefited the project.

Thoughts

Not only does pigeonholing people on a cross-functional Scrum team hurt those individuals, but it is bad for the team and company. It is bad for the individual because he never gets a chance to grow in his career. It is bad for the team and company because having a single point of failure is never good.

One way to overcome this pigeonholing is to rotate roles on a team. I am talking about on cross-functional teams where people are separated by skill sets. I know in some companies “everyone plays every role” on the Agile team, so rotating roles does not apply. You can also rotate the Scrum Master role if you are using Scrum.

Depending on the way your teams are structured, maybe it is possible to rotate developers between teams. For example, I have seen sustainment teams using Kanban and project teams using Scrum and every other month or so developers are swapped between these teams. If your teams are following a model where your teams own a complete Service or vertical (UI to Service for a functional area in an application) and handle both product defects and project work, then you can try rotating developers between working on defect and project work every few Sprints. Again, it depends on the structure of your teams and the dynamics, but I think rotating developers in and out of production defect type of work is a good idea because it can help developers write better code (because they know what it means to support code in a Production environment).