The Agile Manifesto Needs Updates and a 14th Principle

Bryan Finster, -whom I don’t know from bars of soap but the DevOps community- wrote a piece upgrading the Agile manifesto and he lived to tell the tale but only barely.?Bryan asks if it’s heretical or a good idea in his comment accompanying the update - I don’t see why it can’t be both.?

Do I personally agree with every word choice? Maybe not but we certainly owe him a debt of gratitude for busting the conversation open. For instance, he entitled it “Upgrading the Agile Manifesto” whereas I would say it’s an “Update” and yes, a long-overdue one, because whether we like it or not it has been tens of years since it has been written. TENS. OF. YEARS.?

And it has become the talk of the Agile village. Both publicly where people attacked Bryan's credentials and in private where they questioned the need. I really enjoyed the latter kind of discussions and wish they would have been public because they were of the constructive sort and I think Bryan himself would have welcomed them.

One objection that I heard a couple of times that would not have occurred to me but seems valid is how Principle 6 mentions “face-to-face conversation” and that is surely clearly outdated in our virtual, distributed, remote work new reality.

The modifications Bryan makes are chiefly around the fact that people should have always been religious about the spirit of not the wording of the manifesto. That being verbatim was only needed as protection against Fragile not valuable in itself.?

I can not understand how anyone can object to the modifications Bryan proposes in the verbiage which, for the most part, are replacing “software” with “value creation for the end-user” and “software creation” with “continuous improvement/delivery” and “project” with “product” and “outcomes”. All just common sense really.

There are two parts there that I think Bryan may not have improved and I’m happy to tell him so here in public:

“5th Principle

Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.

I’m never motivated by a project. Now, if you ask me to solve a business problem and provide continuous delivery of valuable solutions…

Build product teams with ownership of the mission, ownership of the solutions, and responsibility for the outcomes.”

The reasoning for the change is 110% clear and the new formulation is awesome but losing the word “motivated” is a mistake in my opinion. As Google found, Purpose and Impact are essential to high performance.?

The other one that is practically the basis for our reason of creating our own?outcome, our Team Dashboard - a product our customers find valuable:

“12th Principle

At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

I frequently see retros every six months. Why shouldn't improvement be part of daily work?

The team continuously reflects on how to reduce toil and batch size to become more efficient, more effective, and more sustainable, then tunes and adjusts its behavior accordingly using data to validate the changes.”

Here’s why I disagree with the proposed change: firstly the initial formulation never meant to condone the 6 months time frame, surely. Secondly, and more importantly, we spend our days preaching how important this is at PeopleNotTech - “measure your behaviour and improve it, here’s a tool for it” and I think I speak for not only ourselves but retro support tools as well when I say that while “continuous improvement” is meant to reflect the importance of doing MORE not less of this reflection and correction work, the lack of fixed intervals serves as a license to postpone it or simply not do it.?

In other words, I think Bryan wanted to shake people into keeping the improvement, and the people and behavioural work as top of mind all the time and have it done faster than the ‘once in a blue moon” patterns he is starting to see emerge, but I believe that removing “regular intervals” gives people a license not to define and uphold the healthy habit contained in the ritual.

Furthermore, Bryan interprets “behaviour” as “toil and batch size” whereas I think there was a clear intention to include the human behaviour element in the initial principle formulation, if you reflect and find you weren’t flexible or courageous enough or were in the midst of unresolved and toxic conflict and that’s what affected the handful of sprints you did, you’ll realise that even if the toil and WIP were perfectly matched to the team’s abilities, the outcomes were still dismal and that is what needs working on.?

My proposal is either to leave the 12th principle alone or, at most to modify it to:

At frequent and regular intervals, the team honestly reflects on how to become more effective, then tunes and actively adjusts its behavior accordingly both from the point of view of the work and of their team dynamic and relationships using data to validate the changes.

Obviously, I personally love that last bit that Bryan added and left it in because we make a tool that helps measure so imploring people to use data is our day job but I can see it being the biggest sticking point of it all as well.

I put it to us that the only thing wrong with the 12th principle is how forgotten and obscure it is.?

The number of teams who fancy themselves as being "fully Agile" (don't even get me started on that formulation) that don’t do retros at all or do them once every few months in a soul-sapping round-the-room sterile sharing exercise at best, if not, more commonly a full-blown and much-hated blame festival, is staggering.

I believe there is a direct correlation between Psychological Safety and the frequency and openness of retros. The more of the former the more of the latter there is in high performing teams. So yes, Bryan is right, it should be all the damn time but removing the need for exact intervals and the commitment will only make teams that are unsafe even less likely to do any of the reflection and improvement work.?

I think what we’re missing is a 14th principle. (You guessed it, that's an airline-style omission of "13" for good luck, this is too important to risk it)

The 14th Principle:

To be sustainable, happy and high-performing, we are to put the human work and psychological safety of the team, first.

That would be an upgrade. A HumanDebt? busting upgrade at that.?

—————————————————————————

The 3 “commandments of Psychological Safety” to build high performing teams are:?Understand,?Measure?and?Improve

Read more about our Team Dashboard that measures and improves Psychological Safety at?www.peoplenottech.com ?or reach out at?[email protected] ?and let's help your teams become Psychologically Safe, healthy, happy and highly performant.

To order the "People Before Tech: The Importance of Psychological Safety and Teamwork in the Digital Age" book go to this Amazon link