Making Work Ready

Teams moving to Agile often abandon planning and documentation. Some coaches claim that any planning or estimating is waste. Some teams hear that we don’t do any planning or documentation in Agile. The concept of not developing “The Plan” upfront comes to mean we don’t plan in Agile and we don’t document in Agile.

Planning and documentation become waste in product development when we delay the start of a project by months so we can develop detailed requirements and task level estimates to come up with “The Plan”. At some point, we have developed “The Plan” as much as we responsibly can and the delay in getting stared is more expensive than improving the upfront precision of “The Plan”.

“The Plan” becomes wasteful when we then use it as the one right precise answer and we create overhead in managing detailed changes that don’t impact the promise to the customer.  When we don’t realize “The Plan” wasn’t precisely accurate to start with, we pull people that could be doing work into long meetings to defend where they are and to figure out how to get the project to green (to match “The Plan”). We also end up with starved and overloaded capacity all over the place when we make very precise “resource loading” decisions across multiple simultaneous projects based on “The Plan”.

So we have done a good job convincing people too much planning and documentation is bad. I frequently see this aversion to planning and documentation go too far – trading off the waste from delaying the project too long and putting too much detail too early on into The Plan for the waste of just winging it. What we want to do is progressively elaborate The Plan – making work ready for the teams to optimize product flow while minimizing the waste of over-planning. From Vision and Road-map, through Release Planning, Feature Planning and Story Writing, Sprint Planning, to the Daily Stand-up we have to do enough planning and documentation to make work ready before Planning.

There is work to do around the Vision and Road-map and understanding our customers and stakeholders before we get into Release Planning. Getting the team together to plan a release when you don’t understand the business problem, don’t have insight into the needs of your targeted stakeholders, haven’t come up with even a proposed architecture, and don’t have any strategy for how you will test what is being developed as it is produced seriously hampers Release Planning. There is planning and documentation for the Product Owner or Product Manager to do to get ready for Release Planning.

If you have a large project, you may be doing Story Writing Workshops to prepare the backlog ahead of the Delivery Teams. Before we get the whole team together to slice features and stories in a Story Writing workshop, we need to have thought through the feature a little. We probably need to draw a few pictures and have some data driven examples of business rules prepared before the Workshop.  There is work to do to make sure the Story Writing Workshop doesn’t become drawn out and inefficient.

There is work to do to get ready for Sprint Planning.  In some of our large projects that means writing acceptance tests for the stories ahead the Sprint.  It probably means answering any lingering questions from Release Planning or the Story Writing Workshop. It might mean sorting out some technical risk or documenting some precise validation rule to make work ready for the Sprint. When we don’t get ready for Sprint Planning, it is very difficult to become predictable in the Sprint.

So, we avoid the waste of documentation that is never consumed or that is stale when it is consumed. We avoid the costs associated with pushing a project back for weeks or months while we produce a falsely precise plan with too much detail. We minimize the cost associated with managing inevitable and foreseeable change. This waste comes from planning and documentation for its own sake.

But, we don’t abandon planning and documentation.  We still produce “The Plan”.  But we don’t do it for the sake of planning and documentation. We do it progressively – elaborating just what is needed at the time. We do enough planning and documentation to make work ready to an appropriate level of detail as our work unfolds. We do enough to help us make and keep promises to our customers. We do enough planning and documenting at the right time to ensure entire product team (product management, development, testers, and analysts) shares an understanding of what we are about to build, what we are building and what we just built. Effective planning and documentation are part of making work ready to help improve our team’s potential for success.