I have been playing with a simple way to visualise progress and efficiency when we are creating solutions. I think could be useful, tell me what you think.

When I came up with this method, I was a little frustrated. My team was doing a lot of work but making only modest progress. We hadn’t spent enough time on prototyping so our stack was slowing us down. We were using discovery to figure out how features would look but this meant a lot of re-work.

I was frustrated because I felt like we could go faster, that we could communicate better, that we could waste less but I didn’t have any way to communicate this feeling to our team and our stakeholders.

Out of this frustration, I invented a way of visualising what was happening with our progress, a way of showing all of the twists and turns we were making in pursuit of a useful solution. For the moment, I am calling this thing Solution Space.

I imagined solution space as a circle (it’s radial) and gave it 3 aspects.

• At the centre of the is a point. This represents no solution, no useful features, no implementation..
• As you travel outwards from this central point, this represents more solution, more useful features, more complexity, a more comprehensive implementation.
• As you travel around the central point radially , this represents different solutions. Different features, a different implementation

Using this method, it is possible to plot out your progress for a particular feature or story or project.

If you are making good progress, your efforts are rewarded with more features, more useful implementation. If you are changing features often, refactoring implementation late, pulling out features, this is waste, there is something wrong with your process.

Understanding Cost of Travel

Every movement through solution space costs time and money.

• Traveling outwards i.e. building features.
• Traveling inwards i.e dismantling or decommissioning features.
• Traveling around i.e. changing features or implementation.

These are all quite obvious but some interesting things pop out when you apply them.

Understanding Efficiency

Everybody knows that the shortest distance between 2 points is a straight line. It follows that in the context of solution creation, the most efficient way to create a useful solution is to go directly from a starting point to your final solution.

Walking a straight line means that every effort, every configuration, every installation and every line of code moves you incrementally and inexorably closer your final solution. No back-tracking, no feature changing, no unnecessary complexity, no waste.

Where you Start is Important

You need to understand where you are starting from. This may seem straightforward but for better or worse, there are a lot of possible starting points for a solution, particularly in I.T.

If you are a hard core enthusiast, you might start close to the centre, from hardware, a circuit board, Raspberry Pi or Arduino device but this is unusual. More commonly, you will choose to start with a particular device, operating system, platform, or tool-set. These all bring their own complexity, features and abstractions and using them means that you are starting at some point away from the centre. It follows that there are good and bad places to start.

Teams will usually do a ‘Sprint 0’ or ‘Proof of Concept’ or ‘Spike’ to try and get this starting point right. These periods of technical discovery can be difficult for management and external stakeholders to understand. There is a perception that no progress is being made; however, these activities help the team to start closer to the finish, it actually makes the journey shorter. Taking time to get it right makes practical sense.

Knowing where you are going is Important

If you are going to walk straight, you need to know where you are heading. This is at once the simplest and most complicated part of the problem.

Requirements and detail design documentation, user stories, paper prototyping, non functional requirements, design briefs and minimum viable product are all different ways that we attempt to define and reason about what our end point might be, before we are at that point.

These tools are all useful in their own way but they are all just approximations; imperfect attempts to conceptually describe something that doesn’t exist yet. Once you stop building, you have a single solution. One particular set of configurations, instructions and assets that affords one particular set of features. In the context of solution space, a completed solution is a point.

In addition to the difficulty of artifacts, there is also the problem of interpretation. Often different people in a solution team have different views of what the endpoint is.

Walk Straight

I think that if you have clearly defined your start and end points, you are well on the way to walking straight. I have thrown down a couple of thoughts here about what might cause deviations but much more thought is needed on this.

Bugs and Errors

No real people are perfect. Developers and other technical people make mistakes. I think this is where testing jumps in and helps us. I will resist the urge to invoke any crutch metaphors resist.

Unforeseen Obstacles

3rd party libraries with defects or just-discovered vulnerabilities, counter-intuitive API’s, undocumented features.

Learning to Walk

The job of a technical person is to navigate and manipulate the many layers of abstraction between hardware and eyeballs in order to build useful solutions. Unless teams have chosen to start with and use only familiar and stable technologies, there is usually some learning on the job required.

Solution space as a Retro Technique

Solution space can be a cool retro technique. This is just one idea of how you might do it. I’m super interested to hear other ideas and experiences from folks. ###Use To talk about how efficiently the team was able to finish a particular story or feature ###Length of time 10 - 30 minutes ###short description A technique in which team members map out their experience of progress on a particular story or feature, discussing the twists and turns and how a more direct route may have been possible. ###Materials Whiteboard + different coloured pens ###Process The team decide which feature or story is to be discussed. This may be an obvious problematic feature or it may be decided with cards/votes or any other method.

Team members take turns to ‘map out’ their personal journey through solution space for the particular story or feature. This begins by drawing an area that represents their understanding of the initial target and a point representing where they thought the journey started.

Then each team member ‘draws the journey’ from the starting point outwards for progress, around the circle for changes in direction, features or re-implementation and in towards the middle for regression.

At any point, the person drawing may draw a new re-draw the target to indicate changes in requirements, approach or understanding.

Each change in direction usually warrants a comment written on the board at that point and these will be points of discussion. ‘changed our minds on this feature’, ‘cleared up a misunderstanding about a requirement and had to change things’, ‘realised it was over-engineered and we refactored to something simpler’.

One interesting thing that may fall out is that different team members had different views of the progress on the story or feature. This technique may drive out any type of action but most frequently, the importance of communication and clear understanding of start and end points are highlighted.