Abstractly Concrete II

September 11, 2014

“Are you sure you know Agile, we just don’t ever plan.”  I often get this comment when I raise the “P” word with Agile practitioners.  Whenever I start talking about planning, people steeped in Agile try to shut me down as someone who just does not understand that in the new world, you just do not need to plan.  This is an unfortunate misunderstanding of reality.  Planning is just part of life and all businesses need to do some planning.  It is whether we plan but what we do with the plan that has changed.


The arrival of Agile has done a great deal to change the manner in which we plan. We used to place too much confidence the plans we created, and that was a problem.  Today we understand that we need to do much less planning and much more building. But the notion that you just build and deliver whatever you finish whenever you finish it, is neither good business nor good engineering.


Let me argue by analogy. In a military battle, a team might be sent to capture a hill.  The team can be completely tactical in their task and with good execution and some luck, they can achieve success in their mission.  But should the hill be taken in the first place?  Does the team need the support of more teams because the task at hand is too much for a single team?  Who decided that this hill is worth taking and in what context and at what cost?  Hopefully, someone thought about all of this before they sent the team off to do their job.  Hopefully, someone did some planning.


Understanding what the future may hold allows us to shape it now so that it is more successful later.  A business needs to project expenses and revenue (even if it is using Beyond Budgeting techniques).  Some of the reasons a business needs to plan are:

  1. Customers like to hear about what is coming next. 

  2. A team needs to be hired to do the work, and it needs to be sized. 

  3. Office space and tools need to be acquired. 

  4. Projects need to be evaluated relative to each other and approved based on projections of cost and return. 

  5. People need to think things through so that obvious errors can be avoided.

  6. Good plans reduce risk and provide guidance.

It is this last category that we are addressing in this paper.  We want to provide guidelines for how to think about a complete project in the planning process and before building commences.  In this note we are less interested in the time frame and total work involved than we are in pointing to a methodology for reducing risk and increasing understanding of the problem at hand.


What we are advocating is that we do some thinking about the items that matter most. Planning is the process of imagining what will happen and understanding the implications. The imagining process allows us to look at what we are doing and make decisions, before we invest a lot of time and effort in the details or in actually building it.  We can iterate at this level, before we iterate in the building process itself.  The imagining process is often call a Thought Experiment.


The Thought Experiment is a kind of planning often used for a broader strategic view of what is desired and causes the people involved to think about the endeavor that is about to be undertaken in its totality. The process involves itemizing every part of the solution and thinking through what it does, its interactions with the rest of the system, its interactions with the world, it complexities, its risks and its benefits.


Thinking these things through can speed up the eventual development of the Minimum Viable Product.  It is a narrative, of the solution being contemplated at a high enough level to be useful to a broad audience, yet containing enough reality to provide both guidance to those actually building it and a first “thought experiment” to those doing the planning.  This balance may seem confusing, but it is achievable with a little practice. I call the level of detail that provides direction without being too detailed: Concretely Abstract.


The audience for the plan consists of the people doing the planning.  When you plan, you are imagining the future and looking at it from a variety of perspectives.  The very process of thinking things through gives you experience that helps reduce errors in the coming building phase.  It reduces risk.  Much like athletes use “visualization” to walk through various moves they expect to make in an athletic endeavor, engineers who plan visualize their project so that they can get ready to make fewer mistakes when in the actual battle of creating the product.  It is much like grooming, but at a broader and higher level.


The trick in all this is to hit the right level of detail.  You need to strike a chord between overdoing and under doing the level of detail in the plan. You need to strike a tricky balance that forces you to think through the project by enough, but not too much detail. That is you need to recognize where the line exists between providing enough guidance to solve some big problems while leaving all the details for later.


At the high level, you want to solve the big problems to take the risk out of the project.  The high level issues define the broad picture of what is being proposed. They provide the description and color that creates the visualization of the coming project.  Some of the key areas that are focused on in the plans are:

  1. Strategic direction and implications

  2. Policy

  3. Integration with other products

  4. Pricing

  5. Cost

  6. Key success criteria

  7. Basic fit of solution to the problem being addressed

  8. Eliminating the items that have high risk

  9. User Type and Experience

  10. Problem Domain

The plan is the act of assembling these concepts into a coherent picture of what is to be built.  The planners create a complete high-level description of the solution being planned.  They define the solution, resolve conflicts, make decisions, and evaluate the usefulness of the solution for the intended purpose.


One of the goals of this effort is to provide clear guidance for the project team, allowing them to untangle the enormous details that they will encounter when they set off to build the solution.  The planners are not trying to solve the whole problem.  They are providing direction and guidance.   They are validating the basics and estimating the cost necessary to succeed in the undertaking.    The plan will still have technical risk in it, but hopefully the market and product risks are taken out.


The planning phases of a Waterfall process assumed all the detail could be planned ahead of time. In that model every item was thought through, planned, scheduled, and described.  That goal was to leave nothing but the actual coding for the work that comes after the planning process.  Here we are avoiding all of that detail and just focusing on the systems operations, behavior, interaction, size and risk.


Avoiding the details helps assure that the plan will be useful.  It also raises the odds of people reading it and understanding it.  It improves the probability of the plan being correct.  The following are examples that represent too much detail for a good (Concretely Abstract) plan:

  1. User interfaces

  2. Algorithms

  3. Designs

  4. Data Structures

  5. Exact tools to be used

  6. Architecture

  7. Pert/Gantt Charts

  8. Object definition

  9. Configurations

Again, the key to this planning is to find the right level of detail to think through in the planning process. The plan needs to be concrete in many places, because it is laying down guidelines.  At the same time, it needs to be abstract enough to avoid the details that will bog down the planning effort and will easily change as the plan evolves and the building phase is started.  It is a fine line that needs to be understood so that it is neither to detailed or too squishy.  It needs to provide broad direction, although sometimes more detailed.


I find it takes a while for people to reach an understanding the right level of detail. At one end of the spectrum people get so incredibly detailed that planning effort bogs down to the point uselessness.  At the other end people get so abstract that they might as well not do any planning, as the plan does not provide guidance or direction.  Each time you make a point you need to ask yourself:

  1. Does this statement provide those building the product with the ability to make clear decisions about what fits and what does not fit?

  2. Is this statement so proscriptive that it provides no ability to make choices?

  3. Is this statement clear and easy to comprehend?

The following are examples of Abstractly Concrete statements about a plan:

  1. The plan should provide no UI details.

  2. Performance guidelines of any plan should be a range of values for success and failure.

  3. The user description for any user described should lay out the context and needs of the user and not the dwell on the exact needs of the user.

  4. Manpower loading diagrams are too much detail for any plan.

A Concretely Abstract plan is compete at a high level. It does not need to skip major areas or anything that is important.  We used to think capturing every last detail was important, it is not. A Plan should be more descriptive than prescriptive but shares an element of each.  It is a narrative that provides the visualization of the coming solution.


A plan that is Concretely Abstract can be put together in a couple of days by a team of people.  It can be easily understood and reviewed by who understand the market area.  Engineers can read it and have a feel for what their constraints are. Product Owners can create Epochs and User Stories from it. One can test to see if the solution provided is complete enough to succeed. The key risks in the plan can be assessed and eliminated by making sure it is complete.


© 2011-18 Westerly Consulting LLC, all rights reserved

Share on Facebook
Share on Twitter
Please reload

Featured Posts

I'm busy working on my blog posts. Watch this space!

Please reload

Recent Posts

November 23, 2015

September 11, 2014

Please reload

Please reload

Search By Tags
Follow Us
  • Facebook Basic Square
  • Twitter Basic Square
  • Google+ Basic Square

© 2017-18 by Westerly Consulting, LLC

Westerly Consulting, LLC

All photographs by Fred Engel