Take a learning journey to agile project management

by Carl Weller on 24/04/2015 11:50

Take a learning journey to agile project management

Most of my career as a “planful” project manager - by that I mean a devotee of PMI and PRINCE2 (yep, I’ve said it and I’m not ashamed of it) – I’ve heard metaphors like “herding cats” or “getting your ducks in a row” being used to describe the business of delivering value to clients. I’ve even used them on occasion.

Looking back, perhaps with a little more understanding, statements like those above are full of subtle meaning; an assumption that the “cats” needed “herding”, and a belief that the problem we were solving was simple enough that all I needed to do was “line up some ducks” (by which I mean create a work breakdown structure and implement a plan).

I like causality, the feeling that I can analyse a situation and come up with a plan. It makes the world feel safer and more ordered. Like many others, I’ve seen the “Agile gap” (aligning adaptive Agile development practices with quite prescriptive Newtonian organisational frameworks) and quite happily sat on my own side of the canyon (for years in fact), expecting agilists to close the gap from their side. In some ways I guess I found early Agile development very challenging to my world view.

Moving on a few years, with a few more scars on my back, I’ve been lucky to be exposed to some deep thinkers, many of them at Equinox IT. I am now gingerly straddling the fence between predictive, planful project management and Agile project management, using adaptive practices. Some I am very comfortable with, others I just need to plug into my frame of reference.

The most significant shift in mindset for me has been acknowledging that the work of software development is complicated, but the added dimension of people and politics found on projects - and in organisations - can make software development very complex. For those of you with a knowledge of the Cynefin framework, or Eddie Obeng’s 4 project types, the meaning is clear; some of our tools are more suited to industrial management in the style of F.W. Taylor than they are for 21st Century knowledge work.

For some work, where the objectives are clear, and the methods well-understood, perhaps it is just a case of lining up a few ducks (or “painting by numbers” according to Obeng). In these cases I’d feel comfortable sticking to a traditional planful project management. Borrowing from Ray Cooke’s metaphor in his post Optimise your software development approach around producing happy customers this is about ensuring all the cogs are correctly aligned and working at peak efficiency.

But most of our work isn’t like that anymore. The pace of change is such that value needs to be delivered faster, with better predictability, and the best methods I have seen to do that are those that embrace change as a constant rather than something to be controlled. The people I am “leading” are generally smarter and better informed than I am, and they can generally work out better approaches to deliver value than I can, but they don’t have all the answers either – at least not well in advance as is required in a waterfall approach.

Keeping the cogs aligned to a very detailed plan over time, as the environment changes, requirements change, people move on and off the project, or try and split themselves across multiple projects, becomes harder and harder. You can spend too much time discussing if something is a change or a defect, or updating a Gantt chart, when you could be helping focus on continuous improvement and removing obstacles in the team’s way. An Agile project management approach is much better suited to these situations.

So am I now some sort of convert, suitably equipped with missionary zeal? No, I’m just someone on a learning journey who has found some more tools that work in some situations, and could be adapted for others. But I’m not sitting smugly on my side of the canyon anymore either. I now see a product backlog as just another form of work breakdown structure, and release and sprint planning as a mixture of a continuously evolving schedule and a change control process. If you get past the shape of the tools and think about their purpose, the fit becomes clear. I no longer make misinformed statements like “there’s no such thing as Agile HR management”. In one sense there isn’t, but the practices I’ve seen for building and enabling self-managing teams, using an Agile project management approach, are amazing and would fit just as well in a policy shop (Jurgen Appelo is a must read for managers of all teams, not just software teams).

And if I put my PMI hat back on, there have been concepts like “progressive elaboration” and “rolling wave planning” since the early to mid 2000s (PMBOK 2 and 3 respectively). These are all about iterative planning and planning in detail in the near-term and less granular further out. Unfortunately they are often overlooked and under-used.

The concept of the project plan as a “contract” has been taken too far. It diminishes the complexity of the work we do and sets up adversarial rather than collaborative relationships when the project plan gets “challenged” by reality. What Agile - be it Scrum or Kanban – does is make the process and the conversation easier. Starting an Agile development project means you acknowledge that you don’t know exactly what the future holds, but you agree to work through it together to find that best mix of time, cost and scope that delivers value (By the way, never start an agile project if you don’t have this acknowledgment from the business!).

Carl Weller is a Principal Consultant specialising in Project Management and Agile Leadership, based in our Wellington office.

Recorded webinar: Learning the hard parts of agile software development


Get blog posts by email

New call-to-action
New call-to-action