We continue to miss the point. It is not Kanban vs. Scrum, it is "people over process"!

The Scrum vs. Kanban debates rage on in the blogosphere but I can't help but feel that our Agile community is missing the point.

Where is the "People and interactions over processes and tools" that is part of the core values?

I commented on Rachel Davies's post about what she calls W-Agile (waterfall disguised as Agile, I guess). In that post she identifies very correctly a typical anti-pattern of agile adoption (read the post, it is worth it).

However in the comments she continues one thread with which I disagree, and I think the evidence for my argument is easily found around us.

Rachel states:

Vasco, You say "I disagree with the statement that Kanban can do anything to help the W-agile teams." I find this an odd thing for you to say and wonder if this is a gut reaction or based on experience?

I have seen Kanban help make the end-to-end workflow visible as a first step to improve those invisible parts. I don't see doing that as incompatible with Scrum.

My assertion is that Kanban *alone* cannot help where other methods have failed unless *people* change their way of thinking by way of adopting the Kanban (or any other) ideas. Sure, people can change, and many of us have changed our mindset when adopting iterative software development, then XP, then Scrum and recently Kanban. That's a fine argument to make, i.e.: Kanban can bring things to people's eyes that other methods have failed to *and* change the way people behave. But that is a totally different than saying "Kanban brings success"!.

Please note that the key ingredient here is not Kanban (or Scrum, or XP), but the fact that people *change* their views, prejudices, etc.

From this quickly follows the following proposition / hypothesis:
A new method can make a team succeed if and only if the person (or people) helping the team adopt the method succeeds in changing the team's behavior.

Proving this hypothesis is rather simple: just look around you.

1. Have you seen teams succeed with some method and other reams fail with the same method? I have. Many. Generalizing this observation proves that *a* method alone cannot make a team succeed (no matter the method).
   
   
2. Have you see teams succeed while adopting method X with the help of person A while previously having failed to adopt the same method when helped by person B? I have. I have been person B and A myself! -> this proves that a person(mentor/coach) can have more impact than the method itself.
   

Given that a mentor/coach can have a larger influence on the team's adoption of a method than the method itself, and that the same method can lead to success or failure (Jurgen's argument as well) then it follows that method alone cannot be a pre-condition for success or for failure.

At the end of the day it is about getting the right help (or changing the help if it is not working) to adopt a method that fulfills your business goals (whatever that method may be).

Agility is about providing business value, not about methods.

Photo credit: David Kingham @ flickr

The challenge to the Agile community: can't we do better than PMBOK?

Another Knowledge Area in the PMBOK is Human Resource Management. The very name of the knowledge area already gives away the values behind it. It should not say “resource management”, it should say People Management!

The old-skool project management is very much based on the values of Scientific Management and Hierarchical organizations that have permeated our society for hundreds of years. Surely there is a lot of useful things to learn from this, useful things for sure, but not enough.
In order to be able to better handle the unpredictable situations we will regularly face, we need to be able to self-organize to better respond to the challenges presented.

What is self-organization? A technique to enable a faster way for a team to answer any problems that cross their path. Before, when following the command-and-control values a team would have to stop and wait for the boss to leave a meeting and finally ask the boss what to do next. Today, teams are required to self-organize, find a solution or several solutions, experiment and come-up with the final result. When the development iteration ends, the customer will tell the team whether the solution is good enough or not.

Not allowing a team to self-organize turns the old-skool decision makers into bottlenecks that delay the team and potentially the whole project.
Self-organization, however is not easy, you cannot order or wish it into reality. You have to work hard to enable that to happen. Scrum is a process framework that already has some of the needed ingredients for self-organization to happen.

Through the setting of clear goals and it's governance framework, Scrum allows the team to be left alone during an iteration (after having agreed to a set of clear goals). In the Sprint Review, the customer/Product Owner will come together with the team and evaluate what was delivered. This evaluation, in turn, is input to the planning of the next Sprint

So, the message of this series of posts is embrace change.
However, even changing some aspects of the project management body of knowledge (PMBOK) is useful, it is not enough!

A mind shift is needed;. So many new concepts are in play that we must start thinking about Software project management in a completely different way.

We need to change the culture in our companies/organizations. Companies as a whole need to change.

The challenge that is presented to the Agile community (and to the PMI Agile community by extension) is: "how do we benefit from the breakthroughs that have enabled Agile SW development to emerge"?

As a person that has tried the "change PMBOK" approach, my answer is that we need to forget about PMBOK and start afresh from a different set of principles to those that were at the origin of PMBOK.

The recent field of Product Development with authors such as James Morgan, Donald G. Reinertsen and others, together with the people writing about software development present a sufficiently convincing and engaging view to the software development system. Those views demand a serious inspection of PMI/PMBOK approaches. The Agile community must take up that task and come up with something credible. Just embracing PMI's Agile community is not enough. The world has changed enough to warrant a different approach.

Respect for people, the translator's edition

In the spirit of Lean my colleague and friend Mika Pehkonen writes how they are able to respect people, get them to do what they are best at and most motived to do. I'd say that's a win-win-win situation!

we pay our translators by the hour, not by word count. This means that the translator gets fair pay for their work, they do not need to spend time on proofing computer propagated translation matches that are by default out of context and they get to concentrate on their key expertise, translating concepts from one language and culture to the other. This, combined with assisting scripts and tools, allows the translator more ownership over their own work in ways that are more meaningful than just reviewing and translating words in a software.

That's a message that is often missed in the frenzy of Agile or Lean adoption. An example of that is the testing work, espcially regression testing, that is mostly done manualy and where the question "how many test cases can you execute an hour?" is the most asked question. That kind of approach clearly leads to what Mika has managed to avoid: spending most of your money in low-value added work that does not motivate and by it's very nature reduces the quality of the output. I usually compare this to the person in an old-school factory whose job is to make sure that the Coke bottles do not have too much coke in it while reviewing hundreds of bottles against a white screen...