Skip to main content

Towards an 'Agile Manifesto' for Leadership at Stoos?

The Agile Manifesto has been the basis of a shared identity for software developers for over 10 years. A diverse group of people - the thought leaders of the 'lightweight project management' movement - got together it the Snowbird Lodge in Utah, identified some common beliefs, gave themselves a name, and (inadvertently?) started a movement. At Stoos, we want to catalyze a change for the better in management. What would an 'agile manifesto' for business look like?

As Steve Denning and I prepared the Radical Management Gathering in Zurich, we felt that future radical managers would want training and recognition -- they are doing something important! -- but didn't feel certifications was the right way to do.

The concept was simple: Recognized and Committed. A participant who attended the gathering and committed to the principles became a 'Recognized and Committed Radical Manager'. Recognition came from attending the gathering - there could be other ways to become 'Recognized' in the future - and committed meant that the individual had signed an affirmation of his/her belief in and commitment to the principles.

We toyed with the idea of formulating the principles as a 'Radical Management Manifesto' but decided that a 'me-too' manifesto wouldn't really help anyone. So although our text was inspired by the Agile Manifesto, they were 'just' principles and did not mimic the manifesto too closely:
The principles of Radical Management represent a process of ongoing discovery and include:
  • Goal: A shift from the goal of making money for shareholders (“shareholder capitalism”) to delighting customers through continuous innovation (“customer capitalism”). 
  • Role: A shift in the role of managers from controlling individuals to enabling self-organizing teams. 
  • Accountability: A shift in the way work is coordinated from bureaucracy to dynamic linking, in which those doing the work have a clear line of sight to those for whom the work is being done and can see the impact of what they do. 
  • Values: A shift from a preoccupation with efficiency to a broader set of values that will foster continuous innovation. 
  • Communications: A shift from top-down commands to horizontal, peer-to-peer, adult-to-adult communications. 
Radical managers espouse these principles and their supporting practices. They recognize that the principles are interlocking and need to be implemented in an integrated fashion.
Should we produce a manifesto at #Stoos? What are the alternatives? And what should we call ourselves? Unlike the lightweight methodologists, we don't even have a collective name for what we do (AFAIK). And if not a manifesto, what is something simple that everybody can understand which will make it clear what we're about?


Niels Pflaeging said…
Hi Peter,. Just some thoughts on your post about "principles" for the new movement. The principles you list here are the ones from Steve ´s book; i guess. I today have the same feeling about them as when I read Steve ´ s book a couple of months ago: These principles are not the right ones. Some of them are rather weak ("Goal"). Some or not precise enough, or to the point ("Accountability", "Values"). The only principle I find in the set that comes close to "right" is "Role". I like that one. It is quite concise. But overall, one notices that this particular set of principles comes from the mind of one isolated thinker/author with a certain focus. That´s why it is not "complete". There are gaps. You could not develop a real organization with these principles alone. So I suggest to revise the set of principles. Identify the missing ones and sharpen the existing ones. Regards, Niels Pflaeging
Thomas Botton said…
Hi Peter,

So where can I sign?!?

Joke aside, I think people tend to be used to manifesto.
As long as you state properly which people you target, aka managers, I think it won't be "one more" manifesto but THE manifesto for managers (don't know if such a list already exist in this format for any management framework though).

The good side with manifesto is that it can be displayed on a presentation during a conf, it can be listed on a A4 sheet, etc... It is precise and concise!

But well, I think one of the most important points is to clearly define the target. Is your manifesto targeting managers of managers? Or is it only for managers of team doing the "real job"?

Regards and good luck for the Stoos gathering!

Peter said…
Hi Thomas Botton,

You can sign right on the dotted line!

A bug in our concept: the participants could sign the principles and call themselves a 'Recognized and Committed Radical Manager'. One person declined to sign, saying 'I'm not a manager.'

The purpose of the Stoos Gathering is to catalyze a change. Creating a manifesto might be a means to that end, but the end is better management, viaable companies, and joy not frustration as a customer, consumer or employee.

So who is the audience? Maybe top managers, may be the 99%, and maybe all of the above...

Peter said…
Hi Niels Pflaeging,

My goal with this article was to document what we did and raise the question of what should happen at Stoos. Whether this formulation is adapted, adopted or discarded is really secondary.

At Stoos, I will encourage 'yes, and' discussions rather than 'yes, but' debates. The former is the basis of building a consensus, the latter leads nowhere.

I understand that you found the above concept of 'Role' to be a good one. What do your principles have in common with Radical Management principles? And what is missing from the RM principles?


Niels Pflaeging said…
Hi Peter, hi all,
to approach the discussion on principles for a better organizational model with a "yes, and..." is a great idea, Peter. My post was meant in that way, too, implictly, but you are clarifying it nicely with the disctinction you make.
I also saw that Jurgen Appelo, on his blog, started comparing the principles from different known approaches in a similar (positive) way- trying to synthesisze a robust set of principles out of all the work that has been done already. That seems to me to be a wonderful and productive way of working out principles, instead of writing manifesto.
The best set of principles I have found so far has its roots in the work of the Beyond Budgeting Round Table. This set doesn´t seem to be well-known in the Agile, Scrum, and development communities, but it is based on complexity-sciences and on very serious case-study research work that was done in the late 90s and early 2000s. It doesn not only consider principles for structures, leadership and values, but it also covers principles that have to do with what usually is referred to as "performance mangement" - a serious blind spot in all other set of principles I have come along in the past. E.g. almost no model approach offers concise principles for how to deal with goals/targets, compensation, and resources. Though no organization can be designed without solving those issues. The set of principles of the Beyond Budgeting Round Table contains 12 principles, which wer laid out in books first in 2003. More recently shortened/sharpened them and re-baptized the as the BetaCodex, but in essence, the set has remained pretty stable since 2003. You can read about the principles and its roots in this paper: I think they are well worth considering. You have Franz Röösli of the BBRT on board at Stoos, so it´s granted this approach to "contemporary leadership and organization" will be present at the gathering. I also recommend the other papers on our portal, under
Regards, Nieos Pflaeging
Peter said…
Hi Niels,

Thanks for the info!

Here is the link to the BBRT Principles/BetaCodex as a clickable link.

Thanks again for the constructive feedback.


Popular posts from this blog

Sample Definition of Done

Why does Scrum have a Definition of Done? Simple, everyone involved in the project needs to know and understand what Done means. Furthermore, Done should be really done, as in, 'there is nothing stopping us from earning value with this function, except maybe the go-ahead from the Product Owner. Consider the alternative:
Project Manager: Is this function done?
Developer: Yes
Project Manager: So we can ship it?
Developer: Well, No. It needs to be tested, and I need to write some documentation, but the code works, really. I tested it... (pause) ...on my machine. What's wrong with this exchange? To the developer and to the project manager, "done" means something rather different. To the developer in this case, done means: "I don't have to work on this piece of code any more (unless the tester tells me something is wrong)." The project leader is looking for a statement that the code is ready to ship.

At its most basic level, a definition of Done creates a sh…

Explaining Story Points to Management

During the February Scrum Breakfast in Zurich, the question arised, "How do I explain Story Points to Management?" A good question, and in all honesty, developers can be an even more critical audience than managers.

Traditional estimates attempt to answer the question, "how long will it take to develop X?" I could ask you a similar question, "How long does it take to get the nearest train station?

The answer, measured in time, depends on two things, the distance and the speed. Depending on whether I plan to go by car, by foot, by bicycle or (my personal favorite for short distances) trottinette, the answer can vary dramatically. So it is with software development. The productivity of a developer can vary dramatically, both as a function of innate ability and whether the task at hand plays to his strong points, so the time to produce a piece of software can vary dramatically. But the complexity of the problem doesn't depend on the person solving it, just …

Money for Nothing, Changes for Free

“Money for Nothing, Changes for Free” encourages both customers and suppliers to focus on value.

A key advantage of Scrum projects is that at least once per sprint you have something that could be shipped and no work in progress. You can change direction every sprint, and you can reevaluate whether the project is a good investment or if your money could be better spent elsewhere. Abrupt cancellation is risky for the supplier.

While the concept of an early-exit penalty is not new, Jeff Sutherland gave it a unique allure with his allusion to the Dire Straits hit.
Desired Benefit Incentivize both customers and suppliers to focus on functionality that provides genuine value.
Structure This works with Agile software projects because there is little or no work in progress. After each Sprint, functionality is either complete or not started. Work is basically on a Time and Materials basis with a cost target, often with the intention that the project should not use up the entire project budge…