"Responding to change over following a plan does not mean going into chaos. The following a plan refers to follow a line without looking at changes in time. That is flawed thinking, the plan may perfectly be to respond to change in an organized way, validating each time to improve the next one. The plan is simple: we decide as we go, following these principles."Quote from the Article by William Martinez Pomares
I don't really know agile programming but as obvious as this may seem, I think it should be a stated prerequisite nonetheless for any organizational
system to have a "table of contents" overview in order to separate and not allow any productivity method to be mis-categorized as a system. (Sort of how a "deep" novel or movie will eventually resort to a storyboard or software editor even if the core process remains simple and traditional to natural organization.)
SourceThe Vision Box
A Vision Box presents the features and benefits of the project as a box of cereal – the front has a name and branding, along with a list of the key benefits the product will convey to its buyers (the customers who will eventually use the product, be they internal to the organisation or real paying customers). The back of the box contains operating instructions (high level design decisions) and a list of the key features the product will have.
Building a vision box is a creative activity that helps the team articulate what they are thinking about. It can be useful to break into smaller groups and have the groups each build a vision box that they then “sell” to the remainder of the team. After the separate presentations a shared vision box should be produced that conveys the ideas of the whole team.
Some examples of this for productivity are:
- Corkboards
- Kanban Boards
- Index Card Systems
- Software Sticky Notes
However, I firmly believe that Vision Boxes shouldn't be part of a productivity system in the same way you don't turn the table of contents of a book into a cliff notes version of the book.
The risk of doing so might turn the box into nothing more than an enlarged notebook with columns or worse, a calendar/goal system that works if you know what you are doing but falls apart once something (like a task) starts falling apart and getting in the way.
Another (rarer) interesting take in the article is the visual utilization of sliders:
The sliders range from Fully On to Fully Off – if an element is On then it will be the strongest factor that drives the decision making as the project continues. No two sliders can be set at the same level, and the more sliders there are on the “On” side of the grid the higher the risk of catastrophic failure this project accepts. Where there is little leeway in the project sliders then the choice becomes deliver everything or deliver nothing, whereas more leeway allows for partial delivery that contributes to the organisations goals.
Online Tool linked in the articleI don't think the idea works as well as it should but it's another clue towards the different ways a vision box can help in getting organized.
Finally, the most difficult thing about explaining a vision box in my opinion is that it's not a:
- Corkboards
- Kanban Boards
- Index Card Systems
- Software Sticky Notes
It sounds contradictory but it's like a chart. You get something from a chart but it has to have data in it in order to properly visualize itself.
My interpretation of a vision box is the same except it should already be a workable chart even before the data is calculated or the needs are met.
The article alludes to this by explaining how a product roadmap works:
The product roadmap is a time-based view of the anticipated delivery lifecycle of the product. It is a high-level plan maintained by the product owner and project manager that is expected to change over time.
The product roadmap is regularly validated against the product vision and is used to convey to the team and the outside world the likely release schedule for components of the product.
The product roadmap is at the level of features and epics – user stories are not included.
A product roadmap should be expressed as a big visible chart that shows important milestones, features and target release dates. As changes are made items are added, moved and removed from the roadmap.
The problem with a roadmap though is that, it again asks for a static workable private space, where everything is posted and that space can't be interrupted. Contrast this with a software launcher like RocketDock or CircleDock where if you reformatted your desktop, the program is not dead in the water once re-installed. Sure you have to re-add the icons but the structure itself promotes the addition and you don't have to re-memorize each and every position of a normal icon within the dock.
If all these seems different from how the article explains it, again I just want to emphasize that I am trying to explain the implementation of the Vision Box from my perspective of how it can become part of a productivity system rather than how it is used in agile programming.
