Krishna Kumar

March 10, 2021

Cards on a Board

We’ve all seen them wherever software teams work: the whiteboards with sticky notes posted in neat little rows and columns, or more likely these days, the electronic Scrum or Kanban board filled with card-like things in even neater rows and columns. 

People sit around quietly at their desks tapping away and every now and then, someone moves a card from one column to the next. Every now and then, there is a high-five when a card reaches the last column. If this was “bring your kids to the office” day, the little ones would not be out of line thinking their mum or dad "made" software simply by moving cards on a board. 

Cool for little kids, but unfortunately not so cool when this is the way your engineering analytics tool thinks too. 

Everything interesting about making software happens between the time a card enters one column and moves to the next. Yet, almost all current techniques and tools for analyzing software development processes treat cards as the basic primitives and the movement of cards between columns in the board as the basic operation in a software process.

We count cards to measure throughput. We put limits on the number of cards in a column to manage bottlenecks. We measure stats on how long cards took to move between columns to analyze bottlenecks, usually after all the movements are done, and the bottlenecks have moved on as well.

Of course, there is huge value in knowing how long cards took to move between columns, but if you want to know why it took so long to move, or why its been sitting in one place for so long,  then you need to have some way of looking at what was happening in between those movements, while people were sitting quietly at their desks tapping away. When you don’t have the situational awareness that comes with knowing what’s going on behind those keyboards, you enter the dreaded “negative feedback loop of distraction”.

It goes like this. 

  1. The engineering manager wants to know why that card has not moved in two days, so 
  2. He walks over to (or emails, or Slacks) the engineer to find out why, and in doing so
  3. Breaks the zen-like state in which she is cranking out code while typing quietly away.  

Her answer is probably not going to be of much help to the manager except to make him feel somewhat better (or worse), but in the mean-time he’s probably broken the flow state she was in - setting the card back an extra two hours and we are back at step 1.

It is designed to kill engineering productivity.  It is how most of us work today.

There is more than a little irony in the fact that an industry devoted to digitizing every conceivable human endeavor, seems to cling with such determination to analog techniques from the twentieth century, based on analyzing manufacturing assembly lines, when it comes analyzing to its own work.

But making software is nothing like making widgets. People “make” software by changing, testing and shipping code not by moving cards on a board. Can we find better solutions to this as software engineers? 

Continuous Measurement

Suppose we are able to visualize the actual work of making software by connecting each card to the actual code changes being made by engineers to implement the requirements in the card, in real time? If we did that then we’d know how far along the card was in implementation at any time. Not only that, we’d know how the card was implemented: what changes were made by whom, when they were made, how long they took, and a whole lot more. As a bonus, the card would tell you why the code changes were made, which has all sorts of useful implications, in shedding light on how the quality of the codebase impacts our ability to deliver certain types of features. And more. A lot more.

This is the fundamental premise behind Continuous Measurement, our approach to Measuring the Work of Making Software, developed at exathink with over half a decade of R&D behind it.  It provides everyone on the team, all the way from engineers to executives, a simple, intuitive vocabulary and a set of techniques to communicate intelligently about the work of making software in terms of code moving through engineering, that goes beyond the "cards on a board" model we use today. 

With Continuous Measurement, we not only get a lot of valuable data that managers can use, but we are also able to build tools on top of this data that give everyone on the team, engineers, tech leads, managers, product owners and executives the ability to visualize the detailed flow of work in engineering in real time, and answer questions going all the way from an engineer asking “who broke my code just now” to the CTO asking “why do features take so long to build”,  or “are engineers working on the right priorities”, or the product owner asking “was the customer value we got for this feature worth the engineering dollars we spent on it” and of course, the engineering manager asking “why hasn't that card moved for the last two days”. 

We've operationalized Continuous Measurement with a real-time measurement platform and app called Polaris. In addition, we are also introducing a continuous improvement framework called Ergonometrics™ for Software Teams, designed to use the measurements to help teams analyze  how they work to deliver software and systematically execute on strategies that will help them manage their engineering capacity to effectively and efficiently deliver the maximum customer value. 

Our approach is process-agnostic and is focused entirely on measuring and improving customer facing outcomes while connecting them to nitty gritty details of changing, testing and shipping code. So you can use it on top of whatever flavor of agile (or even waterfall, if that is still your thing) you may have in place.

Polaris and Ergonometrics™ for Software Teams have been field tested for several years in consulting engagements at exathink and we are launching them as products in an invite only public beta this month.  In preparation for the launch, I'll be posting more short articles here to talk about our approach and new tools we bring to the table here, in a series of follow-up posts.  

So if you think you might be interested in participating in the beta or simply following along on some of the ideas, please subscribe below. Or feel free to reach out to me via email at kkumar@hey.com or on Twitter (@krishnaku). I'm happy to chat. 

—————————-
Dr. Krishna Kumar
Founder/CEO
exathink.com
Ergonometrics™  for Software Teams
Measuring the Work of Making Software
twitter: @krishnaku