A tweet from a friend who works as a project manager got me thinking about whether agile planning techniques are applicable in other contexts. We used to have project managers in software development who assumed that creating software was a predictable process, a misconception that stems from instinct rather than anything scientific, and I imagine this misconception exists in other areas. It took the frustration of programmers to apply more scientific methods to their process to change things and they gave us Agile Software Development that the lucky ones of use today. It turns out that developing software is too complex and too creative to be predictable. Although we have a rough idea what needs to be done (a goal or purpose) the best way to go about doing it only reveals itself as we start building. For this reason our planning is very fluid, the plan is constantly changing making any long-term planning in the traditional sense meaningless. We guarantee meeting an end date by making sure we are always in a state close to release. We manage this by limiting work-in-progress and focusing on ensuring the features and stories we add are truly done before we move on to the next ones. When we need to release it’s already tested and approved by the customer.
Who should plan?
People are motivated when they have self-direction. So by giving people self direction we see huge gains in effectiveness and creativity. Since working to other people’s plans kills our motivation we tend to avoid any project manager roles. In fact any role with the word “manager” in has bad connotations in the Agile world. Unfortunately its easier to change yourself than change your organisation so command and control management remains prevalent in most organisations despite killing effectiveness and leaving employees to soldier on waiting for a pay check.
Agile planning is done by the team who carry out the work because they are the only ones who understand what really needs to happen and have the best idea of the impediments that stand in their way. The team can collaborate to work out the best ways to work together and not tread on each others toes. A single project manager with a Gantt chart might not get such cooperation from his team.
Traditionally planning is left as the responsibility of a project manager. Project managers are measured on their ability to deliver on time and on budget after which they will move on to another project. This might be good for the project but delivering projects shouldn’t be the purpose of an organisation, it should be to create value. Agile teams shun individual targets in favour of looking at their effect on the wider system. We understand, with more than a passing interest in Systems Thinking, that individual targets increase competitiveness and reduce collaboration with the overall effect of killing effectiveness (yes we don’t think much of bi-annual appraisals either).
In Scrum we used to use the term “commit” when agreeing to what we would take on at the end of a sprint planning session. But even the work commit can be damaging. By committing to anything you close your mind to alternatives that will appear on the way. No we just say this is a plan and if it changes all the better or just regularly top up a backlog of things to do.
When should we plan?
Planning the future of an unpredictable project is pure waste, at best it will get thrown away at worse it may stop you delivering anything meaningful. As long as everyone understands the purpose of what you are trying to achieve it’s better to plan little and often (daily is a good starting point). I was going to say there are times when the simplicity and predictability of the thing you are doing mean you can plan at the beginning but I suspect you are just shooting yourself in the foot. Does anybody actually do it? Does it serve any purpose?
In Agile we may have some idea what we will do for the next sprint or iteration but the most important thing is the goal not any predictions of how we might achieve it. A daily standup allows us to at least give an intention of what we might do for the day and provides an opportunity to account for what we did yesterday. When the whole team can see what the others are doing there is no need for someone to coordinate; we self organise. What if the people working on the project aren’t part of the same team? Simply put, you need to restructure your organisation into cross-functional self organising autonomous teams. I know this might not be achievable over night but the price you are paying for single function departments is too great to ignore.
How do you plan?
The greatest gains in our effectiveness can be seen from doing the right things, and our job is to discover what these things are. But is that planning or is that just part of the whole process?
So presuming we (the team) know roughly what we want to do, we give that thing a name (perhaps in the form of a user story), stick it up on a board where the whole team can see, and as we become free we pick the tasks that are most in need of being “done” now and do them. Note that we “pull” the tasks we feel best positioned to do rather than have a project manager tell us. If you do this in a collaborative environment with all the people involved that’s all you need to do. While you are all together collaborating why not spend some of the time you are saving not being ineffectively productive by being a bit more creative? Have some fun, throw ideas around, you’ll be amazed at what you can do. All you need is a purpose.
I imagine this is going to appear as bit of an anarchic rant to the average corporate project manager but perhaps there are some who can see the light. If it makes sense then take small steps. It will take generations to undo the damage that has been done by the management techniques of the industrial revolution. But if you just create one team who work like this you will have played a huge part.