High performing teams that embrace Agile, continuous delivery and a DevOps mindset will rely on tooling to automate the humdrum of IT development; This makes tooling as important as a team member.
Organisations that are serious about delivering business benefit with their IT capability will focus on having Agile teams, they will promote the DevOps mindset and that achieving continuous delivery will realise the benefit faster than more traditional approaches; This is all true. The pitfall emerges when teams become reliant on tooling that does not have the necessary support.
Organisations with rapid growth or large established IT departments may suffer this more than most (though it can exist in many types of organisation). How many of us know of ‘Bill the tools guy’? The chap whose job it is to make sure your corporate source repository, artifact store, build-automation server and so on are working.
For illustration, let’s assume an organisation that has adopted a set of recommended tooling. Let’s focus on one tool – a build-automation server. Your team is working on a new feature which the business needs ASAP, you complete the review phase, the merge is done and… nothing. The build cluster is broken.
So with no release build, no automated regression can start and no automatic deployment to beta/live environments can happen. The lovely domino-like automatic approach has stopped. The business wants to know when your product update will go live. There’s head scratching, panic and someone quips “let’s do it the old fashioned way!”. Then you realise no-one really remembers the old way, or it seems so archaic no-one is prepared to try it. The only option is to start the hunt for ‘Bill the tools guy’. What? He’s on holiday today! Ok, so we give up. We resort to hope that on Bill’s return the build-automation server is fixed quickly and we can deliver our changes in a couple of days (instead of a couple of hours).
So what should we do differently? Tooling should be treated as a first class citizen. If you expect any of your applications to be available 99.9% of the time, then your tooling should be exactly the same.
It’s easy for organisations to overlook the support of tooling. Perhaps it is seen as an indirect cost and it is not a shiny new thing, so funding is only given grudgingly. Delivery Managers and Architects should always be promoting the importance of proper funding for tooling. I like to use the analogy of a traditional manufacturing plant. The plant produces value (new shiny things) using a conveyor belt (part of the tooling). If the conveyor belt breaks, how do you expect the plant to function? Maintenance of the belt is seen as an important by all (not thought as something Bill will fix when it breaks).
So how many ‘Tool Guys’ do you need? It depends on the size of the organisation. If we use rough Agile team sizes as a yardstick (so that’s 3 – 9 members):
- A single team – there should be effort allocated for maintaining and improving the tooling. If no tooling exists at the beginning then this proportion of effort should be much larger but, in a mature team it may be only be a small story/task every fortnight or so.
- 3-10 teams – this larger amount of teams being dependant on tooling warrants a dedicated tooling team to provide support. It also provides coverage when one of the tools guys takes a holiday! Some organisations may want to adopt a rotation system whereby people can be seconded into the tools team temporarily. This allows good knowledge sharing to occur and give the individual time to tackle the tooling that they feel let them down most. The rotation system has its pitfalls though; the tooling team needs to maintain a clear direction and moving team members out of other teams will affect productivity of all teams.
- 10+ teams – this should be covered by a large or multiple tooling teams. The tooling team(s) should see all of the other dev teams as customers of their products and so having requirements sessions, getting feedback and providing support are all necessary. The tooling team may be broken down into factions, each taking on specific duties: supporting the current tooling (the Operational side), implementing the next generation of tooling (new Development), and providing consultancy to other teams on how to best leverage the tooling (the Gurus).
These are only suggested sizes; organisations that leverage Cloud-based tooling should need less ‘Tools Guys’ in theory, but they will still need some. In these organisations the ‘Tools Guys’ are there to help establish and perhaps more importantly spread best-practice and ensure the tooling platform is as stable as possible. If team retrospectives are raising tooling as a problem area, then it’s a sign that more investment is needed!
Tooling provides automation and supports collaboration. It helps to accelerate teams into being higher performing. Tool usage becomes second nature to us and we become reliant on it but as tooling gets more complex it needs to be carefully considered, requires proper ongoing investment and to be seen as essential within any organisation.
