I’ve been working on “agile” teams for about 4 years now, so I kind of take for granted the whole short-term planning strategy that agile development centers around. But articles like this, How Plans Kill Productivity, remind me that not everyone has the luxury of working in this kind of environment. I’d like to iterate the reasons why I think short-term planning on projects beat out traditional application lifecycle management every time.
In most agile flavours of software development, there’s a focus on short term planning. From the granularity of test-driven development handling one portion of code at a time, to from the daily scrum meeting where you announce your plan for the day, or the week-or-more long iteration plan, and even the team retrospective. All of these are planning cycles that usually don’t extend more than a few weeks, at most a month. Contrast this to traditional methods of waterfall or spiral patterns where months or years of a project are all planned up front.
Time to React
The obvious reason this is better is because of the feedback loop. If you’re able to re-evaluate your position on a daily or weekly basis, you can respond to change and unexpected events easier. Not only that, but you open your team and project up to feedback – if you’re heads down for 3 months at a time and don’t report any sort of progress, no one’s going to bother you with that requirement change until it’s too late.
There are other benefits to this approach as well. What I’ve found in processes like this is the control of the execution goes back to the team. No longer do you have “architects” and “project managers” deciding what you’ll be doing for the next six months of your employment, the actual implementation and execution of the project is in the hands of the team. You and your team meet regularly to report progress, discuss roadblocks, and ultimately decide how you are going to complete the project, small steps at a time.
Trusting your team to be able to manage the day-to-day of a project’s implementation allows each employee to work to their full potential – no longer are they just reading from a 200+ page design document and following instructions, they’re critically thinking about the problem they’re solving and possible solutions. This also frees up management to think about other things, and leave the software development to the software developers.
As the original article says, those long-term project planning meetings are essentially trying to play fortune teller for days at a time. And they usually don’t involve the people who make the actual project! They are doomed to fail from the beginning, and I think are a large part of the reason why we have so many failed software projects in our industry. Leaving the actual project implementation to the people who know how to implement software is a much better approach.
Goals Over Instructions
Where does long-term planning fit in then? People looking at the bottom line of the company and our future need to know that we’re going somewhere, and when we’re going to be there. I think from a long-term planning perspective, instead of planning an entire project from scratch, we need to change to setting milestones and goals. Managers, let your team know where you want to be in 3 months, and let us worry about how to get there. If it’s an unreasonable timeline, we’ll let the management know. And if anything comes up along the way, there’s a retrospective meeting every few weeks – the management is welcome to attend and get a status update.
Its not that there is no place for planning in a software project – without a plan it would be chaos. I think companies just need to realize the futility of trying to plan a 6 month software project in advance – there’s no way anyone can predict everything that will happen to a project in that kind of timespan. As a side effect, you’re locking your team in to a 6 month cycle that is resistant to change, and you’re also demotivating your employees from contributing to their fullest.