Setting Up Global Agile Teams- Team’s Work Stream

An agile team ‘pulls’ work from the product backlog into a time-boxed iteration. After a couple of iterations, they know how much they can do in a given period; they have established a velocity. A common problem for managers new to agile is that they want the team to do more than the amount their speed indicates. So they pressure the team to give artificially low estimates, or to work long hours, and so on. [7]

Speed as an emergent property

An essential idea of a pull system is it recognizes that the team cannot control everything that has a bearing on their speed. The team is part of a bigger, interconnected system. That system can produce almost bug-free code at a specific rate, full stop. That’s the velocity. It might be stated as so many story points per week. If the faster output is needed, then the interconnections between the agile core team and the rest of the system need to be understood and improved to generate a higher velocity.

Velocity is an emergent property of the system. It cannot be directly commanded. If you get fifty story points this week by working twelve-hour days, when the usual was forty points, you are not working sustainably. You’re merely robbing future production to get a peak now. Perhaps a tool to do data profiling would result in higher velocity. Tools are an example of an interconnection between the core team and the organizational system.

Diagnosis of Comet’s Work Stream Problem

Comet team’s velocity eventually started decreasing. When more coding is done on top of quick fixes, the codebase quickly becomes brittle, and very hard to work with. Changes produce new bugs, and they take time to fix, hence a slower speed. An increasing bug rate tempts people to do even more quick fixes leading to a downward spiral.

In frustration over the developing problems, Comet’s managers reacted by pressuring the team to get more work done. Direct pressure cannot solve this–it intensifies the problems. The team responded by overly-optimistic “commitments”, and by refusing to devote any time to helping each other with tasks. Undoubtedly, that further slowed their progress.

In this instance, managers needed to recognize that the velocity was slowing because the group had decided to go with using quick fixes, and they were not taking the time to clean these out of the code. The question technical managers needed to ask is “why are we using an unsustainable technique to keep code production going at this rate?” Was the team simply bowing to inappropriate pressure to keep velocity up? That’s the surest way into trouble. Or did the team believe the quick fixes would be harmless? If so, then they should have seen that wasn’t the case and reversed course. Retrospectives provide an excellent way for managers to gain early insight into issues like these before they are compounded.

Lessons Learned for Keeping Team’s Work Stream Healthy

Agile teams should receive their priorities through the product owner, and no one else. Sometimes standards groups, regulatory representatives, or others expect to direct team activities.