The AGILE MANIFESTO is the opium of the people...

Recently, I’ve been seeing a continuous flow of articles blaming Agility.  The relevance of the Agile word, its misuse and its role as a blanket above approximate implementations is discussed. People also like making themselves look important by announcing the failure of Agility and, by doing so, claiming themselves above the crowds.

Meanwhile, I’m often meeting people at my job, within project teams or of course on the Net who say themselves Agile because they are doing a stand-up, but who really have never been above the Manifesto level.

Today, the AGILE MANIFESTO [1] really is the opium of the people…

The Agile Manifesto is no bible

As its authors have said, the Agile Manifesto is nothing but a snapshot…[2]

It is what a group of people has identified as being the best practices to foster project success in the IT at a given point in time.

Nevertheless, for some, the AGILE MANIFESTO has become the Agility’s bible. It is carved in marble, 10 commandments’ style. It is written in capital letter… A lot use it as a sword of truth and justify the least of their actions by quoting it (often approximately). Most by the way only know the 4 values and have forgotten about its 12 underlying principles. The crowds finally, “the people”, believe that Agility is born in 2001.

No, we are no witness of Agility’s failure. No the Agile word does not raise any issues. If there is a problem of implementation, it is due to a careless reading of the Manifesto.

ScrumBut and AgileWashing have already been denounced, but too often we blame these situations to a non-literal respect of practices. Contrary to that, I believe that it is those really practices and more precisely their portrayal in the AGILE MANIFESTO, which, by taking away our freedom of thought, prevents success in our projects.

Passing the Shu level

In Japanese martial arts, there is the Shu-Ha-Ri concept.

Credits: Original design by N. Lochet

I’m not the first to make the comparison [3] between those 3 stages in martial arts mastering and Agility but I find it very appropriate. Today, whatever some may think, we largely stay at the Shu stage; that is to say the learning of fundamentals.

In the past, the Agile Manifesto has been useful. By its simplicity and visibility, it was successful in attracting attention. By its influence, it allowed a lot of people to consider new approaches in project management.

Today, the AGILE MANIFESTO is like the ball and chain of the convict as it is preventing us to move at full speed. It established itself has a barrier, which hamper our ability to access the above stage of the Ha (breaking with tradition) and moreover the Ri (transcendence).

I’ll give you as a proof this only example that you probably have witnessed yourself when a customer ask you the following:

- But then, I cannot do documentation anymore?

Here, the Manifesto doesn’t help…

Most do not go behind the first part of the proposition “working software” and think they are not allowed to do the second part “comprehensive documentation”. In such times, I wish I could sweep away the past (knowing that the situation is even worse in French due to the ambiguous translation). Thus, not crystalizing reckoning around the Manifesto, we could better move forward and finally progress towards the Ri.

Discarding the “command and control” philosophy

I’ll say it differently. If the Agile Manifesto has become a hindrance, it really is because it has been deified. I’m not criticizing its content, but really this way of considering it as a checklist that has to be done without discussion…

Credits: Original design by N. Lochet

As opium is fogging our senses, the AGILE MANIFESTO is blinding us. Today, its omnipresence is such that as soon as we touch it, people call to arms…

If we have come to that, it is because we have to fight against the conditioning of 40 years of Waterfall-like development. [4] It is this “command and control” way to look at projects, which conditioned us into accepting checklists as absolute truths.

To succeed in our implementation of Agility, we should stop to stupidly apply “administrative” behaviors induced by our past practices. If they made sense before, in a “command and control” approach, they no longer need to be in an “inspect and adapt” approach.

Agility behind the Manifesto

No, Agility cannot be reduced to the Manifesto. That would be whipping a dead horse but we should nevertheless remind that Agility is not born in 2001. It is not some kind of discovery that we would suddenly have done, but a history of research in project management. An inheritance within which we could selectively quote:

• The Mythical Man-Month (F. Brooks – 1975)
• No Silver Bullet – Essence and Accidents of Software Engineering (F. Brooks – 1986)
• The New New Product Development Game (H. Takeuchi, I Nonaka, Harvard Business Review – 1986)[5]
• Scrum introduction at OOPLSA in 1995
• Developing Products in Half the Time (P. G. Smith, D. G. Reinerstein – 1^st Ed. 1995)
•  The first use of XP in 1996 within the C3 project at Chrysler[6]
• This inheritance doesn’t stop in 2001, but is continuously growing with for instance:
• Kanban – Successful Evolutionary Change for your Technology Business (David Anderson – 2010)[7]
• The Lean Startup (how today’s entrepreneurs use continuous innovation to create radically successful businesses) (Eric Ries – 2011)

And so on and so forth…

The list is long and clearly shows that a rich academic background inspired Agility.

As for the word “Agile” itself, which use we tie to the publication of the Manifesto, it can in fact be seen as soon as in 1991 within a report ordered by the US government and called 21^st Century Manufacturing Enterprise Strategy.[8]

This report, published by the Iacocca Institue, studies the difficulty of numerous American companies in offering an industrial organization as flexible as the one from their Japanese competitors.

There we find, applied to manufacturing, a great many of the principles taken later into the Agile Manifesto in IT. They are summed up there as early as within the introduction of the report:

« The term « Agile Manufacturing » describes a manufacturing system with extraordinary capability to meet the rapidly changing needs of the marketplace, a system that can shift quickly among product models or between product lines, ideally in real-time response to customer demand. »

Being agnostic and thinking by ourselves

Thus we should stop calling ourselves from an AGILE MANIFESTO as we would be claiming ourselves from a religion. We should learn to go behind, to understand what are the foundations and goals of such or such practice. We should consider the appropriateness of these practices within our context. Rabelais in Pantagruel wrote, “Science without conscience is but the ruin of the soul”. We should educate our conscience. We can apply, we can adapt, but we do it consciously, with the knowledge of all consequences.

• We should be lazy and only use the bare minimum of practices useful to us.
• We should iterate, not because it is one of the 12 principles of the Manifesto, but because we understand the benefit of reality checks.
• We should increment, not because it was asked of us, but because we understand we may not need everything, right now[9].
• We should communicate, not so that we stand by an Agile practice but because we value sharing information as soon as possible.

And above all, we mustn’t prevent ourselves from borrowing a specific technique or tool from other fields or even to innovate because this isn’t in the AGILE MANIFESTO.

Learning to be craftsmen of continuous improvement

We shouldn’t be cooks who follow a recipe, but learn to be Master Chefs, able to mix sweet and salted, to borrow to physics and chemistry to do molecular cuisine and thus reinventing ourselves all along so that at last we can do continuous improvement.

---

[1] Capital letters are used on purpose, and I ask for your forgiveness, I have nothing against the Agile Manifesto itself but against its display on a pedestal. I’m thus opposing within this text the Agile Manifesto, which stands for the genuine text, to the AGILE MANIFESTO, which is its deification.

[2] For more details, you should look at Ron Jeffries article : Beyond Agile : New Principles

[3] Personally, I have seen it first within Alistair Cockburn book Agile Software Development : The Cooperative Game (you should read it, if you haven’t !)

[4] An all of this, because of a mistake since Winston Royce was already denouncing the limits of the model within its very description in his 1970 article Managing the Development of Large Software Systems

[5] Which inspired the Scrum framework and within which the Scrum terminology is used for the first time

[6] Contrary to what we often see in France, Scrum really was presented before XP.

[7] Following upon the Kanban systems implemented at Toyota as early as in 1953!

[8] The complete title of the report actually even is: 21st Century Manufacturing Enterprise Strategy An Industry Led View of Agile Manufacturing

[9] We may never need it and by all means, in appliance of the « Requirement Uncertainty Principle » of Watts S. Humphrey, we will only be able to know after demonstration!

I want your tests!

Programmers usually dislike testing.

With waterfall projects it was easy for them to just disregard testing as it was done at the very end of the project and usually by different teams.

Martin Fowler came up with a great analogy to explain the importance of testing. It's called technical debt.

Put in a few words, test early or it will cost you.

Think you are making a loan to your bank to build this house you want. You'll be able to get it quick but you'll end up paying twice the price once you add the interest.

Testing is the same, you can disregard it to go faster, but in the end it will be much more expensive.

This is rather natural when you think about it.

If you test your code just after having written it and it fails you'll know which part is involved. It will be fresh enough in your mind that fixing should be done in a matter of minutes.

If you do that at the end of a waterfall development you'll have no idea which part of the code is involved and you'll probably won't remember how you did the trick.

There's a programmer's joke which says:

//When I wrote this, only God and I understood what I was doing
//Now, God only knows

Your probably get the idea what you'll be facing...

The good thing is that testing early is now more and more widely accepted as a good practice.

What I'm more interested in is automatic testing. I've met quite a few teams finding that hard to do and not getting the point of doing it automatically.

The fact that Scrum says nothing about engineering practices explains testing is quite often overlooked.

This is the reason why the teams getting the best results are often complementing Scrum with XP.

Well the first argument for automatic testing should please most programmers.

If you dislike testing then why not let the computer do the task?

Actually you wouldn't be testing any more but writing testing code. You could go back to the beauty of pure coding...

The true argument though is tied to what you want to achieve with Agility.

With Agile projects you want to get two things:

A working software (which is the reason why you want to test early and often)

The ability to respond to change (which is the reason why you want to automate testing)

Indeed if it takes you a full day to test your whole software each time you change something, your ability to embrace change will be quite limited.

The more frequent changes you would make, the more danger you would add to the project. You could end up being in a situation where you don't have working software anymore very fast!

However with automated testing (part of the build process and ideally no longer than 10 minutes) you are safe from side-effects of change.

Now you see how you can be flexible, fast and still maintain working software!

Credits: Original design by N. Lochet (based on J. M. Flagg 1917' poster)

Addiction in games, almost there

I love addictive games.

I know it probably hurts the industry. 

When looking for reasons of society failures, people prefer to find excuses rather than looking at their own faults.

Movies used to be blamed for the violence in society. But this isn't trendy, people needed new excuses and video-games were a perfect one.

Think about it: people playing rather than working? Surely that must be evil?

Nevermind that playing is universal and part of all cultures, video games are just wrong!

So when I say that I love addictive games I deliver new excuses for the ones willing to blame everything on others.

Depiction of violence in video games transforms us all in serial killers.

Addictive games will get us all in serious need of psychological therapy (or not).

That being said, I still love addictive games.

When I am in front of a video game, I am playing. I'm not trying to educate myself, I'm not trying to escape reality, I'm just seeking entertainment.

A good game has to deliver fun or it misses the point. Fun is an essential characteristic of games as defined by french sociologist Roger Caillois in his book "Games and Men".

An addictive game is a game that knows how to distillate the fun so that we keep coming back for more.

That's not easy task, as it is not only a matter of delivering good emotions.

A linear emotional curve is not a good experience.

For emotions to be interesting they have to vary in kind and in intensity.

A good game will have you experiencing frustration.

But contrary to a poorly executed game, a good game will know how to pace the emotions it delivers so that you experience the right amount of frustration at the right time.

Creating addiction in a game brings one kind of emotion. This is not sufficient for the game to be enjoyable but it is a really good step towards it.

To create addiction you have to really understand two things: rewards and staging.

Neither rewards nor staging by themselves are sufficient to create addictive games. It is by successfully using both that you get the best results.

When speaking of these game design techniques there is one name that gets quoted a lot an that is Blizzard Entertainment.
Blizzard is a company which has taken addictive game design at the heart of many of its products. If you want to try good examples of addictive game design, you only need to play Diablo 3 or World of Warcraft.

In addictive games, rewards have three qualities:

Firstly, they are frequent.
It's rare to spend more than a few minutes (sometimes even seconds) without getting some kind of reward. Knowing this, the player is often tempted to play longer in the hope of better rewards.

Secondly, they are varied.
If the game keeps giving you the same reward over and over again, things will become dull soon enough. The player needs to know that a reward is close, but he still needs to be surprised when it comes. The more often he gets the same reward, the less interesting the reward. The more different kinds of rewards you can give, the better.

And finally, they are meaningful.
Rewards need to make sense to the player. They have to be useful for the game at hand (coherent with the universe). They need to be relevant to the challenge to overcome (proportional to its difficulty and intensity).
In this regard, context has a lot of influence.

For instance you are designing a racing game and want to give the player a car as a reward. Depending on situations this could be a good or very bad idea.
If the player only has a few cars and the car given is better, this is a good reward.
If the car given is less valuable than the ones he has, this will be perceived as a poor reward.
If he already has a lot of cars, getting a new car (even a good one!) isn't very interesting.
If the car given is of low value to the player and is coming after a great effort (say after a difficult and lengthy race) this could actually be resented.

This makes it very difficult to design meaningful rewards because it is quite complex to know which is the player's situation.
Indeed, no one player will play your game the same way (players have different skills and playing behaviors). People will go through different playing experiences, especially if your game is non-linear. What can be meaningful for someone may have no value for others.

Addictive games do not only offer good rewards, they also stage them in a way that motivates the player.

This is what I call the "almost there" concept. 

It takes two forms: gameplay staging and visual staging.
Gameplay staging is the idea that the player is presented with several gameplay loops (objective > challenge > reward) of various lengths  simultaneously.
The goal is that he always has something to do and that he always is almost finished with a specific gameplay loop.
Erich Schaefer in his postmortem of Diablo II puts it this way:

"There's always a quest that is almost finished, a waypoint almost reached, an experience level almost achieved, and a dungeon nearly cleared out."

This puts the player in a situation where he enters a never-ending streak of rewards.
There's always something coming and always a chance of getting something big: this creates addiction.

Visual staging is probably less well-known and used than gameplay staging but is equally important (if not more) to motivate the player to move forward.
The idea of visual staging is to graphically stage the progression towards a reward so that the player sees he is close from getting it.

The experience bar in World of Warcraft is a very good example of visual staging.

Instead of putting an interface that only shows your progress towards your next level in XP points, Blizzard displays a graphical way to see your progression.
The bar visually shows you where you stand.
When the bar is nearly full, chances are that you won't be quitting the game because you not only know that a big reward is close, but you also see it.
Actually the bar is even divided in small bubbles for a finer sense of progress. Back when I played people where often chatting messages such has "one bubble left" to tell others that they were close to their next level.

World of Warcraft ™ visual display of level-up progress - © 2013 Blizzard Entertainment, Inc.

Visual staging can not only help you to see your progress towards a reward but also what to do next.
This is a bit like in "Hop-o'-My-Thumb" (Little Thumbling), pick up a stone and the next one is immediately visible to you.
Translated into games, as soon as the player finishes a gameplay loop, he sees the next one right in front of him.
Again, in World of Warcraft when you finish a quest, a big exclamation mark usually pops on top of a nearby NPC's head.
This is your rather obvious clue to what to do next!

I could go on discussing tips for designing good rewards for quite some time. This post only briefly touches the surface of good addictive design.
But hey... my game is waiting.

My quest is almost finished...

Credits: Unknown

Has Scrum made us forget what is Agility?

According to Ken Schwaber, in 2009 about 84% of the organizations using Agile processes were using  Scrum.

However most people using Scrum were in fact using what was described by Martin Fowler as Flaccid Scrum. That is to say: inadequate variants of Scrum which were not yielding the full benefits of the methodology (when not actually making projects worse).

Now that we stand 4 years later, the figures are probably even bigger and the number of Flaccid Scrum even greater.

Scrum has been widely embraced in IT projects. And, indeed, that's quite understandable. Scrum methodology is lightweight, easy to understand and easy to practice. When compared to industry heavy methodologies such as PMI practices, Scrum offers a breath of fresh hair most welcome by project managers.

More and more often when we speak of Agility, we tend to really speak of Scrum. The line between the two is increasingly getting blurry.

This is problematic as it is easy to fault the whole of Agility for badly executed Scrums.

Scrum became dangerous to Agility as it was used by more and more people not knowing Agility in the first place.

Agility is a state of mind (for some it's even a philosophy), it is not a tool or process.

No tool will ever make you Agile, it is the way you look at things that will.

Scrum is a framework for project management. 

It is nothing more than a tool. Scrum, by itself, is not inherently Agile. 

As all tools it won't work if not used properly.

Following Scrum, even when done perfectly, does not make you Agile.

When starting on the Agile journey, you first need to understand the philosophy before learning how to use the tools.

If you want to get the full benefits of Agile tools, you need to understand their purpose. 

To learn that, you need to know what are the roots of Agility.

It would be easy to limit the roots of Agility to the signature of the Agile Manifesto in 2001.

That would be forgetting why experts met in the first place.

People only remember outcomes, not the path to discovery.

When the experts met in 2001, software development was getting more and more complex. 

With increased complexity, the rate of project failure was becoming higher.

Although improvements had already started (Scrum was initially published at the 1995 OOPSLA conference), software development project methodologies were still largely based on project methodologies initially developed for industries (such has the infamous Winston Royce waterfall model, which incidentally he never recommended). 

We were using methodologies suited for stable environments in an unpredictable world.

So the question that guys behind the Agile Manifesto really wanted to answer was:

How do you lead a project in a complex environment?

That is, how can you drive a project in a fast changing environment when all parameters become unpredictable?

In unpredictable contexts, traditional project management proves useless. It only offers techniques to increase predictability and can never be 100% successful.

The only thing you can do is to adapt to new events you couldn't predict. And you want to do so the fastest you can so that it doesn't cost you.

The purpose of all Agile methodologies is to increase your adaptability to change so that the impact of unforeseen events remains constrained.

Scrum is in fact trying to offer a framework that will make it easier, quicker and less costly for you to adapt to change.

For instance, the Daily Stand-Up is nothing but a tool to increase communication, so that you know about change the minute it occurs.

If, in the Backlog, you prioritize tasks according to their added customer value, it is in an attempt to keep project costs at their minimum. This way, if you need to change your plans (and you will), you won't be throwing away work you could have dispensed to do.

You could find similar benefits for all components of Scrum. One way or the other, they all help putting the project in a situation where change is easy, quick and not costly to make.

Now, it's pretty easy to understand why most Agilists recommend the XP practice of tests automatization.
Indeed, it's the best way to decrease the cost of quality when change becomes the norm.
With automated tests, your full work can be instantaneously checked. Defects introduced by change can be spotted at next to no costs.

In the end, I'm not saying we should never adapt Agile practices or that we should follow them all, quite the contrary.

As we've seen, in a complex system, you want to increase your adaptability and that includes adaptability of your tools.

What is important, is that you adapt your tools for the good reasons. 

Today, people look towards Agile methodologies as a way to increase productivity. 

Remember that at the heart, Agility is not about being more efficient.

The winnings in productivity (or costs) are only byproducts.

It is because you diminish waste (by being better suited to the environment) that you are faster, not because you increased the pace of execution.

So if you are looking at adapting Agile methodologies for productivity reasons you are probably getting it wrong (chances are you'll diminish your adaptability to change).

But if the adaptation you want to make actually makes embracing change easier, faster or less costly, then, by all means, feel free to do so!

"Science sans conscience n'est que ruine de l'âme" Rabelais, Pantagruel
"Science without conscience is nothing but the ruin of the soul" Rabelais, Pantagruel

Credits: Anthony Gatto by Dirk Franke

Climbing over the ladder of innovation

Not that long ago, I was challenged with the task of designing something innovative.

As you often do in such situations you collect ideas you've seen on numerous projects and see if you could bring them together in a new way. You don't try to reinvent the wheel, but rather to present existing things with a new twist that makes them interesting.

I thought I had done a good job of it.

I was wrong.

What I presented was not judged to be innovative enough and I was criticized over the fact that the individual elements I had used had already been seen before.

But then I asked myself: what is innovation?

Is it still possible to think of something that would be ground-breaking? Something never seen before?

On the 4th of July 2012, the CERN announced it probably had discovered the Higgs Boson that was predicted in 1964.

Despite the Boson being called Higgs, after the british physicist Peter Higgs, you may be surprised to learn that Higgs wasn't its inventor.

Or rather, he wasn't alone.

The mechanism conducting to the existence of the Higgs Boson was in fact proposed by several physicists at about the same time.

Indeed, Wikipedia credits several physicists along Peter Higgs for the discovery (R. Brout, F. Englert, P. Higgs, G. S. Guralnik, C. R. Hagen and T. W. B. Kibble).

Incidentally, not only this theoretical discovery was a shared discovery but also the concrete discovery of the Higgs Boson itself is a team work.

To find evidence of the Boson, scientists used particle accelerators such as the Tevatron at the Fermilab and the LEP (later replaced by the LHC) at the CERN.

Such accelerators are huge pieces of engineering. 

In fact over 10,000 scientists and engineers from over 100 countries worked on building the LHC responsible for the CERN's discovery.

Discovery as it seems, isn't the matter of one person anymore but rather a collaborative work by brilliant minds all around the globe.

For the story, that doesn't prevent such events to be a fierce competition between scientists! Since the LEP had to be shut down before the LHC could be operational, people at the CERN were in fact quite worried that their colleagues at the Fermilab would make the discovery. The willingness to be the first was strong enough that, just before they shut it down, they went as far as pushing the LEP beyond its designed limits in the hope of catching the Higgs Boson.

You could think that collective discovery is a recent phenomena due to the development of communication and the easiness of sharing knowledge almost instantaneously.

You would be wrong.

In 1439, Joannes Gutenberg, contrary to what you learn in school (or at least to what I learned), did not invented printing.

What he did was improving over existing techniques (namely movable types, ink and screw presses) so that printing could become a mass market product.

Thomas Edison did not invented the electric light bulb. He perfected it, making it long-lasting and practical.

I'm sure you could find numerous other examples and you probably have your own.

My theory is that invention as such does not exist.

I consider it something made possible by a succession of steps above which you build so-called "new" things.

It is not that much about being innovative than it is about being creative.

It is not that much about having a stroke of genius than it is about looking at things differently.

I believe it's about assembling existing elements to build the unexpected.

Did you know that there are more than 915 million possible combinations for six 2x4 LEGO® bricks of the same color?

Credits: Fotolog Bureau Robin, http://goo.gl/Z8VS8

Gaming on the go, press pause

Mobiles expanded the video game market to a whole new audience.

People who didn't use to play suddenly started spending a huge amount of time playing on their mobile devices.

Angry Birds from Rovio Entertainment was downloaded by more than 1.7 billions people (yes, you read it correctly, billions...).

Quite impressive knowing that a game reaching 1 million sales can be considered a best-seller. All the more taking into account that there isn't more than a few such games a year.

But apart from changing consuming habits, mobiles introduced some important variations in the way we interact with games.

Good mobile games make those inherent to their design.

The main two are quite well known:

- shorter playing sessions ( a few minutes compared to half an hour and more on console games)

- more frequent sessions (as often as 10 times a day on games relying on energy such as city builders)

Apart from that, there is an important concept that I found to be too often overlooked by designers.

Mobile gaming is, guess what, mobile...

That is to say that people playing will be in situations where they can't give their full attention to the game.

They may be in a bus, paying attention not to miss their station.

They may be walking in the streets, having to watch for traffic.

They may encounter friends and pause to say hello.

All kind of situations where they are not watching their mobile screen.

There are lots of ways for a designer to take that into consideration, but what I prefer is what I call "the never ending pause"

It's really quite simple and can be done with one rule only:

Nothing should ever happen within the game without player interaction

This means that whatever action that has been planned into the game will only happen at a suitable time for the user.

It means I can look up and check the next bus station without fear of loosing.

I am not penalized for not giving my full attention to the game.

When you think about it, that's a big difference from hardcore gamers' titles.

That doesn't imply fast-paced action games cannot exist on mobiles and Real Racing 3 does a pretty good job.

But while, at times of writing, it is ranked 31 among top grossing apps in the French iPhone App Store. It is ranked 6 on iPad.

Meaning it is better ranked on the device used on the couch, in non-mobile situations.

Remember Angry Birds?

This is a nearly perfect example of a "never ending pause" (you could argue, that some Birds require interaction after you shot them. Given that's about 1 second of your attention though, you can safely consider it a "never ending pause").

Still not convinced? Check the iPhone App Store top grossing rankings and just count non-action games.

At times of writing all the games from the top 10 grossing iPhone French App Store are non-action games...

Credits: Original design by N. Lochet (based on Space Invaders start screen)

We don't need no Scrum Master

I see more and more comments from Agilists complaining that, more often than not, Scrum Master is yet another name for Project Manager.

Agility (and Scrum) promotes self-organized teams.

In such teams there is no hierarchy.

Team members organize themselves as they wish and efficient communication ensures it works.

Self-organization and communication are the true roots for emergence, something all Agilists should aim for.

Contrary to that, traditional projects are hierarchically organized around a Project Manager.

He is the leader of the project and team members report to him or her.

He is the only one to decide about the organization and the processes followed by the team.

The task is daunting. When you add control over the dreaded tryptic of quality, budget and schedule, you can guess what usually happen...

As widely quoted, 1994 Chaos Report from The Standish Group shows a shocking 16% rate of success among IT projects.

Their figures are much debatable, as proves J. Laurenz Eveleens and Chris Verhoef article, "The Rise and Fall of Chaos Report Figures", published in January/February 2010 issue of IEEE Software, but you get the idea.

If you have a minute or two I widely encourage you to read it.

If you ever wondered why statistics do not show much sign of an improvement over the past few years despite the wide adoption of Agile, there is your answer!

You may guess that with such heavy duties, project managers have long been a role of great importance in organizations.

When IT projects costs millions, it's no surprise (and I dare say quite natural) that you want to be sure to have the best control you can (now you understand why some fear self-organized Agile teams).

The quick rise of Agile put all those guys at risk. What is their value if teams no longer have a leader? What if people start self-organizing? Would they have to quit?

But as said, they are smart...

Soon enough, projects managers started becoming Scrum Masters.

Nothing had changed, only the title.

Brilliant, but when you think about it that could have been predicted.

Why is it that Scrum invented the role of Scrum Master but for providing a role for former project managers?

The Scrum Master is there to vouch for the good use of the methodology, has final say on backlog elements, and keep trackers up-to-date.

But when you think about it, why would you need that?

Isn't a Scrum team self-organized?

When I coach Agile projects, I encourage the teams to switch roles so that the Scrum Master is not always the same person.

It helps people both to embrace the methodology and to start self-organizing.

It's rare to truly reach a state where the team is self-organized, but for such teams:

We don't need no Scrum Master...

Credits: Original design by N. Lochet (based on The Wall CD cover and Scrum Alliance logo)