One day, every project will be agile

1
2747

The time is not far when the question of reinventing project management will be a key issue. The purpose will be to reconsider a project as something that have to fulfill a need and not an objective by itself as it’s so often. How can we see a project is its own purpose ? When, at the end, what is delivered totally matches with what what decided at the beginning and, at the same time, people realize it doesn’t fulfill the need because the need has evolved in the meanwhile, or that the client (internal or external) agreed to something that didn’t was not really what he expected, perhaps by lack of communication or bad understanding to what could actually be done.

By being next to developers all day long, I looked at the way they were working and it seems to me these guys discovered a kind of Holy Graal called agile method.

Of course I immediately tried to find if it could be use for other kind of projects than software development.

If I refer to the french version of wikipédia, these methods rely on four core values

• Team (people and interactions rather than processes and tools)

• Application (something that works rather than comprehensive documentation)

• Collaboration (collaboration with the client rather than negociating a contract)

• Change acceptance (react to change rather than following a plan)

Some points behind the agile manifesto may also help :

  • Customer satisfaction by rapid, continuous delivery of useful software
  • Working software is delivered frequently (weeks rather than months)
  • Working software is the principal measure of progress
  • Even late changes in requirements are welcomed
  • Close, daily cooperation between business people and developers
  • Face-to-face conversation is the best form of communication (Co-location)
  • Projects are built around motivated individuals, who should be trusted
  • Continuous attention to technical excellence and good design
  • Simplicity
  • Self-organizing teams
  • Regular adaptation to changing circumstances

It seems to me that very little work has to be done to rewrite this in order it could apply to a wider range of project. Most of all I believe that multplying iterations, permanent discussions, permanent client’s involvement (whether the client is internal or external), implementing things one by one and looking at what’s happening are very important in project management.

I recently tried to manage a small project like that because all the elements where gathered for that : a very scattered team with people who didn’t knew each other, overbooked people, hard to gather all of them for weekly reviews (even by phone). Although these people were used to “classical project management” and, at the beginning, they were not very comfortable with the fact the method was not as interventionist as what they used to do, the results were very interesting. A total success. It was easier to change things when it was obvious that what was initially planed didn’t fulfill perfectly the original need, when new ideas came to them, when one needed help. No week long tunnel between two reviews but a permanent conversation (using social media of course).

I think it’s worth digging deeper into this.

Frédéric de Villamil [fr] wrote an interesting note about knowing how a team is not ready for agile methods. It’s quite interesting because it strangely looks like the symptoms of companies that fail in succeeding in a context of uncertainty, discontinuity, disruption (what a pity…it’s the world we’re living in).

Your are inflexible : Apostle of the “we’ve always done like this” way of doing things, you can’t imagine to change anything in the way you work, whatever happens.

You hate uncertainty : better planning something impossible to do than let any margin, better deliver something that don’t fulfill the need than changing anything one the project has started. You don’t care if experience tells you it won’t work, the only fact you decided it will work makes you feel well. Even if you don’t master things you like to have the illusion you can.

You treat your people as ressources and you forget they are human ressources. Talent is a word that don’t mean anything to you, you only want people to be as exchangeable as machines, just like clones.

You consider projects as a linear process : imponderable don’t exist in you world. And things can’t be improved. Things happen the way you ant them to and if not it’s the other’s fault. You don’t learn from failures and will always operate the same way.

Do you know examples of agile methods applied to other things than software development ? I’ve made some researches, found things about project management 2.0 (of cours ! ) but no case study.

Does this inspire you any thought ?