Agile Software development, lean manufacturing, and similar buzzwords have roused and disturbed the project management community. Is it only the latest management fad, something that will be quickly forgotten, absorbed as yet-another possible process, or is it something that heralds a big change of the way we (traditionally) conduct projects? There are lots of myths and half-truth abundant, which seem to point in the former direction, and many projects claiming to follow agile principles don’t seem to harvest the juicy fruits that agile is promising.
If you are contemplating whether to implement agile – maybe via Scrum or XP, you might easily get the impression that you have to throw away all you disciplined processes in favor of a somehow chaotic approach, where documentation is neglected, your project team members decide what they would like to work on, and there is no way of telling what you can finally deliver to your customer.
In reality, this is as far from the truth as it could be: In contrast agile – when done well – emphasizes the commitments given to the customer in a much stricter way than usual, process-driven methodologies do. Observed from the outside, agile seems to consist of only a sketchy process and some lofty principles. And if you stay at that position, you are quite likely to fail in your attempt to implement agile in your organization. One of the bigger threats is certainly the attempt to customize the agile approach so that it fits to your environment. This is not to say that it is not indispensable to customize. Not doing so will make it equally likely that you flounder with your attempt. Instead it is necessary to understand the underlying philosophy and mindset that is shared by all agile methodologies, and make the customization in a way that does not run contrary to the principles stated in the Agile Manifesto and the Declaration of Interdependence.
Actually, agile is more than a collection of tools and processes / procedures that can you can choose from as you like. All building blocks described by a certain methodology (e.g. XP) are tightly coupled. If you dismiss one, the whole methodology might crumble. But the biggest impact is not on the technical side – it is on the way who people interact with each other and how the collaborate.
As a matter of fact, agile project management is not only a technical skill to select (and control) a certain process and coercing the project team to follow it. Instead, agile project management might well be called ‘agile leadership’ as it is more about leading people and team than assigning task and tracking their completion. The agile project manager has to steer the project by presenting a project vision, emphasizing (and demanding) personal and team accountability and removing impediments to the project success. In that, it signifies a completely different mindset to a project manager: Abandoning a command-and-control attitude and becoming a coach, mentor and a guiding light to his teams – and possibly the rest of the organization. The agile project manager has to become a change agent in the company, serving as a role model for his project teams, and aid them to make those necessary behavioral changes that are required in a complex, quickly changing project environment that agile methods advocate. Renouncing the command-and-control attitude is probably quite hard for many seasoned project managers – but continuing with this attitude might well be the biggest obstacle for implementing an agile company. This might soon become a question of survival in the face of ever-growing competition and reduced time-to-market.