“It’s just a toolbox” – essentials and accidents in scaling agile

– And what is agile, Phaedrus, and what is not agile – Need we ask anyone to tell us these things? – Robert M. Pirsig

Skateboarding is a curious sport. Like Scrum, it’s quite simple, as well as very difficult.

And like Scrum, a skateboard is by its construct, quite simple. Even the most spread visual metaphor of the concept of the minimum viable product by Henrik Kniberg has a skateboard as the starting point. Even the most expensive longboard set-ups stay under 500$, and your average agile coach can well afford to have several set-ups for different purposes

Essential tools

Just like agile transformation, skateboard maintenance – putting the parts together, exchanging them due to wear and tear, or switching to higher quality or otherwise more suitable gear can get quite complicated.

Now, if you have the proper parts and you know what you are doing, you can easily get away with just the following tool:

The essentials in skateboard maintenance

Here, you have 14mm, 10mm and 8mm sockets as well as an Y-shaped tool with three different screwdriver heads. Effectively, that’s all you need for skateboard maintenance.

You could think of the sockets as rolling wave budgeting, cross-functional feature teams, and working tested output for the customer to try out early and often. The different screwdriver heads could be imagined as the product owner, backlog refinement and retrospectives.

Accidental tools

When you start to improvise with the parts you’re using to put the skateboard together- the bolts and nuts you attach the trucks to the board, have low-quality bearings or wheels, or forego regular cleaning of the bearings, you’ll fairly soon find that there are quite a bit of more tools that you’ll be needing.

I have during the years needed way more than just the single multi-purpose tool in skateboard maintenance. In fact, I’ve needed the contents of an entire toolbox to deal with various problems and sometimes quite surprising scenarios.

Looking back, those problems and surprises have largely been due to the choices I’ve made out of inexperience.

I’m hoping that from the following parable you can glean some insight to your agile-scaling efforts.

Feature teams

By far most of the problems I’ve run into in skateboard maintenance stem from improvising with the hardware – that is, the bolts and the nuts which keep the trucks in place. This, I think, is quite similar to not going through the trouble of forming cross-functional feature teams.

In an ideal scenario, you have cross-functional feature teams capable of releasing into production upon demand. And likewise, in an ideal scenario, you have bolts made of a hard metal alloy which go through the board and the trucks just enough – some 5mm or so – for you to have room to tighten the nuts.

However, unless you’ve prepared carefully by getting just the right parts, chances are that the bolts are way longer. In such a case you can’t use the multi-purpose tool any more. You’ll need a ring spanner – think of a team product owner – to get proper grip of things.

The right-sized bolts and nuts made out of a hard metal alloy from the skateshop will – just like battle-hardened agile coaches from Nitor may cost slightly more than those coaches you would get from a big chain bodyshop who is into offshoring. From those, you’ll also find too soft nuts which may also be of similar inside but different outside diameters.

Team product owners come in many sizes and shapes

So you'll probably be needing many team product owners, pardon me, ring spanners, to keep the teams "self-organizing".

Another challenge is that due to the longer bolts, there is quite a lot of manual fastening work to do. You’ll probably want to get some kind of power tool to help with all the tightening.

A release train engineer to help team-to-team coordination

Actually, final tightening of the bolts is meant to be done by hand, because then you’ll then have a better feel of what is ‘tight enough’.

What happens is that while you may avoid the problem of doing all the extra tightening by hand, using a power tool may lead into a bigger problem than it solves.

Now, the hardness of bolts as well as the nuts can differ quite a bit. Your average hardware store parts are quite soft in terms of the metal alloy used. The bolts you’ll get for a seemingly premium price from a skateboard shop – are way more durable.

Using a power tool it’s quite easy to mess up the screw head of the bolt or the nut, even if you have a hard-enough parts at hand. But since you need the power tool in the first place, there is a good chance that you also have a cheap, soft bolt and/or nut in the play.

Your bolt may be tightened up half-way and there’s no way to further tighten it – or, in the best case, you get it tight, but you can’t remove it any more when you wish to change trucks or add risers because you want to switch to larger diameter wheels.

Thus, you choice of bolts – think of team composition – has created some unnecessary dependencies.

And as the bolts can’t release their grip of the skateboard, you’ll need DevOps.

Who you gonna call? Call DevOps!

As a rule of thumb, when you realize that you “need DevOps”, you are already quite deep into the “you should not have ended up here in the first place but you just didn’t realize that knowledge work does not scale like digging a ditch does” territory.

Often you will be be able to squeeze the hacksaw blade in just enough to do the sawing, but you need adjustable product increment clamps – two months, I mean clamps, is OK but three is better – to hold things steady while you slowly and surely grind away the unnecessary dependencies.

A program increment

But sometimes, however, you just can’t fit the hacksaw blade into place. Here, you’ll need system team pliers to hold the the stripped screw head in place while you untighten the nut just enough for DevOps to perform its release work.

The system team

There was one time when I had stripped the bolt heads so badly that I had to give up. Even DevOps could not help me.

That story had a happy ending as I gave the board and its now-eternally-attached trucks away for my friend who for some hipster artistic reason wanted to hang an extremely beaten up -looking longboard wreck on her Kallio apartment wall.

I wonder if you could do the same with front-end code which was abandoned because the back-end functionality that was needed got stuck somewhere in a back-end team’s backlog?

To sum things up, messing up the team composition – I mean the hardware which keeps the trucks in place – is by far the most common problem I’ve had to deal with.

Note, that when dealing with teams that don’t quite fit, people often try to seek for relief from Jira plugins or a requirement level taxonomy.

However, both tend to make things even more complicated.

Rolling wave budgeting

How tight you keep the kingpin – the main bolt in the center of the truck – is key to all direction changes. Myself, I tend keep the trucks as loose as possible – but not looser, for that causes wheel bite – which causes to board to abruptly stop while the rider continues forward.

But eventually, you have to change the nut which governs the looseness of the kingpin. You should replace it with another high-quality and properly fitting nut from a skateboard shop, and endure the premium price.

Of course, you might have similar-looking parts lying around – like your tried and true multi-year solution roadmaps you used to update as part of your yearly budgeting process. For some strange reason, the roadmaps might – just like the nuts lying around in your toolbox, at first still look ok.

Just like that nut you found lying inside your toolbox doesn’t quite fit the main bolt of the truck – or the multi-purpose tool you had. So you get out your solution roadmap and start jamming away like you used to.

Solution roadmap

I lost two trucks trying to fit seemingly ok-looking nuts onto the kingpin. In one case, the nut got stuck halfway in between, and did not get tight enough or come off no matter how I tried. In the other case, I managed to tighten the nut ok, but the soft metal it was made of took some damage in the process, and did not come off when it was time to replace it.

Since then I have resorted for premium kingpin nuts from the skateboard shop, leave the solution roadmap to other purposes, and stick with the 14mm socket of the multi-purpose tool.

Product owner

Great product owners are like high-quality skateboard wheels. They keep everything rolling. Without them, no matter what other parts you have, nothing much happens.

Unfortunately, great product owners do not grow on trees. In your transformation, you’d naturally want to use those people who are already part of the R&D organization – line managers, business analysts, project managers, or application owners and name them team product owners.

However, most of them are usually better as members of the cross-functional teams. What you would need is a single business-oriented product owner, not many “team product owners”.

Unless you find that person – whether from inside or outside of the development organization – who has a grasp of the whole and is able to communicate and mediate with all stakeholders, things just do not roll that well.'

The product backlog

The product backlog is like skateboard bearings – your prioritization, and ultimately your entire value delivery depends on it.

Even with great product owners, your backlog, just like the skateboard bearings, is bound to collect a lot of garbage. If you don’t clean it regularly – that’s 5 times more often than you’d think if you ride in a turbulent environment – your prioritization grinds to a halt.

When this happens, the insides of the bearings fall out and the outermost ring gets tightly stuck into the wheel. Essentially, with that ring stuck, there’s no using the wheel – or rather, all the four wheels that belong to the entire set – any more.

You could think of this as the entire team of teams grinding to a halt from the perspective of delivering customer value.

Here, coaching becomes handy. You jam the head coach into wheel and onto the stuck metal ring bit, and then the lean-agile leadership keeps striking it until the impediment clears.

Head coach and lean-agile leadership getting ready to remove an impediment

This can take quite a bit of effort and patience from both the lean-agile leadership and the head coach, but in the end you either clear the blockade, or break the wheel or the head coach. So far, I have always been able to clear the blockade, but not without some complaints from the HR department. Nowadays I usually go outside to perform the needed hammering.

Another thing the head coach can be used for is when you are removing the bearings for their cleanup. After removing the wheel, you jam the head coach inside the wheel, between the bearings, and then twist real hard to get out a set of PI objectives for the business to score.

Of course that’s much harder than having the business to work with the teams on a daily basis and collaborate on a properly-sized set of user stories in full mutual understanding of the business benefits in the first place. But unless you know that, using the head coach to twist out the PI objectives is a plausible way forward.

Business collaborating with development on a daily basis

The moral of the story?

During all my endeavors, I have managed finally to learn to always go to the skateboard store to get the right-sized parts made of the right kind of material, use only high-quality wheels and clean the bearings early and often – especially those I use to skate in the rain.

And instead of dragging a big toolbox around, I can do all my gear changing with a small hand tool that is easy to carry around.

I’m not yet sure about large-scale agile, but sometimes, at least in skateboarding, less can be more.