Tools, tools, tools – stop talking about tools!

screwdrivers

I mentioned something about Agile tools on LinkedIn recently and my profile lit up like a  lightbulb; clearly this is an issue that people feel strongly about. The point that resonated most with my peers in the Agile community is that there is too much focus on tools – a little ironic, the thing that gets people talking is a comment that there is too much talking…. about tools.

JIRA, Github, Jenkins, Rally, Sonar Cube I could keep going for a while. These are tools that are used in the creation of software, often associated with the most current techniques, some of these are very “Agile organisation” orientated, others more targeted at the integration and deployment end of the cycle, but all of them help teams in their ability to deliver.

However you don’t get immediate results just because you have them. “We’re Agile because we use JIRA”, heard that one before? So why all the fuss, why all the focus? I believe this is simply because they are visible to management- their use can be identified by those who oversee delivery and are interested in any changes that are taking place within our teams. It is hard to see commitment increase a little, but easy to identify a JIRA board being used where previously work was tracked in a chain of emails.

What needs to be made clear is that tools are a means to an end; and as teams look to improve their ways of working they will likely encounter and experiment with some tools along the way, adopting a few that help, tweaking them to their context. The point here is that the team is looking to improve and chooses a tool. The use of the tool hasn’t driven the improvement – it is psychologically the other way round. Which is why the imposition of a tool won’t deliver any results independently and measuring the use of a tool can give misleading results. If the goal of your organisation is to have everything in Jenkins then a mass rollout and migration is just what you are looking for, but it is more likely that the goal of your organisation has nothing to do with Jenkins, probably more to do with selling something, and customers, and other much more normal stuff.

 

I’d like to look at these tools using the analogy of, err, tools. The kind of tools that people thought of when we said tools 20 yrs ago, the kind of tools that people outside our little software bubble still use the word for, like hammers and screwdrivers etc. I have quite a few of these tools in my house, and I consider myself pretty good with them. If you were to come to my house you may see the consequences of those tools all over the place, Shelves that are up, still up, and have never fallen down, Skirting boards that fit, units that have small modifications to fit into irregular gaps etc. What you are unlikely to see however, is any actual tools. You’d probably be quite surprised if you went to a friend’s house for dinner and they brought out their new 48 piece socket set to show off, or a box of screwdrivers with those nice rubberised handles you can get now. They might show you into the lounge with a large television on the wall on one of those moveable arms, and tell you they put that up themselves with a hint of pride, but the tools they used to do it, well they won’t get much airtime. The consequences of the tools are what we are interested in, maybe we used a hand drill and took hours over it, maybe it was a rechargeable cordless drill, maybe that old drill that you inherited from your grandpa and is still going strong – doesn’t matter really from the perspective of the person looking at the TV on the wall.

The choice and use of the tool probably matters a little to you in terms of how efficient you are with your time, and if someone asked how you put your TV on the wall because they quite fancy doing the same, then you might talk about tools, so there is a time and a place for those kind of discussions, but should be very much focused on the job in hand.

The other point about DIY tools is that ownership doesn’t infer competency. Just because someone owns a drill, spirit level and a screwdriver doesn’t mean that they can be trusted to put up a shelf… If you want to know if you can trust them to put on a shelf, go to their house and put something heavy on their shelf….

The last point I want to make about tools is context. If you are putting together a shed on your own, and you have a strange star shaped screwdriver and a set of weird star headed screws, then you could work quite happily to produce your shed – and the resulting shed in terms of speed to build and quality would be the same as someone using a more standard screwdriver and screw head. However if there were 4 people building this shed and each person brought their own unique set of screws with matching screwdriver then it would be clear the kinds of chaos that would ensure and the inefficiencies that would result. In this slightly bizarre world of multiple screw types, it would probably be worth taking a minute before starting the construction to agree on a shared standard, and the more common the chosen standard is, the less discussion would be required and the simpler the adoption from the group.

 

So now, enough talking about tools…

Advertisements

Am I an Agile Coach?

A new year, a time for retrospection and ambition. There is no better time to ask those deep questions, what do I stand for, what do I want to achieve? I am sure many others are doing the same.

 

So, what do I stand for, what am I? Most people I think have a relatively easy time defining their job, Doctor, accountant, Traffic warden; but what do I do, what am I?

I laughed at the time when I asked my boss what he wanted me to do, and he said “Make things better”, but on reflection that is probably the best description of my role there is, implies a vague and varied scope but a clear intention. I get involved in team dynamics, quiet personal one to one chats, programme governance, Agile ceremony facilitation, process mentoring, training and business analysis support, a bit of this, a bit of that, things that I feel need to be done, things that others request of me; all of it with a view to transforming the current state to something better.

The broadest industry term for what I am doing would be an Agile Coach. There are some that would say that means someone that leads Agile transformation programmes, or someone that gives Agile theory instruction, or maybe only a valid title if you are actually coaching – as defined by the coaching institute.

I like Tobias Mayer and Jem D’Jeyal’s podcast where they discuss the nature of the term Agile Coach and state they like the term Agile Consultant – but they can use that term with less confusion than me because they operate as independents rather than permanent employees.

I used to get a little hung up on what an Agile coach is, and be able to argue that because what someone did, or didn’t do, that they weren’t really a coach. This is especially true in the rather philosophical argument between the Scrum Master and Agile Coach role. Now I am increasingly of the opinion that the definition of the term Agile Coach is really in the hands of the employers. If they say that person is an Agile Coach, then by definition they are, regardless of what we in the industry think. This is in part due to the power of the recruitment industry and the market place remuneration benchmarks that come with it.

The role of the Agile Coach is becoming standardized in terms of activities, industry experience, skills and reward. We may not like it but the wider society appears to have consolidated around a position that an Agile Coach is a progression from Scrum Master. Of course, many in our industry influence what those employers think, but the most powerful in the industry trend to be those that sell Agile rather than implement it – ultimately selling themselves.

 

So am I an Agile Coach – I guess that is up to you to decide.