Back to Blog
Date Posted: 2018-06-04

Visualising development flow with DevMetrics

Achieving optimal flow is central to Lean Software Development. To achieve flow, teams need to optimize the value chain as a whole, eliminating bottlenecks, reducing work-in-progress and balancing capacity at each point in the process. Achieving flow is central to unlocking continuous delivery and building a responsive software development capability.

How does DevMetrics track flow?

From DevMetrics perspective, flow is best tracked by looking at code activity. Accepting that teams do more than just write code, code activity is still a good indicator for flow because it reflects the amount of change that is being generated by the team. When looked at over time, changes in the team’s level of code activity are a good approximation of flow.

Common flow patterns

With DevMetrics we have seen several common patterns of code activity that speak to a team’s flow, we'll dig a bit more into the most common patterns here.

Perfect Flow

Perfect Flow
Perfect Flow is nearly constant with expected dips during holidays and the occasional slight spike

In a perfect world and given a stable flow of requirements this is what the Code Activity would look like. There will be minor fluctuations but, in general, the level of activity is stable. With the exception of a change in the team, the level of code activity remains stable, and as long as there are requirements the team can keep up this pace indefinitely.

The See-Saw

See-Saw Flow Pattern
Definite dips and peaks that coincide with iteration length indicates a see-saw pattern

The See-Saw is the most common pattern in DevMetrics. A gradual upswing in activity that peaks and then subsides over a predictable interval. This interval generally coincides with the team’s iteration length. For example, if the team works on 2-week iterations we see the cycle repeat over 2 weeks as the team plans, builds and tests the new features.

Something to keep an eye on is the point in the cycle where the team ‘peaks’ and how soon in the iteration this occurs. Does the team quickly reach some maximum and then taper towards the end or is there a long buildup peaking towards the end of the iteration? The former case indicates that the team has returned to a flow state quickly whilst the latter may point to some issues in attaining flow.

Here are some common issues that can affect flow:

  • Meetings. Are your meetings planned as optimally as possible? Are unplanned meetings forcing the team to context-switch?
  • Weak ‘Ready for Dev’ definition. If requirements are poor the team will spend additional time clarifying them before starting development.
  • Testing Late. When testing is left to late in the iteration it can cause disruption as developers will need to move between their current assignment and bug fixing. Untested work is a form of Work In Progress and represents a possible disruption if issues are identified late in the process.

The Chaos Swing

Chaos Swing
The Chaos Swing appears much like see-saw but with irregular dips and peaks

This is See-Saw’s evil cousin. The level of Code Activity fluctuates wildly over an unpredictable interval . This pattern is the most obvious indicator of a severe lack of flow. Typically, this pattern is caused by either inconsistent requirements, technical debt or both.

Inconsistent requirements mean that the amount of work the team is asked to do varies wildly from iteration to iteration. Whereas the team is bored one iteration they quickly swing into panic mode the next as a ton of requirements are now available. Coupled with poor capacity planning or external pressure to ‘get things done’, the result is chaos.

Unmanaged Technical Debt means that the level of effort to implement a feature changes wildly based on which areas of the application need to be changed. A new feature for example can easily be added because it interacts with fewer parts of the application. A change to an existing module however requires a huge amount of effort – not necessarily because of the complexity of the requirement – but because the Technical Debt in that area must either be addressed (which takes effort) or accepted (which takes more effort).

The Death March

Death March
The Death March is identified by sudden, large peaks in activity, usually followed by much lower levels of activity as the team recovers

It’s 2018 and sadly this anti-pattern of software development is still with us. The technical definition of a Death March, according to Edward Yourdon, is a project whose 'project parameters exceed the norm by at least 50 percent’. This somewhat clinical definition masks the reality of being on one of these projects – late nights, working weekends, low morale, poor quality and shattered teams.

What a Death March looks like from a DevMetrics perspective is fairly predictable. A long, slow build up followed by an order of magnitude increase in activity. This is the point where the calls of ‘all hands on deck’ echo through the halls and the coffee machines start to work overtime. The level of activity stays at this level until the project is stopped, the milestone is reached or the team burns out.

There are two things that DevMetrics highlights which are not so obvious.

  • In the majority of these projects the total amount of activity could have been achieved in the same if not a shorter time frame, had the team worked consistently. If the issues and impediments had been recognized earlier and addressed, the Death March could have been avoided.
  • The level of activity following the Death March drops to practically zero. This is the team recovering. Nobody wants to touch the project barring minor bug fixes. This typically lasts for at least as long as the Death March itself. For example, a 1-month Death March could result in a 2-month cool-down period.

Where to from here?

Which of these patterns most closely resembles your team? Discuss with your team why your Activity looks like this. What changes could you make to your process to smooth out the flow? Pick one item and try that for one iteration. Predict what the change to your flow would be and see if that is what happens. Here are some examples of things teams we have worked with have tried:

  • Agreeing a formal definition of ‘Ready to Dev’ to prevent delays caused by incomplete requirements.
  • Creating a ‘Meetings’ block on a single day so that the team can plan around them.
  • Agreeing that all Pull Requests will be reviewed on the day they are submitted.

Keep in mind that each team is different and what worked for one team may not work for another.

We’ll be sharing interesting patterns and metrics we uncover on this blog, so keep an eye out. In the meantime, make use of the free trial to see what insights your repo holds that are waiting to be uncovered.

DevMetrics Graph