Some important convergences towards Simplicity and Agility in Management

Some days ago I pointed in the Solutions-List to this video: http://www.infoq.com/presentations/Agile-Transitioning-Mike-Cohn
showing Mike Cohn reflecting upon the transitioning process towards an agile organization and how to deal with the complexity of such processes.

And today I become informed about very recent news about an upcoming "deal" between the "Project Management Institute" (PMI http://www.pmi.org) and the "Scrum Alliance" (http://www.scrumalliance.org/) concerning a much closer cooperation.

This may serve as one of some triggers for a "cultural change" within the Project Management scene..... And as Project Management is one of the core management fields in many companies it may serve as a trigger for some change in the "Art of Management" also.

Why?

Well, here the background:

With more than 265,000 members in over 170 countries PMI is the world’s leading not-for-profit association for the project management profession. PMI is recognized for the advocacy programs we conduct with governments, organizations and industries around the world as they recognize and embrace project management to achieve business results..
And the PMI until now is seen as "THE" "custodian" for a "classical" kind of project management based on the idea, that a project can be planned and steered based on five process groups:

* Initiating
* Planning
* Executing
* Closing
* Monitoring and Controlling

And, in most cases, a project traditionally is seen to have to follow the first four groups consecutively, like a "waterfall", and the fifth group is "across" all those four groups. As a consequence of that it is broadly acknowledged that it is necessary to collect and analyse all requirements in a very early stage (Initiating and at the begin of Planning) - and to "freeze" them latest at the end of the Planning. And following this strategy for a project until the of the third process (Executing) nothing else will be visible but documents. Documents for requirements, for concept on different layers, documents with plans. Not until the end of Executing testable results are visible for the user . That means: Between collecting the requirements and the outcoming results there is a time gap of many months ...
You can imagine, that this does not fit very well to complex business areas which are very versatile and does not fit to new business areas where the quite unclear requirements become more and more clear step by step during the practical work in this new area only.

And this was the motivation to create an "agile" kind of project management based on the idea, to "cut" the project into "vertical slices" which are completed slice by slice incrementally: Each slice is a usable "feature" and is done very quick like a "mini project" covering Initiating, Planning, Executing, Closing, Monitoring and Controlling within two or four weeks only...

That means metaphorically: The "waterfall strategy" is like producing a torte by asking the costumer to explain very specific how the whole torte should looks like and taste, then ask him to sign this as a contract, then creating a recipe, then organizing all the ingredients, than producing the bottom cake layer of the torte, then producing the first cream layer, then the middle cake layer, then the next cream layer, then the upper cake layer and then the chocolate coating. An NOW - after a long time of waiting - the customer sees the torte and can taste a vertical slice of it.... and the cook hopes, that there are no change requests for the next slice... because it is nearly impossible to change the torte....

The "agile" strategy is very different:
The cook asks the client to tell him some first ideas how the first slice of the torte should looks like and taste. He also provide some mock ups (maybe based on lego bricks) to co-create a better understanding. And maybe for the taste he also provides some "samples" out of his kitchen.
And then he starts to produce in a quick - but very professional and not "dirty"- way the first slice of the torte consisting of a piece of a bottom cake layer, the first cream layer, a piece of the middle cake layer, the next cream layer, then a piece of the upper cake layer and then the chocolate coating for this slice only. And he invites - after a reasonable short time - the customer to try it out. And the cook asks him to tell, what he should change for the next slice. And maybe the customer says: For the next slice please without the chocolate coating but with an additional cream layer with strawberry flavour! The cook responses: Great - no problem! It is a pleasure for me to do this!

So, "classical" cooking and eating means to plan and prepare the meal in the kitchen during many hours and then to eat it afterwards without sending many parts of the meal back to the kitchen with change requests.
"Agile" cooking and eating means to plan, cook and eat "incrementally" trying out a lot of improvements.
"Classical" is a noble and perfect dinner. "Agile" is a barbecue party.

So, there is no "good" or "bad". It is different. It depends on the context: At a camp site a noble dinner might not be the best choice...

Of course, this "torte metaphor" is very simple and does not cover many other aspects. But it is - I hope - a good platform to understand the meaning of the "four values" of agility, proclaimed in the "agile manifesto":

While there is value in the items on the right, we value the items on the left more:

* Individuals and interactions over processes and tools
* Working products over comprehensive documentation
* Customer collaboration over contract negotiation
* Responding to change over following a plan

So, you can imagine, that the "agilists" and the "classicists" understood themselves as very opposed.

In the agile scene some specific agile "frameworks" how to support projects have been created, the most important today is "Scrum", sustained by the "Scrum Alliance".
The Scrum Alliance is a global nonprofit organization with about 50'000 members committed to delivering articles, resources, courses, and events that will help Scrum users be successful. The Scrum Alliance's mission is to promote increased awareness and understanding of Scrum, provide resources to individuals and organizations using Scrum, and support the iterative improvement of the software development profession.

And now:

WHAT IS this very recent news about an upcoming "deal" between the "Project Management Institute" (PMI http://www.pmi.org) and the "Scrum Alliance" (http://www.scrumalliance.org/) concerning a much closer cooperation? A cooperation which may serve as one of some triggers for a "cultural change" within the Project Management scene?

Here it is (shortened):

Gregory Balestrero, President and CEO of the Project Management Institute, wrote in http://blogs.pmi.org/blog/a_chief_executives_perspective_on_project...
this message:

I recently attended the Scrum Alliance Gathering in Orlando, Florida. I attended with Mark Langley, PMI Executive VP & COO. The intent of the visit was to bridge the gap between the Scrum Alliance and PMI. But I guess the real reason we attended was to dispel the myths that surround the PMBOK® Guide ((which is decribing that kind of project management the PMI stands for)) and Agile practice. There is a widely held opinion that the PMBOK® Guide and Agile don't mix... they can't be "shaken, nor stirred" together.

I went with an open mind and actually had it filled with great information and dialog. It was enlightening. We met with Ken Schwaber and Jeff Sutherland, the founders of the Scrum concepts, and Jim Cundriff, Managing Director of the Scrum Alliance. All were really receptive and eager for collaboration. Ken and Jeff in particular were striking in their passion for simplicity and agility, with fascinating backgrounds and rigor in the field of software development.
However, there was great anticipation among many Scrum gatherers that PMI was going to do something wrong.
Well, my remarks were well received, and committed us to understanding one another and collaborating wherever we can. Many of the attendees really resonated on the desire to collaborate, and maybe recognized that there was a great deal of room to collaborate. The team of PMI volunteers that is putting together the new PMI Agile Forum was in attendance and was the driving force in getting us to attend the meeting. They too were energized.

There is no question that agile PM is a leading and emergent practice. It has great traction in software development and software installation. It is now moving into mainstream activities such as manufacturing in the telecommunications field. I was in Lima, Peru recently, and I spoke with many of the PM leaders there. Agile is on the move in Peru, where 60% of the GDP is driven out of small and medium sized companies. Agile approaches to PM are more the rule than the exception in these applications.

The movement in Extreme PM, Agile PM, and Scrum are movements which are critical to understand in reference with the standards developed by PMI. No doubt about it. And, the critical issue is to dispel myths and misunderstandings that would allow PM to prosper. There are zealots on both sides of the issue. In fact, I was as surprised of the number of PMI members who either misunderstood, or to the extreme, feared Scrum. So the issue is on both sides of the fence.
On the Scrum side, there was the perception that "the PMI way is incompatible with agile." And there is also a misperception that PMI "methodology" pushes against the movement of speed and agility in PM. Both sides of the proverbial fence share misunderstandings that needed correction.

The issue that gets in the way of an agile approach seems less the issue of the PMBOK® Guide, but more the issue of organizational culture. High demands for accountability, detailed planning, extensive reporting, mechanistic approaches, and hierarchical controls, may very well be averse to an agile approach. Maybe, just maybe, there should be strategic principles and values that address management style, instead of viewing management, and in particular project management as a tactical approach for which someone else is responsible.

IMHO there is nothing to add to this last paragraph...

Thank you for your patience to read all this "stuff"!
Hans-Peter