Dev team leakage
February 6, 2009 § 1 Comment
It’s a bit of an anti-pattern that I have observed and want to discuss. Firstly though, I want to cut straight through an analogy that I believe helps to describe the situation (curiously, I have received some feedback on my propensity for using extreme analogies from a superb linguist colleague of mine who later was inspired to write an article on the subject: http://siddiqui.saleem.googlepages.com/sublimeanalogies).
If we can see the dev team as an animal in the jungle (and so forth we have other ‘animals’ such as QA teams, BA teams, Project Managers etc), then ‘dev team leakage’ refers to the cutting open of such a large and volatile jungle beast and of letting it’s gooey entrails slide out and slither amongst the wider natural setting of which the poor animal finds itself.
Yep. Basically it’s about breaking encapsulation. In the case of a dev team, there are many inner workings that need not be externalised to the outside world.
Technical ‘to-dos’ are one such example. On a typical agile project, the technical team would have a series of technical tasks that are being raised and dealt with on a continuous basis. This is part and parcel of what it means to develop software. A smart dev will think of something that needs doing that is not directly in his/her line of fire, and will flag it up as a task for execution at a more convenient time. The anti-pattern I am discussing would occur here if this ‘task’ was picked up by the wider process, and managed like any other software requirement. Suddenly the inner-workings of the software development team are exposed and tracked.
In this scenario, the project will seem a lot ‘busier’ than it should be, with issues largely of a fine-grained technical nature polluting the wider process. Woods would become difficult to see through the trees, and the ‘bigger picture’ – that is the production of functionality the business really cares about – is obscured.
Additionally, we can see that important business stakeholders may be presented with new, heavily-detailed information that they will probably not understand or frankly care about. In this example, it is easy to see that some stakeholders could get disenfranchised pretty quickly, especially if they were asked to start prioritising what technical tasks they would like developed in a particular order. They may also start to see the stream of ‘techno-babble’ being directed at them as a sign that the wider team is not focussing on what really matters, and they’d most likely be right.
This is a singular example of dev team leakage. Others include the micro-management of how developers might ‘pair’, or of dev stand-ups being folded into a wider stand-up consisting of various differing teams (missing the opportunity stand-ups offer for devs to give each other a ‘heads-up’ about various technical issues). Furthermore, there could be no mechanism (such as focussed retrospectives) in place for the team to continually improve, as improvement is dictated from above.
In taking this anti-pattern to the extreme, one can envisage the real risk that the ‘team’ may not actually be a ‘team’, but a collection of people acting as cogs in a larger machine. All the really good and essential stuff we get from ‘tight’ dev teams, such as collective code ownership, and not to mention a real sense of purpose and morale, would be lost.
At this point, I must stress that in order to avoid ‘dev team leakage’ we are not required to treat the dev team solely as a black box. Whilst the team may want to shield the complexity of its inner workings from the encompassing project, it ought to be able to stand up to scrutiny, and to justify the behaviours it extols on the wider system (a case in point is of the team justifying why they need more time to focus on cleaning up the house first, before tackling some additional requirements).
Here the root-issue is transparency. There is a traditional tendency of software project management that places the requirement on development teams to ‘push’ out a whole host of data out to the wider process, that might otherwise be kept internal. In the ‘push’ model (as oppose to pulling out data as needed), there is the danger that such data may be used for tweaking purposes, and that micro-management will eventually start to sink in, leading to a ‘command and control’ style of project execution.
The development team is of paramount important to any software development project. It needs to be able to hold up its head with dignity and will require experienced leadership to actively safeguard its own integrity. Importantly also, is that there are people on the outside helping to nurture it, providing the team with the space and resources it needs to operate.