“Daddy, you’re not doing it right!”

Parenting, pigs, pirates and Agile production

Part 1 — Pigs and parenting

Last week, I was playing with my three-year-old son, which for non-parents, means setting up his toys for him to play with, then being told off for not doing it the arbitrary way he decided he wanted it after it’s already been set up. It’s essentially a bad day at work.

His toy of choice on that day was his “Toot Toot” car set. For those not in the know, this particular vile invention is a set of cutesy little plastic cars with faces, which sing irritating songs on a loop until you remove the batteries. They come with a set of tracks you can construct into a road that runs between various overpriced “garages” and “car washes”. On the plus side, they are simple enough for a toddler to put the bits of track together themselves, just not to arrange them into a complex grid incorporating the various playsets along one loop.

It was while I was, once again, constructing this vast Toot Toot city across my son’s playroom that I heard this article’s titular exclamation. What I, apparently, was not doing right, was that, in constructing this multi-layered fractal monstrosity of plastic chunks, I had failed to group all the yellow-coloured bits of track together.

Now, forming a loop from straight edges and corners, quite clearly, requires a careful judgement about the lengths of track you choose. All the yellow pieces were of a particular length, so putting them all on one side may not have been possible and, even if it was, it would have meant deconstructing the whole thing and starting again.

Clearly, this was far from ideal, but nothing I could say could convince my son of this, which led to a tantrum. The issue was that my son knew what he wanted to accomplish, but had no idea of the best way to achieve that.

As such, the ideal would have been for him to leave that part to someone who did know how to do it, then benefit once it was complete. This, it immediately struck me, sums up the entire methodology of “Scrum” production.

Scrum is an Agile development concept, predicated on the idea that the tech industry is moving so quickly that, by the time software is completed, what the software needs to do, the system it needs to work on and the demand for it in the market will probably have changed. As such, developers need to be more flexible than a normal method of production can cope with.

Scrum, named after a misunderstanding of what the word meant in rugby, works by giving more power in the process to the actual developers, so decisions can be made by the people doing the work in the moment, instead of waiting six months to scale their way upstairs and back down again. Rather than an actual scrum, the creators envisioned passing a project along a production line to completion like a rugby team passing a ball between them to the try line, able to dodge obstructions or change direction without consulting their coach first.

The idea is that the manager can come to the team and give them a set of requirements and priorities, but it is the team who decides how to complete the work, how long it will take and whether it is possible in the first place. The old example that has been used in every Scrum training session, ever, is the fable of the pig and the chicken:

Hey. You think it’s not funny the first time? Try the hundredth…

The concept is that the people who actually do the work are “committed”, giving their time and energy to a project, while others are merely “involved”. As such, it should be the ones who are committed who make the main decisions. This is in the interests of the committed, obviously, but also it leads them to make the right decisions for everyone by balancing the needs of a project they care about enough to sacrifice for, with what they’re sacrificing.

My son’s arbitrary demand for all the yellow bits of track to be grouped together made perfect sense to him, but I was the one who understood the logistics of doing so and, being the one who would have to actually make it work, could balance the amount of ball-ache against my son’s whims and make the decision that it wasn’t going to happen. Thankfully, in this situation, I was the one with the authority, but in traditional workplace structures, it’s the toddlers who run the daycare, so to speak, which leads to mass worker demotivation and, probably, hammered profits from huge losses incurred by indulging uninformed whims.

Part 2 — Avoiding the black spot

Of course, I’m not a developer. I’m the head of an in-house copywriting team, but the principles of Scrum apply just as much to any method of production. I encourage my copywriters to see requests from our business in the same way that an agency would. We see the business as our client. We are committed, they are just involved.

In an agency, a client comes to the team with a request for work and the team respond with an offer of what can be accomplished in what amount of time, at what fee and, if that is not sufficient, they negotiate until there is an agreement. This is how Scrum development works and that is how an in-house creative team should work as well.

Though that isn’t the end of it. I apply a similar principle to my management style. When it comes to setting work for my team, I’m involved, they’re committed. This is why I don’t set deadlines; I ask my team how long the work will take.

For my own amusement, I tend to think of Agile Scrum a little like piracy. I’ve been fascinated by pirate stories since I was a little boy. I’m a devoted fan of Robert Louis Stevenson’s Treasure Island and, myself, am a treasure chest of pirate facts, so I’m also a big fan of the Game of Thrones-meets-Treasure Island TV show Black Sails. One of the things that series gets very right about old-school pirates, in terms of historical accuracy, is the democratic nature of their crews.

You see, pirates were all about honour among thieves. A pirate captain wasn’t a tyrant, they were chosen by the crew in much the same way that a company works today. It might be that a captain decided to start a pirate crew, so recruited a bunch of men to work for him by advertising what kind of culture and benefits they could offer. On the other hand, a crew just starting out would either promote a captain from within or recruit one from outside. They were so focussed on going with whatever worked, they had female captains in the 18th Century.

If said captain then didn’t earn the crew enough doubloons, or treated them badly, they might quit and go work for someone else, though if the whole crew were sick of the captain they might sack and replace him, just like a company. Of course, instead of giving him a redundancy package, they’d probably hang him, but swings and roundabouts…

The captain only had significant authority during battle. In the day-to-day running of the ship, all decisions were made by a public vote. The captain maintained control by force of personality and the respect of the crew only. The real power was in the Quartermaster.

The Quartermaster was elected immediately after the captain and became the representative of the crew. They maintained order on the ship, orchestrated votes and had the power to call for mutiny if they felt the captain incompetent. Unless the ship was under fire, the captain took their queue from their subordinates; the crew’s leader was a true servant of those they led.

In the case of Scrum, the “captain” is the “Product Owner”, while the Quartermaster is called the “Scrum Master”. The Product Owner represents the needs of the business and the customer. They are the voice of the “involved”. They choose the course of the team, decide what they will do and what their priorities are.

The Scrum Master, on the other hand, is the voice of the “committed”. They represent the team, take their feedback on timescales and feasibility, treat it without bias, then respond to the Product Owner with a plan.

The classic pirates we think of whenever the subject is mentioned were so effective in their plundering that nothing the two most powerful empires at the time could do managed to stamp them out, partly, I think, because of the practicality of their method. They were certainly more effective than a tantruming toddler.

So, whether you decide to take all the principles of Scrum on for your workplace or not, it’s still worthwhile considering who has the power in your business — the committed or the involved. If it’s the latter, you may find yourself keelhauled in the end…