The best agile software development teams use just-in-time planning. It’s a simple concept, really, but not-so-simple to put into practice. It has roots in product manufacturing and is embraced by companies following a kanban approach to building products.
You’ve probably heard of just-in-time inventory management. It’s a set of techniques for minimizing both raw materials and finished goods. Raw materials needed for building finished products are kept to a minimum so that excessive amounts of storage space and working capital aren’t tied up for extended periods of time.
Similarly, the inventory of finished goods is kept minimal. The idea is to produce goods just as the customer needs them and not have them sitting around in the warehouse waiting for orders to arrive. Makes sense, right? Easy to do, right? (Trick question. No, it’s not.)
In the world of software development, there’s a similar concept called just-in-time planning. Companies prepare detailed plans at the time they’re needed, not weeks or months in advance. This approach is mandated in highly-dynamic situations or anytime you want to make just-in-time decisions. Businesses that are morphing rapidly can’t afford to plan, re-plan, revise the re-plan, rework the revised plan, rethink…you get the idea.
Detailed planning takes time — lots of time. Why derive detailed plans far in advance of implementing them when you know they’re going to change before you ever get a chance to deliver the goods? You’d knowingly be creating waste. Why would you do that?
The better approach is to define a strategic plan (a.k.a. high-level plan, vision statement, strategic direction, product roadmap, etc.). Strategic plans are less likely to change in the near term. They help guide software development teams in making key decisions along the way to delivering final products.
The strategic plan is usually drafted before the project starts though some consider it a component of sprint zero. In conjunction with the plan, it’s a good idea to define a set of themes and epics — high-level functional characteristics and user stories. These themes and epics don’t have to cover all the major features of the software system but should cover enough to give everyone a good sense of what’s being built.
With these elements in place, the team can begin grouping and splitting epics into user stories. Epics and stories are commonly grouped into releases which are further broken down into sprints. The team will work out the implementation details during each sprint as part of the sprint planning process.
Easy to Say, Hard to Do
Simple, right? Sadly, no. Just-in-time planning demands cooperation and collaboration among all the business and technology groups who have a vested interest in the project. It takes trust and confidence to embark on a major software project without getting up-front commitments around precisely what will be done and when. (Of course, all the planning in the world won’t help when the “world” changes part way through the project.)
Just-in-time planning is a way of making decisions at the time the decisions need to be made. That’s when the newest and best information is available. Better information leads to better decisions resulting in better software.