Visualize the problems, make decisions swiftly from project management to trouble shooting

Continuation of the previous post, very specific to one of the principle, while explaining the need for rest of the principles.

To ensure our team’s productivity and quality of delivery, we decided to start with one task at a time.

Each row represented one person and this gave us a visual clarity on how many tasks are being worked on by the team member. While this is the standard Kanban board, we had to decide on thresholds and actions when they are violated.

Should have minimum 3 tasks ready to start, anything less is a warning for planning team to come up with next set of tasks.

Having more than one in progress is a violation of our original plan, but it happens when something is pushed back due to quality issues or changes. This is acceptable to a level of 2 which is still a warning, more than that is considered as a problem, where the developer cannot deliver on time and we can expect delivery issues.

We have few more steps like verification, waiting etc., which actually is for testing or waiting for feedback from someone, blocked due to some issue and we were forced to start another work.

The waiting help us with an alarm in our daily stand up as this forces us to solve this, while the team scaled from 4 members to 25+, we started to have multiple boards and walking through them became more complex. This involves the communication between the teams, product architecture, inter dependency of teams and finally the release model.

“organizations which design systems … are constrained to produce designs which are copies of the communication structures of these organizations.”

— M. Conway

We designed our product with micro services and each having its own ownership to plan and deliver without breaking rest of the services. I would like to keep it for later as a different story.

You cannot visualize if you don’t have data

The Kanban board looks good, but it will not scale and give variety of metrics and more insights unless you try to identify in the board yourself.

We were in need of a software based tool, to support offshore (work from home) team. We need a dashboard to act on the problem, if the the decision maker is at home to analyze it over night.

What to choose and how to organize for our need was too deep to analyze, we just started every thing with Redmine and started logging into it, the task, time taken and its status.

We built our own dashboard just using the API to identify the following

• Basic kanban board with warnings and action areas just with aggregate values.
• Kanban board, based on team members and based on features.
• Pull requests waiting for a long time with 2 days as the warning.
• Failed builds and their down time metrics.
• Production service health as UP/DOWN with Red, Amber, Green indicators.
• Chart of time spent on activities (Dev/test/support/discussion etc.,)

While all the above are just numbers or colors, we prefer to have a color to the items that require actions, thresholds and violations are good for us as it helps to take actions swiftly.

The 7th principle of “The Toyota Way” forced us to collect metrics and that helped us to build the graphs and visualization. Now we could act faster and save a lot of money which is hidden as they are mostly waiting time and decision delays.

Lets have a detailed look on the metrics that we have collected and their differences in another story.