Skip to main content

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....


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???


  1. Thank you so much for this.

  2. When adding keywords to a Job Description, contractors should write the keywords into complete sentences so that the content flows as a logical composition.guarantor

  3. The essayist, through this blog, has earned regard from numerous for all the correct reasons.

  4. I'm thoroughly getting because of your site. I too am an aching online journal machine, nevertheless I'm still not used to the complete thing.
    New Govt Jobs
    Maharashtra e- scholarship 2018 Application Form


Post a Comment

Popular posts from this blog

Advantages of using Test Management tools

Before I start talking about test management tools, let me clarify what I mean by the term test Management tools...  I am not taking about your office excel program where you store your test cases in. I'm talking about bespoke test Management tools, your quality centers or Microsoft test manager...
In the strict case of the term test Management tool, Microsoft Excel can be used as such, but heck, so could a notepad if used in the right way... For the sake of this blog post I am talking about bespoke test Management tools.
Firstly, what test tools are out there? There are many more out there today than when I first started in QA over 5 years ago. When I started the market was primarily dominated by a tool called Quality Center, this would run in a browser (only Ie unfortunately) and was hosted on a server.. Nowadays it's market share has somewhat dwindled, and there are some new kids on the block. 
One of the more popular tools is that of Microsoft Test Manager, it's big…

What is a PBI?

After my last post, I had the question of what is a PBI... so I thought i'd write a short blog post about what they are and why they are used.

A PBI is an acronym for Product Backlog Item. It is a description of a piece of work that your SCRUM team will develop and deliver. When you have a list of Product Backlog Items, you then refer to that collective list as a Product Backlog.

The product backlog is often prioritised and yourteam will work through each PBI, and release on a regular schedule... I am however going deep into the world of Agile development, which isn't entirely what this post is about, so I will stop myself now.

A Product Backlog Item is made up of the following:

Title - This is often a one liner that gives the team an idea of what the PBI is about, although it can just be an ID for the item and the team work off of that.

Description - Breaks down the PBI in a bit more detail, and can be written in any style, however I prefer it to be written as follows: 

By writin…

Dealing with Selenium WebDriver Driver.Quit crashes (Where chromedriver.exe is left open)

We recently came across a problem with Selenium not quitting the webdriver and this would then lock a file that was needed on the build server to run the builds.

We were using Driver.Quit() but this sometimes failed and would leave chromedriver.exe running. I looked around and found this was a common issue that many people were having. We (I say we, as we came to the solution through paired programming), came up with the following, that would encapsulate the driver.quit inside a task and if this task takes longer than 10 seconds, then it will clean up any processes started by the current process, in the case of the issue on the build server, it would kill any process started by Nunit.

        public static void AfterTestRun()
            var nativeDriverQuit = Task.Factory.StartNew(() => Driver.Quit());
            if (!nativeDriverQuit.Wait(TimeSpan.FromSeconds(10)))

        private s…