Application Kata "Idea Flow Mapping"

Idea Flow Mapping is a method invented by Jeanelle Klein to achieve the most effective improvements in software development.

According to Jeanelle, all changes must be backed up by evidence of what we are really doing. More or less test automation, more or less clean code practices, more or less agile rituals? It all depends on how fast you progress and how much time you spend realizing your ideas. As long as you are making real progress most of the time, everything is fine. However, as soon as progress decreases and troubleshooting increases, some measures need to be taken.

What is progress? Achieve the expected results and turn your valuable ideas into correct and useful code. What is a bug fix? Being in conflict with what you expected. You expect the code you just wrote to compile without errors - and it doesn't? That's a conflict. Now you are 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 has occurred? That is also a conflict. You need to switch to conflict resolution mode. Or you're happily programming - and your boss needs your immediate attention for an hour? That's a conflict too, because you were expecting uninterrupted coding time until noon.

Jeanelle argues that we don't really know how much time we spend making progress and how much time we spend troubleshooting. We don't know how much money is consumed by conflict. Decision makers in particular are disconnected from the conflicts their assignments can cause. A fundamental feedback loop is broken in companies.

Her recommendation: Track your time. The first step to making a sensible change is observation. This means that you measure how much 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 working modes over time. Here is an example from her book:

Your task

Develop an application for Idea Flow Mapping.

Users must be able to track their time with the app and create Idea Flow Maps.

Time recording

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.
When time recording is switched on, the user can switch between progress and conflict resolution at any time - and optionally add tags.
As soon as a task has been completed, the time recording for it is stopped.
If necessary, a stopped task can be reopened to continue tracking the time invested in it.
If a user wants to take a break, tracking can be paused and resumed later.

During the time recording of a task, the user should see a simple history of the mode changes.

All this is permanently recorded in a database for later reporting.
Several users in a local network can track their tasks simultaneously.

To continue a paused task or resume a paused task, an overview of the tasks (completed and ongoing) is required from which the user can select.
Tasks can also be deleted from this overview - which are logged in the tracking database.

Reporting

Reporting creates Idea Flow Maps like the ones above in a (simple) way. The main purpose is to easily get an overview of how time was spent. What the pattern is between progress and different types of conflict resolution (e.g. #Troubleshooting, #Learning, #Rework).

To do this, tasks must be selected by user and/or date and/or day.

Reports are rendered directly on the screen. Or, if it is easier, it can be written to a file (e.g. jpeg, SVG) and then opened with a standard program such as a web browser.

To prevent the fast mode from changing, e.g. because an incorrect mode has been selected, add noise to the report, only modes that last at least 1.5 minutes are displayed. If the duration of a mode is shorter, the previous mode is extended by half the duration and the next mode is brought forward by half the duration.

Security

No real security measures are required. In the context of a single company (or team), users trust each other. To identify themselves for time tracking, they only need to enter their email addresses when starting the app.

The app can even remember who started it the last time. Until another user "logs in".

User interface sketch of the console

The app does not need a fancy GUI. A simple console user interface is also sufficient. It could look like this:

(One feature is difficult to show in the above listing: constant updating. While a task is being tracked, the duration of the mode is updated at least every minute, if not every second. This is relevant for lines 4, 7, 9 above, for example. Once the user presses a button to change the mode, the automatic update is suspended).

As the example suggests, some commands can be issued with parameters:

• Start task: Without parameters, a new task is started, otherwise the task whose ID has been assigned is restarted.
• Task history: Without parameters, today's tasks are listed, otherwise a specified number of tasks are counted back from the last. Only tasks of the current user are listed.
• Delete task: The task with the specified ID is deleted.

And here's an idea for a simple console report:

However, more creativity would be desirable for this part of the application. Even though time recording is the basis for all reporting and should run smoothly, the benefits of idea flow mapping can only be exploited if the reporting provides meaningful diagrams.

More complex user interface

A web UI or desktop GUI is of course welcome.