Were Pirates Agile?

A good friend of mine has been watching Black Sails and he commented at how similar the structure was to a Scrum team and so I did a little research just to see what parallels can be drawn from a a band of pirates and an Agile team.

They are self-organising and self-managing

A pirate crew was very much a self-organising structure, all crew members got an equal say in decisions. Officers were generally elected including the Captain and the Officers. Almost all decisions were made by way of voting or the crew voted to delegate decisions to an individual. The crews were generally cross-functional, some specialist skills were in short supply so people with those skills were highly valued but generally crews were expected to pitch in and perform multiple roles.

They had a Product Owner

A captain was elected and his role was to set vision and direction, to be a single voice and he became ultimately responsible for the success or failure of the project, he would choose the next target or destinatation and would decide how to respond to navigation hazards that could be planned around. There were some perks associated with the job but generally loot was divided equally amongst the crew, a Captain may get 1.5 or 2 shares. Successful Captains would likely be re-elected unsuccessful ones may not be so fortunate. There was a distinct lack of authority in this role outside of navigation and strategic decisions.

They had a Scrum Master or Team Coach

Crews would elect a QuarterMaster, their job was to ensure the ship ran well, he understood the process and would do his best to coach the crew into keeping a ship running well. But the quartermaster did not have authority over the crew beyond this. Pirate crews were made up of runaway slaves, deserters from armies and ships or fortune seekers, many were not skilled sailors or fighters and most had a very strong aversion to authority and discipline. Quartermasters were first and foremost coaches. They would encourage the crew to learn the necessary skills and to keep the workflow effective. Quartermasters were likely seasoned sailors with lots of experience and the ability to understand how a ship works and how to coach the crew to do it. But unlike the Navy where discipline could be used to enforce order a pirate crew didn’t do this. If a quartermaster struck a sailor they risked being marooned as a consequence.

The crew had individual responsibilities

All crew members had responsibilities and were held accountable by their peers, all understood that the crew stood or fell on it’s own so anyone not pulling their weight or letting the crew down was a liability. Whilst there were officers the officers were organisational necessities not authority figures, it was about communication not control. Discipline was most definitely not enforced by officers.

But the best parallel is that they had working agreements

The pirate code – perhaps the earliest documented team working agreement? Each crew had and documented their code and held the other members of their crew accountable to it. The code contained how decisions were made, what decisions were delegated. How loot was divided. How the team interacted with each other. It was clear that in most cases it was a flat structure and that roles were temporary and were elected.

Pirates were generally forbidden from stealing, destruction, sexual assault, fighting, desertion, gambling or breaking up the pirate band. Some even mandated an early bed time!

Definition of done

This one in particular amused me, but the pirate code contained a definition of done for a Pirate. If a pirate earned 1000 pound then he may retire. If the pirate lost a limb they could leave the crew and would be given 800 pounds. (400 pounds if it was just a hand).

So are pirate crews agile? yes they Arrrgh !

Why Scrum so often fails

I should start out by saying that I am a big fan of Scrum, I think those that devised the framework possessed an agile mindset but also were mindful of human nature. They created a framework that had in built checks and balances and prescribed solutions to many of the most common problems. They also had an understanding of system level thinking – I’ll come back to that later.

The core of the system though are the core roles Scrum Master, Product Owner and Development Team. This triad is what makes Scrum so successful (when it works) and in my opinion it is the absence of this triad that is the root cause of the majority of the unsuccessful adoptions.

It is all about the mindset

However, I don’t think it is the role that defines this triad but the perceived mindset behind the role. Having a team that possesses a strong member with an Agile mindset, and the knowledge and skills to support it and the opportunity to focus on it; having a strong team member with a Customer mindset, a desire to engage the customer and ensure they get what they really want, and finally a cross functional development team with a strong Production mindset – that of delivering a well designed, high quality and maintainable product.

Scrum assigns named roles because they believe this give the best chance of having those mindsets on the team. But sadly it doesn’t guarantee them. There are far too many Scrum Masters that understand the rules, but do not have an agile mindset so create cargo cults and many product owners that build what they want not what the customer wants. And many development teams that over-architect, over-engineer or pay lip service to quality maintenance and even design.

The flip side is that you can create Agile teams without team coaches and without customer representation, sometimes they are very successful. But my assertion would be that on those teams there is someone with an Agile Mindset and calls out the team when they deviate, there is someone or multiple people that make the customer voice heard and engage them often and there is a cross functional team dedicated to building the product right.

In essence I am saying that Scrum fails when those in the named roles fail to live up to the role. And that in cases where a role isn’t named someone or more than one steps-up into that role. But in either case if those mindsets are not present on the team it is a recipe for failure.

Agile is a Mindset not a Rule-set

Scrum fails in essence because we assume a Role is the same as a Mindset. In this case Correlation does not imply causation. There are many great Scrum Masters and Coaches out there who posses an Agile Mindset, but sadly there are also a great many that lack it and see the role as the application of a rule-set rather than the application of a mindset.

System Level Thinking

This failure of mindset extends to the tired old conversation of Scrum Masters (and coaches) making themselves redundant on a team. There is a lot of talk about whether or not a Scrum Master(or Product Owner – or QA or designer etc etc) would be fully utilized on a team. Utilization of resources is a point of frustration for me (Note my deliberate use of the word resources). If you are concerned about maximizing utilization of someone then you are failing to see them as a person or see the value they provide and they have been reduced to counting the number of hours they occupy a seat.

A coach does not become redundant on a team when the team performs their tasks for them, a coach becomes redundant on a team when the team develops an Agile mindset and has the skills and knowledge to apply it without the coach’s help (and even then I see value in a diverse perspective). Utilization should not even be a consideration, value to the system should be the consideration. The same applies to the other roles – PO, designer, QA etc.

It is all in the name

Naming roles on a team is a risk, as I have described above if you get the wrong person it can undermine the balance, there is also a risk of knowledge siloing, and perceived expectations and divisions of labour when you name a role by areas of responsibility.

But far, far more damaging in my opinion is giving names that imply authority. Any type of named leadership role embedded on a team (Manager, Tech Lead, Team Leader, Architecture Lead) immediately stifles opinion and inclusion and undermines self-organisation on a team. Where roles like Scrum Master and PO stifle horizontal knowledge sharing, hierarchy stifles everything – so in my opinion this is far worse. If someone possesses a greater technical understanding there is no need to anoint leadership, it should be self-evident, and if it is not evident to the others on the team then likely the leadership title will subvert rather than support. Equally A self-organising team should not need a team leader or manager.

Ultimately it comes down to balance.

If you believe a team will be able to balance the three essential mind-sets without named horizontal roles, then the roles are unnecessary. If not (and I would err on the side of caution) then named roles give the highest probability of achieving this balance – especially if you have confidence in your hiring team that they are hiring for mindset rather than certifications. Those in the named roles should be sharing the mind-set as much as the knowledge.

But I if you feel there is a need for named leadership roles on a “self-organizing” team, ask yourself why you don’t trust the team to self-organize?

And finally if at any point decisions are getting made based on utilization of staff, in isolation and without consideration to the value they bring to the team. Then read the book “The Goal” by Eliyahu M. Goldratt. It will help understand that a focus on perceived local efficiencies and a desire for maximum utilization can actually be damaging to the larger system. Or read my post on efficiency

Self-Organisation vs Human Nature

I love the notion of self-organising teams, the belief that if left alone the team will pull together and solve the problem at hand. I also love the notion that a team doesn’t need named roles and that a team should be multi-skilled and can and will do any and all tasks necessary to deliver the work. As a model this does work, I have seen some great teams that can and do achieve this. But I don’t think this is the norm. There are certain foundations necessary for this model to work and for far too many teams they don’t have the necessary pre-requisites.

The team must have (or have readily available access to) all the skills.

The first is to have ALL the necessary skills on the team. Which may sound obvious, but when arranging and staffing teams we will generally ensure that a couple of the core skills are present and overlook or underestimate the importance of other skills. Or some of the other necessary skills are a lot less tangible and quantifiable, ‘softer’ skills, so we trivialise or undervalue them, when actually those less defined skills are likely to be the ones that mean the difference between getting by and excelling.

I doubt many question the claim that a software developer is a specialist skill, many people can have a go at coding but most serious products require a deeper level of understanding of the code than a casual understanding. I personally believe that the role of QA is similar, many can do the basics and run test cases, but a QA is a specialist skill and those gifted at it possess a perception that few developers even grasp let alone can mimic, they see a problem differently, a Dev tends to see a solution, a QA will see how it might fail.

Similarly with design, few Devs could design their way our of a paper bag, interfaces designed by engineers must give designers nightmares. I have seen engineer designs where every function of the system is displayed on one page giving a casual software tool the appearance of a complex flight control interface. That’s not to say that some Devs don’t have design skills, but generally they are lacking. And then there is Product Ownership – the term for a collection of tasks and skills that I feel is generally drastically underestimated and a skill set that is rare in your typical Dev. In my opinion it is potentially more specialized than that of a developer or QA, and is rarer to find on a typical team composed of Devs and QAs. (Named roles or otherwise)

Drawing the expected value out of a customer or stakeholder and verbalising it, is a skill, translating that into a story can be time consuming and painful, but when done right the Devs can fly and the stakeholders are happy. When done badly the developers churn and the stakeholders grow frustrated. Product Ownership is the vanguard of Agile software development. Being able to articulate a clear vision, and present unambiguous goals and priorities, to write stories that express the value of the work without imposing a solution on the Devs can mean the difference between a goo and a great product.

To do all this requires someone that can communicate effectively with the customer and stakeholders and then transfer that information clearly and effectively to the team, to ensure that the customer is clear on priorities and is happy with the progress requires soft skills that are not at all common. This is an extremely difficult set of skills to master. To simply assume that a team will inherently possess the skills necessary to fulfil this role amongst themselves is inviting disaster. To assume that the customer is clear on their intent or direction and can express that need to developers who may not possess the experience or will to probe and challenge to identify the true need is simply inviting disaster. Product ownership skills and experience is not an automatic side effect of being a Dev – far from it.

The team must be motivated to do any of the necessary tasks.

And secondly there is Human Nature. This may be seen as a generalization and it is a generalization that I have been trying for years to break, and to be fair there are some team members that do manage to evolve beyond their labels and become more cross-functional team members. Many will take on tasks relating to DevOps or DBA or even some of the other core skills on a team such as Design and QA but, BUT…

What I find more often than not is that if people are left to their own devices: Devs want to code, QAs want to test, Designers want to design and NOBODY wants to do documentation, administration, or talk to stakeholders or to integrate other people’s code. Maybe an over generalisation, but not too far off the mark.

The result..

And of course the whole point of self-organising teams is that they ARE left to their own devices. So we have a bunch of self-organising teams that have a mix of being unable or unwilling to do all of the tasks necessary to deliver the product. Obviously some do muddle through and when push comes to shove they will step up and get the job done. But many just don’t want to and will either leave it to others meaning that the more ‘Agile’ team members get all the crap jobs, or more commonly I seem teams finding ways to stay busy to avoid doing the tasks they don’t like or facing the problems the team would have if they actually confronted them.

In the book the Lord of the Flies, there is a goal – a signal fire, but the boys become busy and preoccupied with the more interesting tasks and having fun, thus neglecting the fire.

I see non-urgent (and not prioritized) features getting worked on, scope creeps all the time. The ‘build process’ becomes gold plated, and the team starts a whole bunch of ‘spikes’ that take far longer than should be expected. Everyone is ‘busy’ but no one is delivering value (nobody is tending the fire). All because the team is subtly, maybe subconsciously avoiding tasks they don’t like or don’t feel they are able to do. This may sound harsh, but I have seen this behaviour far more often that I would care to count.

So do I advocate self-organized teams? Do I advocate named roles in teams?

In my experience Product Ownership requires skill and dedication. Assuming a team possesses it simply as an after thought or assuming it is a secondary role is very damaging. For a newly formed team/project someone skilled in Product Ownership should be primarily focused on that.(Not necessarily in a named role, but certainly specifically assigned the responsibility). But that assumes there is someone on the team who possesses those skills.

It should be part of the responsibilities of that role to spread that knowledge and share those skills to avoid creating a silo – (why not pair? the way you would a Dev role?) Please note I am not saying this is essential, but I am saying that it can vastly increase the effectiveness of a team. and fears of a bottleneck are unfounded, a focal point and a single filter may actually be a benefit rather than a hinderance.

In a similar vein I think that in the early days of a team of a project a flow manager/coach/Scrum Master type role can help a team form and become effective far quicker. They encourage the team to be aware of the less desirable tasks and to emphasise the importance and value of getting them done rather than focusing on less important tasks. Helping the team understand the difference between the feeling of being busy and actually delivering value to the stakeholders/customer.

Understanding the difference between a necessity of having someone in a role and the benefit a team derives from having someone in a role are often confused and muddled and that is something I intend to return to in a future post.

Summary

I do believe teams can be self-organising and I do believe that named roles can sometimes lead to unnecessary siloing – but that is not a certainty and that goal should not dwarf the desire for an effective team. I don’t believe that throwing a team together and taking away titles will magically make a self-organising team. Self management is a learned skill like any other and takes time to learn and to perfect.

I also don’t believe that taking away named roles removes the need for specialist skills. Saying we don’t want a named QA or Dev or PO doesn’t mean you don’t need those skills on the team.

Understanding which skills are needed is vital for an effective team, whether it is self-organised or not. But even with the necessary skills the team still needs to understand the direction (vision) and be motivated to reach it.

All he does is state the obvious…

A few weeks into a new project and I was given the feedback that all I had been doing is stating the obvious and pointing out pretty much fundamental Agile principles and practices.

At first I was a little offended, I want to be adding value and so it was more than a little disappointing to hear what I felt like was a negative assessment of my work. And so I reflected on what I had been doing, partly to see how I could do better and partly to reassure myself that I was adding value in the right areas.

As I reflected I realised he was right. I had been stating the obvious, but what is not generally well known is that the obvious is not so obvious at all.

If there is one criticism that could be fairly leveled at me is that I let teams flounder too long before I step in. I have the belief that if a team solves it’s own problems without help they learn far more. If the team doesn’t appear to be seeing a solution I then move on to subtle hints – dropping seeds of ideas, and if I still feel they are not seeing things and I get to the point of ‘stating’ then it is because I don’t think the team is going to solve the problem without more pain than is appropriate for the situation.

In this case I had been challenging the team to produce working agreements and agree what their definition of done was. This is a scaled Agile project and my fear was that if the whole team did not agree ‘done’ together then one sub team’s ‘done’ would be imposed on all, or worse ‘done’ would be inconsistent between the teams. I also urged them to agree how they would integrate their work, I gave them advice on ‘Vertical Slicing’ and some advice on story writing, especially ensuring that the ‘value’ of a story was clear. All pretty obvious stuff – that is if you knew it already.

But these are new teams and some of the team are new to Agile, I suppose what is disappointing is that it was me that had to state the obvious, and not one of the more experienced team members. Self-organisation only works if the teams take the responsibility, and are then sufficiently motivated to deliver on that – more on that in my next post.

If my advice was so obvious why did it take an outside observer to see it? Why couldn’t the team see it for themselves? The answer of course is that solutions only become obvious when you see them, and it often takes an outside observer to point out what should have been obvious all along. All too often we see things as obvious after they have been pointed out to us or later feel they are so obvious we don’t say anything not realizing our team mates were struggling.

Realizing that common sense is not very common and what may seem obvious to one person may not be seen at all by another is actually one of the more difficult aspects of coaching. Sometimes I ask what seems like a basic or even stupid question because I sense others in the room may be unsure. Sometimes this makes me look like an idiot but sometimes it is clear that the stupid question was not so stupid. (And for the record sometimes I ask to promt conversation or clarification but often I simply don’t know and I figure that if I don’it know maybe I am not alone.

So please, state the obvious in your teams, especially if you feel it may not be so obvious to everyone else in the room.