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?

Comments

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!

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

Cheers,
Peter
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?

Best,

Peter
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: http://www.betacodex.org/node/387. 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 www.betacodex.org/papers.
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.

Best,
Peter

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…

Scaling Scrum: SAFe, DAD, or LeSS?

Participants in last week's Scrum MasterClass wanted to evaluate approaches to scaling Scrum and Agile for their large enterprise. So I set out to review the available frameworks. Which one is best for your situation?

Recently a number of approaches have started gaining attention, including the Scaled Agile Framework ("SAFe") by Dean Leffingwell, Disciplined Agile Development (DAD), by Scott Ambler, and Large Scale Scrum (LeSS), by Craig Larman and Bas Vodde. (Follow the links for white papers or overviews of each approach).

How to compare these approaches? My starting point is Scrum in the team. Scrum has proven very effective at helping teams perform, even though it does not directly address the issues surrounding larger organizations and teams. An approach to scaling Scrum should not be inconsistent with Scrum itself.

Scrum implements a small number of principles and constraints: Inspect and Adapt. An interdisciplinary Team solves the problem. Deliver something of va…

What is the role of a Business Analyst in Scrum?

When I teach a CSM class, my goal is that my participants go home delighted (and of course that they learn about Scrum, that they are motivated to do Scrum, and can pass the online CSM exam). So after every class, I ask for feedback, in particular what could I do to get a better score. And for the next class, I strive to implement or address two or three of the points raised by my participants.

One issue that was raised was unanswered questions. It is annoying to ask questions and not get answers! Time is limited, so it is not always possible to answer all questions, so I thought, why not answer them on my blog? So here goes, first question:
What is the role of a Business Analyst in Scrum? This question is a challenge because Scrum doesn't answer this question! Scrum is a simple, team-based framework for solving complex problems. The roles and ceremonies in Scrum are designed to ensure that inspect and adapt can occur regularly with complete and correct information. Scrum does not…