Enable javascript in your browser for better experience. Need to know to enable it? Go here.
Blogs Banner

Can Agile Work in a Culture of Single Point Accountability?

When I was new to Agile and we were working on our first pilot project, I attended a panel discussion on Agile roll-out.  There, I asked the question, “Can Agile succeed in an organization that values single point accountability?” Much to my surprise, the panel was stumped!  “I don’t know.”  “I’m not sure, maybe.”  “Good question.” Once I got over the initial geeky pride-glow of having stumped the experts, I was deeply troubled.  The question plagued me day and night. I desperately needed to know. 

 You see, our Agile transformation was a grass-roots effort. Initiated in the technology department, we didn’t exactly have executive buy-in. (We even had to stop using the word “Agile” for a while because it freaked people out too much.) The company’s executives traditionally wanted to know who to blame when things went bad (and who to give bonuses to when things went really well). Single point accountability was engrained in our organization – from the org chart structure through to office assignments and the way individuals were compensated. Years of finger pointing and “hey, I did my part” left toxicity through-out the company. And, though I was spearheading the Agile effort, I honestly wasn’t entirely sure it was going to work in our organization.  But seeing the initial benefits, I so desperately wanted it to.  I was looking to that panel to give me a glimmer of hope that this could work in the environment I was given.

Well, I’m here to tell you – Agile can work at an organization that values single-point accountability.

I was sitting down with our CEO at the time, explaining this whole Agile thing (ah hem…sorry…our “new process”) and reviewing the successes we had with it.  He kept asking, “who do I go to for information on the project?”, “where do I get explanations on delivery issues?” etc, etc.  I wanted to say “why, anyone on the team!”, but the image of an angry CEO demanding explanations from a Jr. Developer flashed across my mind as a very bad encounter.  Put on the spot, I blurted out, “the Project Manager and/ or Product Owner – same as you always have, only now they’ll be better informed themselves”.  In retrospect, that was the perfect solution.

So, we set up a hybrid culture. At the team level, we enforced and re-enforced and even policed the team accountability concept.  For Agile to work, I do believe that the entire team needs to be bought into the goals of the project, empowered to make project level decisions and responsible, as a whole team, for delivery. That took a cultural shift, but at the team level, not at the corporate level, a much more achievable task.  For Senior Management, however, the Product Owner and Project Manager are still the “face” for the team. Those folks are responsible for upward reporting, explaining issues and risk, and are ultimately on the line for delivery. This is not at odds with the Scrum framework where the Product Owner determines the priority of features and the final go/no-go on launch-able product. The Project Manager still does typical Project Manager stuff, reporting progress, clearing obstacles, managing risk and setting up environments for success, though the methods are different.  The executives know who to go to for explanations, and who to discuss concerns and ideas with. 

 One key element to making this work, however, is that the product owner and project manager must shelter the team from the single point accountability.  As a Project Manger, when a project goes bad (which does happen in agile projects!) and the executive wants to know who messed up, never, ever - and I mean ever - give names.  “The team felt…”  “The team decided…”  “There were issues with xyz that the team is addressing by abc”.  When something goes well and the executives want to give a pat on the back, a similar rule applies.  Name ALL team members – no superstars and especially not yourself in particular!   

The organization where I rolled out Agile is still structured for single point accountability, from the org chart structure to compensation, but also a successful 100% Agile shop.  I’m sure everything would be even better if we could have changed those elements to something more democratic.  I’d be curious to hear from those who successfully changed the culture of a company to make this work…

Disclaimer: The statements and opinions expressed in this article are those of the author(s) and do not necessarily reflect the positions of Thoughtworks.

Keep up to date with our latest insights