Application Kata: Idea Flow Mapping
Idea Flow Mapping
is a method invented by Jeanelle Klein to trigger the most effective improvement efforts in order to achieve sustainable fluent software production.
According to Jeanelle any changes have to be backed by evidence of what we really do. More or less test automation, more or less clean code practices, more or less agile rituals? It all depends on the rate of progress you make, the time you spent realizing your ideas. As long as most of the time you're truly progressing, all's fine. But once progress decreases and troubleshooting of some kind increases, some action needs to be taken.
What's progress? Producing results as expected, transforming your valuable ideas into correct and useful code. What's troubleshooting? Being in conflict with what you expected. You expect code you just wrote to compile without error – and it does not? That's a conflict. Now you're entering conflict resolution mode. That's not progress, that's troubleshooting. Or your code compiles but when you run your tests some old ones break, i.e. a regression occured? That's a conflict, too. You've to enter conflict resolution mode. Or you're happily coding – and your boss requires your immediate attention for an hour? That's a conflict too, because you expected uninterrupted coding time until noon.
Jeanelle argues we don't really know how much time we spend progressing and how much time we're troubleshooting. We don't realize how much money gets sucked up by conflicts. Especially decision makers are decoupled from the amount of conflict their orders might cause. A basic feedback loop is broken in companies.
Her recommendation: Track your time. The first step to reasonable change is to observe. That means measuring how time is spent, whether work is progressing or troubleshooting is taking place.
Once such data has been recorded maps can be drawn to show the distribution of the working modes over time. Here's an example from her book:
Based on these maps informed decisions can be made. Analysis not only of the patterns of troubleshooting time but also where conflicts arose will lead the way to the most reasonable improvement efforts – and serve as feedback for decison makers.
This can cause disillusionment and it should. In many cases much more time is spend in troubleshooting than believed. We're constantly overrating progress and downplaying conflicts – despite all the “WTF!” heard from developer team rooms.
Develop an application for Idea Flow Mapping.
Users must be able to track their time with the app as well as produce idea flow maps.
A user starts time tracking in progress mode and by adding any number of tags. Tags can represent projects or tasks or other aspects of tasks.
While time tracking is on, the user can switch between progressing and conflict resolution at any time – and optionally add tags.
Once a task has been accomplished time tracking for it is stopped.
If needed a stopped task can be opened again to continue tracking time invested into it.
If a user wants to take a break tracking can be paused and later be resumed.
While time tracking a task the user should see a simple history of mode changes.
All this is recorded persistently in some database for later report generation.
Several users in a local network can track their tasks at the same time.
In order to resume a paused task or continue a stopped one some overview of tasks (completed as well as running) is needed for the user to select from.
From this overview tasks can also be deleted – which will be logged to the tracking database.
Reporting produces idea flow maps like the above in some (simple) way. The main purpose is to easily get an overview of how time was spend. How the pattern between progress and different types of conflict resolution (e.g. #troubleshooting, #learning, #rework) looks.
For that tasks need to be selected by user and/or date and/or tag.
Reports are rendered directly on screen. Or if it's easier can be written to a file (e.g. jpeg, SVG) and then opened using some standard program like a web browser.
To not let quick mode changes, eg because a wrong mode was selected, add noise to the report, only modes lasting at least 1.5 minutes are displayed. If a mode’s duration is less, the previous mode is extended by half the duration and the next one advanced by half the duration.
There's no need for real security measures. Within the context of a single company (or team) users trust each other. To identify themselves for time tracking they only need to provide their email addresses upon app start.
The app can even remember who started it last time. Until a different user “signs in”.
User Interface Sketch
The app does not need a fancy GUI. A simple console UI will do, too. It could look like this: