Agile thinking for projects, thinking out of the process box
The world of Agile and Lean thinking, as applied to our profession, has not had much attention from APM, its SIGs etc. I think we should, especially as there are many misconceptions about agile
A consultant from a business school was asked to advise a media company about being agile. He asked them to describe their approach and they looked confused, hurt almost. Then they said, with much snapping of fingers and great enthusiasm. but we are agile, snappy, not constrained, we just get on with it. He had his work cut out.
While this blog is not about agile software development, there is much confusion between this and so called agile project management. So a quick outline.
The Agile Manifesto was an early incarnation of agile software development. From the outset it was not just a process but also a different way of working, than say, serial development methods like waterfall. For example, with a waterfall approach, users tend to get involved part-time. An agile development is done in a serial set of sprints. Each sprint takes a sub-set of the high level requirements and comprises detailed requirements, design, coding and some testing.
Sounds like just a different process so far. But for this agile process to work it also requires agile behaviour. In that the users have to be involved throughout the development life-cycle, embrace change, be continuously flexible and so on. In short, the agile paradigm is as different culturally as it is in process terms, from other development methods. If you look at the principles of the Agile Manifesto, behavioural aspects trump process.
No surprise then that the agile paradigm for project management should be different too. Now, flexibility, communication, team work etc, are in the project management toolbox already.
The trick with agile is how they are used, and integrated with process, and use of management tools. And for me, the focus needs to be on people aspects, instead of them being the poor, if not forgotten relation.
And this is why this area of project management excites me. There is lots of thinking to be done, not least because there is much confusion. For example, three issues I have commonly come across are:
- Using agile as an excuse to leave stuff out, which may be useful, if not critical, e.g. media company example
- Saying we will be agile and then not changing the culture
- Confusing agile software development and project management. They are NOT the same
- Continuous claims to have found the crock of gold. Claims for new agile pm methods that do not stand up
Issue  concerns me most. I greatly applaud those who have thought about agile PM. But many claim to have developed a true agile pm method. My opinion is that none I have seen so far actually show clear blue water between their method/approach and existing best practice. The problem is that the more people shout their claims, the less such claims will be listened to. Even when it finally becomes true.
And it will and I will welcome it. But what I have seen so far are adaptations, some very good.
A superb example is Keith Richards excellent 2007 paper; Integrating DSDM into an existing PRINCE2 environment. It is remarkable in that it adapts Prince/2, which many people (who do not really understand it I suspect) consider a highly beaurocratic method. If this were true it would be next to impossible to adapt it for agile. And yet, Q.E.D.
So how about some agile thoughts, and lets think out of the process box, for a change, for a challenge?