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

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 [4] 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?

About the Author
Adrian is a consultant who’s practice for more than 20 years was the delivery or rescue of Change programmes and the design, build, operation of portfolio, programme and project management capability. Starting in telecoms he has worked in commercial and public sectors: e.g. investment/retail finance, central & local government, diversity, nano & energy technologies and mining. Adrian is a visiting lecturer at Nottingham & Kingston University Business Schools.
He has always specialised in and championed the people aspects of our profession, notably stakeholder management and behaviour. In recent years much of his practice has focussed on developing cultures and organisations in which programmes and projects can thrive and not merely survive.
Adrian has been a long time contributor to the APM, especially within ProgM, e.g. the BoK 6 refresh. He is a frequent speaker, in the UK and internationally, and is co-author of the Gower Handbook of Programme Management. Adrian is RPP certified and an RPP Assessor.

Comments on this site are moderated. Please allow up to 24 hours for your comment to be published on this site. Thank you for adding your comment.