Holocracy & Agile - It IS your job

We were in a meeting the other day, and someone in the meeting, said something that is one of my pet hates, "It's not my job"... This confused me, we are talking about delivering quality software as part of a team, and anyway that someone can add value in that team to deliver the ultimate goal is important, regardless of what their job title is.

This then lead me to think about how testing has changed over the past 5 years, and how I see it as a constantly evolving role, and it reminded me of something that I read about recently and wanted to blog about called Holocracy, it is about a method of running organizations and so it's given me a kick up the backside and here's the blog post.  It has some core principles, and these are:

• Flexible Organisation Structure - With Clear Roles defined around the work and not about the people. People can often take on a number of Roles in a company....
• More Autonomy to Teams & Individuals - Teams and individuals solve and take ownership of issues themselves, cut through the bureaucracy. Decisions are made by the teams themselves.
• No more big re-organisational changes - With roles changing regularly, re-orgs don't need to be big, they are managed internally within the teams themselves. Every team self organizes. 
• Transparent rules - everyone in the team is bound by the same rules, not one rule for one and one rule for another. Teams know what is expected of them as it's the same for everyone. There is no office politics.

You should, hopefully, by now start to see where we are going with this. Does the above sound familiar? Or at least similar to something?

That's right....

Agile

If you're not seeing the link, then that's no problem, I'm going to go into more detail, but first let's talk about the make up of an Agile team...

Some (not all) typical roles are:

• Product Owner - They are typically the projects key stakeholder. The product owner feeds into the team by prioritizing the product backlog during sprint planning meetings. They have a vision of what needs to be built by the team, and feed in however necessary. 
• Scrum Master - They keep the team and the scrum process running, and protects the team from outside influences. They can also help to achieve sprint goals in whatever way necessary.
• Tester - A Tester in Agile helps groom the requirements from the Product Owner, as well as having a specialized skill-set in Testing. They understand the technologies behind the system and help drive the testing activities within the team. They may or may not be involved in development work, and pairing with Developers (although I love to encourage this 2 way conversation between a developer and a tester, it can lead to some interesting conversations that help deliver quality), they are a key contributor to a cross functional team.
• Developer - Like a Tester they help groom the requirements for items in the product backlog, as well as feeding into the testing activities as well as writing Unit Tests, Integration Tests and even Acceptance Tests if necessary. They obviously develop as well, and again pairing with Testers is a very good experience.

As you can see there is a lot of cross over, especially between Testers and Developers. 

How does this relate to Holocracy? Hopefully you can see it, but don't worry if not....

Lets look at the key points of Holocracy and apply them to an Agile team:

• Flexible Organisation Structure - A team isn't bound by the traditional Tester/Developer roles, we have testers working with developers, and writing development code. They're not afraid to get their hands dirty, there is no shoving something over the fence, a developer will help test if necessary, just like a tester helping to develop if/when necessary, even if it is in a pairing activity. A tester or developer should not say in a truly agile team: "But that's not my job it's the testers/developers job" (which is the phrase which actually prompted me to write this post). A role isn't confined to any one individual, everyone pitches in to deliver quality software and make it a teams responsibility for quality.
• More Autonomy to Teams & Individuals - As teams own the product and the software, it makes sense to empower the team to make the relevant decisions themselves, all the way through to deploying it to production, we are trusting the team to write production code, so surely they should be trusted to deploy it to production with help? Again, there shouldn't be any throwing it over the fence to DevOp Engineers, DevOp Engineers need to be embedded in the teams and take responsibility with the team for the software.
• No more big re-organisational changes - We can look at this 2 ways, one is a direct view in that, the teams evolve, they don't have a sudden change in how they work, they hold retrospectives and improve, as mentioned above in the Flexible Org Structure, roles are not confined to any one individual, knowledge is or at least should be shared across the team. Or perhaps in a more abstract way, an Agile team delivers working software over comprehensive documentation, delivering software in small deliverable constantly delivering quality to the customer.
• Transparent rules - Everyone is aware of what is required to deliver software, there isn't anything that stops an individual from contributing in anyway possible in an Agile Team. 

Holocracy also talks about having new meeting formats, which are geared towards action and preventing over analysis... sound familiar? If you are familiar with the Agile Manifesto it should! 

Working software over comprehensive documentation

Teams should be delivering working software, and not be bogged down by producing unnecessary documentation or in a holocractic approach, over analysis. I'm not saying analysis is bad, it needs to be done, but sometimes you won't learn something until you action it. Failing early isn't a bad thing.

So there you have it, a holocratic approach to agile...

Although as I'm sure you're now aware, they are very similar, and lend themselves to each other very well, and as mentioned earlier, the whole sentence that sparked this post was hearing someone say:

If it helps deliver quality software, then it is your job, regardless of your "Job Title", regardless of your skill-set, we should be working together in an agile team to deliver quality software. If you ask one person what they have done to help deliver quality software over the past year, and then ask them again in another year, they will have 2 very different answers, times are changing roles are changing and they will continue to do so.

If people in the team are driven individuals and well motivated, then I do not believe you will ever hear someone say "It's not my job", they want to learn new things, and will step outside of their comfort zone to achieve it. The big questions is, how do we make people become driven and well motivated individuals if they aren't already???