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 [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?
A project professional for over 30 years, Adrian Pyne has led change in 11 industries and in the public sector, in the UK and abroad. The co-author of books on programme management and agile governance and assurance, he has contributed to the evolution of programme, portfolio and PMO standards and is a regular speaker, visiting lecturer, blogger and researcher. His book Agile Beyond IT is published by Practical Inspiration Publishing.
7 comments
Log in to post a comment, or create an account if you don't have one already.
Spot on David,I had a conversation just yesterday with a company who were thinking of going Agile on a large project. Their first Agile project and a long one.My advice was....DON'T! Big risk.Although there would be plenty of opportunities to apply agile and lean ideas. For example as you suggest. And this is what I am trying to encourage by my Blog. You do not have to have a full on Agile development to apply agile thinking to projects....and gain value from so doing.
AdrianI think the main difficulty people have is the change of approach, and some project managers may find it difficult to "let go" as the agile team becomes more self sufficient and takes more ownership of the project. Incremental delivery also means that the team needs to be able to react to what can be a changing set of requirements depending on the result of the previous sprint. There are many opportunities in lean also, one example being the use of kanban to control work flow through the teams tasks. The application of some agile thinking to more structured waterfall projects can have surprising results
A really interesting article about agile development, I am coming across the use of agile more and more in the organisations I work with. I think your contribution is very useful in helping the APM to consider the impact of agile approaches on a more traditional project management. I am not an agile expert but having discussed it with some who are I think there are bridges between the stages introduced in APM BoK 6 and the agile approaches to the delivery of those stages. We have written a blog post of combining agile and traditions approaches which may be useful. I am looking to see how this debate unfolds over the next few years.
Brian, Thanks for your comments. I completely agree that APM could play a role here. It is just a shame that t has missed an opportunity to do so.As I understand it, Agile is now to be brought under the Planning, Monitoring and Controls SIG. Now I am a pretty glass half full kind of guy. But the risk is I feel that this is not a natural home for the critical behavioural aspects of agile. Process will dominate once again.Please prove me wrong folks!
David,I am glad you picked up the difference of the agile mindset. This was a key theme in the blog. But I was abosolutely not writing about agile development. What prompted the blog was the confusion caused when people write about agile development (process) and project management being the same thing. They are not.I am however, keen to promote the use of agile and lean (note non-caps) thinking and behaviours in managing projects, programmes and portfolios. I don't much care whether those projects are agile software development or building an oil refinery.
Agile is a process that focusses on delivering value in incremental steps, rather than delivering the end product(or deliverable) at the end of the project. It requires a change of mindset as it tends to put more focus and responsibility on the team rather than the project manager, in fact the project manager should become more of a servant leader. The key is to have the representative of the customer on the team, and available at all times to make decisions on the product backlog, which forms the basis of the sprint backlog. It also has less focus on documentation, in fact the best agile tool is probably a whiteboard. Leankit software is also useful.I could carry on but I'll finish by saying that some institutions have some useful methodologies that bear study and offer certification (which I have), and it is a change of mindset from waterfall.
Adrian,Your 4 issues about 'agile' approaches are very thought provoking. Using agile as an excuse to leave stuff out: True. And if quality is what is being left out, that is a cardinal sin!Saying we will be agile and then not changing the culture: Over the last decade we have been concentrating on agile programming - we need to move to agile portfolios of change and recognise the need for 'hybird' programmes - part agile, part waterfall, because that is reality for most businesses.Confusing agile software development and project management. They are NOT the same This is where the APM can play a role. Raising the sights of Scrummasters from the detail of product development up to a more strategic level focused on business change. Continuous claims to have found the crock of gold. Claims for new agile pm methods that do not stand up... a plug for my book: evidence based, not preaching!Brian