I was introduced to Agile concepts around 2004 or 2005, primarily eXtreme Programming ideas from articles by Kent Beck and Ward Cunningham. Fairly shortly thereafter, 2007 or 2008, I attended my first Mile High Agile conference here in Denver. At either that first one, or possible the next year (my memory is starting to go), I was introduced to the very energetic V. Lee Henson and a number of his really great ideas in implementing Agile including the "Team John" concept. Briefly, a software development Team John is an engineer who works separately from the rest of the development team on bugs, production incidents that arise, work that comes in sideways last minute ("Hey, can you pull some numbers from the database for me?"), or tech debt. The idea is that developer works on all the other shit that isn't part of the team's sprint work that would otherwise lead to interruptions. The responsibility rotates to a new developer with a new week or sprint.
It seems counterintuitive that removing a developer from the mix would allow the rest of the team to go faster, but I think any development team that regular needs to deal with incidents or gets hit with work sideways, from outside the Scrum process will immediately see the value. Interruptions kill a developer's productivity. That loss in productivity is attributed to context switching: The very act of switching from one task to another results in a tremendous amount of lost productivity. Psychological research has shown that context switching can result in 40% productivity loss, and the more complex the tasks, the greater the loss.
In his blog, Joel Spolsky, the creator of Trello and one of the founders of StackOverflow, puts it this way, "The trick here is that when you manage programmers, specifically, task switches take a really, really, really long time. That’s because programming is the kind of task where you have to keep a lot of things in your head at once. The more things you remember at once, the more productive you are at programming." Spolsky goes on to sum up, "In fact, the real lesson from all this is that you should never let people work on more than one thing at once."
The primary purpose of Team John is to shield the team from interruptions or at the very least funnel them all to a single person. With one of the teams I currently support we were getting a number of ad hoc requests coming into our sprints sideways, whether from our business partners ("Hey, can you get some numbers for us so that we can see how the latest campaign is working?"), or elsewhere within the technology department ("These three servers have critical updates and need to be patched by Friday"), or from within our own group ("This service is causing alerts. Does anyone even know what it does?"). Then you had production bugs and incidents which had to be addressed right away and suddenly we would have three developers dropping what they were doing to look at a single bug. I brought up the idea of using the Team John concept - we already had an oncall rotation for who would handle incidents outside of business hours. We decided whomever was oncall would also handle the interruptions that arose day-to-day. They could work on regular sprint work if there were no interruptions, but at least each individual developer wasn't being pulled away almost hourly.
We quickly discovered that there was a lot of Team John work once we all started funneling it to a single person. Not enough work to keep that one developer busy the entire time, thankfully there weren't that many bugs and incidents, but enough that they really ended up contributing very little on the actual sprint. Meanwhile the rest of the team was able to accomplish more work that it had in previous sprints. I think there were six or seven developers on the team at the team. By taking one out of the mix to handle interruptions our velocity increased by roughly 15%.
Rather than have Team John work on sprint work intermittently, we had the developer begin to pick up some of the technical debt we had accumulated and try to pay that down in between other interruptions. As we began doing that, some Team John work would carry over to the next week (our oncall schedule rotates weekly) leaving the next person in the rotation without much context for what was being worked on. After a while, and after adding a couple more developers, we decided that both the primary and secondary, which was always the previous week's primary, oncall developers would both be on Team John. This way as the primary rolled over to be secondary, they could bring the new primary up to speed on what was being worked on. With the addition of the second developer on Team John I don't believe the velocity increased, but it definitely did not decrease.
It seems counterintuitive that removing a developer from the mix would allow the rest of the team to go faster, but I think any development team that regular needs to deal with incidents or gets hit with work sideways, from outside the Scrum process will immediately see the value. Interruptions kill a developer's productivity. That loss in productivity is attributed to context switching: The very act of switching from one task to another results in a tremendous amount of lost productivity. Psychological research has shown that context switching can result in 40% productivity loss, and the more complex the tasks, the greater the loss.
In his blog, Joel Spolsky, the creator of Trello and one of the founders of StackOverflow, puts it this way, "The trick here is that when you manage programmers, specifically, task switches take a really, really, really long time. That’s because programming is the kind of task where you have to keep a lot of things in your head at once. The more things you remember at once, the more productive you are at programming." Spolsky goes on to sum up, "In fact, the real lesson from all this is that you should never let people work on more than one thing at once."
The primary purpose of Team John is to shield the team from interruptions or at the very least funnel them all to a single person. With one of the teams I currently support we were getting a number of ad hoc requests coming into our sprints sideways, whether from our business partners ("Hey, can you get some numbers for us so that we can see how the latest campaign is working?"), or elsewhere within the technology department ("These three servers have critical updates and need to be patched by Friday"), or from within our own group ("This service is causing alerts. Does anyone even know what it does?"). Then you had production bugs and incidents which had to be addressed right away and suddenly we would have three developers dropping what they were doing to look at a single bug. I brought up the idea of using the Team John concept - we already had an oncall rotation for who would handle incidents outside of business hours. We decided whomever was oncall would also handle the interruptions that arose day-to-day. They could work on regular sprint work if there were no interruptions, but at least each individual developer wasn't being pulled away almost hourly.
We quickly discovered that there was a lot of Team John work once we all started funneling it to a single person. Not enough work to keep that one developer busy the entire time, thankfully there weren't that many bugs and incidents, but enough that they really ended up contributing very little on the actual sprint. Meanwhile the rest of the team was able to accomplish more work that it had in previous sprints. I think there were six or seven developers on the team at the team. By taking one out of the mix to handle interruptions our velocity increased by roughly 15%.
Rather than have Team John work on sprint work intermittently, we had the developer begin to pick up some of the technical debt we had accumulated and try to pay that down in between other interruptions. As we began doing that, some Team John work would carry over to the next week (our oncall schedule rotates weekly) leaving the next person in the rotation without much context for what was being worked on. After a while, and after adding a couple more developers, we decided that both the primary and secondary, which was always the previous week's primary, oncall developers would both be on Team John. This way as the primary rolled over to be secondary, they could bring the new primary up to speed on what was being worked on. With the addition of the second developer on Team John I don't believe the velocity increased, but it definitely did not decrease.
No comments:
Post a Comment