In Progress and the Curse of Reductionism
Written by Brian Ganas
This is the third in our series of posts on The Product Mindset. See the first post in the series here: The Product Mindset.
As we’ve explored throughout this series, a surefire way for companies and teams to improve their value to their customers and align their own priorities, mission, and working cadences is to cultivate a product mindset.
This is the set of attitudes, beliefs, and behaviors that is concerned with building your business by building great products in response to the needs and desires of your customers or other users. A product mindset prioritizes outcomes, learning, understanding of users, and total system health. It’s an approach that pairs neatly with agile development models.
My SDG colleagues and I have had the pleasure and responsibility of working with teams and customers across industries and contexts. One observation I’ve made is that working teams at the ground level are generally willing to try new methods and approaches, like a product mindset.
But even the most willing and progressive team may be fighting hidden forces. These forces can hinder good product practices for even the most collaborative and productive product team. In effect, the team is paddling against a current, and it may not even know it.
The power of a two person team
My colleague and I, unsatisfied with the status quo and intoxicated with the power given to us in our two-person team, began assembling the most authentic Kanban board we could come up with. We started simple, with Backlog and To Do. We added In Progress and Done. Then we got bold. We added a column for Testing and UAT. “But,” I said, “isn’t that just a part of in progress?”
With the dam burst, we found ourselves staring at a Kanban board with 17 columns. What started as a serious exercise quickly turned to a fun one, but something dramatic emerged from the silly board we had assembled. All our additional columns were flavored as “In Progress,” but they were legitimate statuses one could find their work in, such as Roadblocked and Reworking.
The “In Progress” column serves an important purpose. It lets high-level viewers know that a task is being worked on. It provides a quick glance into the activity of the team. But the concept of boiling down all the work that goes into a single item in a status of “In Progress” can feel overly reductionist, especially to the person doing the work.
One little box
As an analyst, I tend to find myself assigned to SPIKE stories. I get a timebox (fancy!) to figure out how a particular process works. I spend hours interviewing people, shadowing, browsing documentation, making beautiful diagrams — and then I get to sheepishly move a little box from the left to the right, about an inch, to announce to my Product Owner that I am done. It’s very anti-climactic.
Complex processes can be reduced to simple representations; we all know this, and we all know there are significant benefits to be gained from those representations. But don’t let the simplicity of that In Progress column ever detract from your feeling of accomplishment — don’t ever let it make you feel unjustified in your frustration when something isn’t working, or when you hit a dead end and don’t know what to do.
How do you accurately reflect the work?
Allow me to share some of the columns we came up with in an attempt to truly report on the status of our tasks.
We started with Roadblocked, one of our legitimate contributions (before the sillies set in) to our “In Progress buffet.” We’ve all been there. We’ve all felt the dead-end looming over us. This was, of course, followed easily with Roadblocked Again. Clearly, this is where the aforementioned sillies began. Roadblocked Again sounds like it would be the same to the inexperienced, but I would challenge anyone who has worked on a project to tell me that hitting your second dead end feels the same as hitting your first one.
We added the one-two-three-punch — I Think I’m Done / I Was Wrong / Reworking. You’ve finished. You met the requirements or the acceptance criteria. You’ve tested. It makes sense. You’re happy. You think you’re done. And then someone has to deliver the bad news: you were wrong. After you’re done playing the “blame somebody else” game (my personal recommendations are “the requirements were wrong” or “the request was stupid”), it’s time to accept your mistake and move on. Time for rework!
Every Kanban board should include the column Meetings About Roadblocks. We all have to do this. You’re not alone.
Celebrate the victory of the little box
We came up with many more, each funnier than the last I assure you. But our board eventually conformed to the norms we’ve all come to love, and we kept it all wrapped up in a traditional “In Progress” column. It may have taken a silly turn, but it became very clear to me as we developed our super Kanban board how much baggage we pack into that single “In Progress” column. Every hard-worked minute spent on fixing bugs or implementing new features gets tracked there. For the simple tickets, it’s perfect. But for the intense time sinks, where we lose hours — sometimes days — to frustration, roadblocks, ambiguity, and pounding our fists into desks, “In Progress” just doesn’t quite do it all justice.
I vowed to take a few steps to make sure I respected the curse of the “In Progress” column. Every ticket, no matter how simple or easy to resolve, was treated almost like its own mini project. Every time my developer finished an item, we took time to celebrate the victory, even if it was just a brief conversation to reflect on how much I appreciated his work, or what I could do better to make the next ticket go even better. It was a small step in the project, but I worked hard to appreciate the emotional process that accompanies each and every ticket.
Conclusion
The curse of “In Progress” is very real. As an Analyst, I’ll remember it when I feel disheartened watching my colleagues plow through stories every week while my large SPIKE stories sit in the same column for days at a time. As a Scrum Master, I’ll remember the curse when I’m wondering why my team has issues sitting in that column for what feels like too long a time. But most importantly, I’ll remember that the simple act of moving a task into Done is often deserving of a lot more praise than that quick action would lead you to believe.
Related Posts
Software Development with Agile Hybrid Projects
insights