🎼Time is ticking away, tick, tick, ticking away 🎸
DC Talk Time is ticking away
"Lost time is never found again."
"So teach us to number our days that we may get a heart of wisdom."
Moses - Psalms 90:12
As I’m getting older (so are you ;-)), I’m realizing the value of time more and more. I have less extra time and have to constantly make choices (Should I watch a movie or go to bed or read a book. Should we sign up the kids for an activity or are we overwhelmed already? the list goes on). I’ve also been apart of many months of software development where the work never got used and was a waste for the company. I’m not the only one, our industry has a huge amount of waste!
I’ve been reading and thinking about How do we have more feedback, flow, continuous learning and joy as Mik Kirsten talks about in IdealCast episode 2? “how do I become more efficient and create more value?”, “What can I do as a engineer, when I’m not running the company, to help my company and other companies to thrive?”, “How do I apply the knowledge I’ve gained from books and articles over the years?”.
"Peter Moore (00:11:39): And what McKinsey did was they didn't study in 2018, and they documented it around the globe there was approximately $1.3 trillion spent on some version of, of digital transformation, 70% of which did not achieve its desired goals, which means $900 billion, ( laughs) did not get much of a return." ~[IdealCast episode 1](https://itrevolution.com/idealcast-episode-1/)
I’ve also spent some frantic days fixing and adding features to find out a few days or weeks later that the customer wants it to behave a different way. I put in a configuration value and added the new feature, hoping that someone will want it the other way. Really, we’re just guessing until customers actually use this.
I began reading Product to Project by Dr. Mik Kirsten while holding Ephraim (our 4th child) in the NICU (he was born 5 weeks early. We were there for 7 days, but he’s healthy and growing fast!).
Mik quotes work from Carlota Perez that we are in the middle of a disruptive age, moving from the Age of Manufacturing to the Age of Software. We are entering the “Deployment Period” 1 - pg 18 and no sector will go un-touched. Perez equates this to the Industrial Revolution and the “Age of Steam & Railways” [1 - pg 21]. We can already see this with Blockbuster, the rise of the tech giants and Tesla. Companies are becoming software and tech companies to survive.
One problem is that the tech giants have found ways to create a lot of value with huge teams and others like Sears, Kohls, etc are failing behind. Some like Nokia invested a lot in Agile training, but couldn’t right the ship.
The book points out these and many other problems with current management approaches for large scale. Many times IT is labeled as a cost center. We can learn from Lean Manufacturing, but software isn’t exactly the same. Software development isn’t connected to the “value stream”.
In his 2018 DOES  talk, he gives an overview of the book. He says that most of thrashing is where disconnection of code to the business. I highly recommend listening to this one, followed by Episode 1 of IdealCast 2.
In the book  and his 2018 DOES talk , Mik shares about visiting the BMW plant and seeing how they approach manufacturing. He has three epiphanies that formulate his approaches to fixing the problems
#1 "Productivity declines and waste increases as software scales due to disconnects between the architecture and value stream" [1 pg 23] #2 "Disconnected software value streams are the bottleneck to software productivity at scale. These value stream disconnects are caused by the misapplication of the project management model" [1 pg 23] #3 "Software value streams are not linear manufacturing processes by complex collaboration networks that need to be aligned to products" [1 pg 24] (don't manage to cost savings). "More like an airline network" - See the graphic on [1 - pg 183]
In March, 2021, I “refactored” out this section into Improving Organizations Readings.
I’ve been a part of a year long project, we were rebuilding a system and seemed to be making good progress. They had attempted to estimate it ahead of time, but a 1000 hours is really hard to get right. Some things took longer. At the end, they brought in a new leader, my contract ended and I don’t think anyone used our software. The developers thought we were really close. How did we fail?
I was a part of another company for a 6 year span. They went from multiple software platforms that did similar things. They started a re-write, but realized they couldn’t just copy the functionality that was before. Over the years we learned about automated testing (unit and UI), moved to feature teams (members from multiple horizontal layers (server, UI, QA engineers, hardware and a PO)), with once a week component days (UI, server meeting on their own) and Scaled Agile Framework (SaFE) with combined planning.
Recently, I rushed to get a piece of a service working in a certain way. I made a mess, but got it working. Thankfully, I had some time to clean up the “technical debt” and got it into a more readable/maintainable state. A few weeks later, we found the customer didn’t even need this functionality. Could we have avoided the rush if we had the time and had connected these decisions to a value stream?
This is a really hard question. It’s vague and depends on each situation. Experimenting, learning from those results and pivoting when needed seem to be the way to find this.
Many things are different between Project-Oriented Management vs. Product-Oriented Management Office. See the table on [1 pg 54]. Here are few examples:
This sounds like a great shift of thinking for software systems and matches the books and videos above.
The Flow Framework is Mik’s answer to the problem of the disconnect of software to the business.
“The role of the Value Stream Network is to provide an infrastructure for innovation for software delivery at scale.” [1 - pg 201]
The Flow Frameworks is a layer above Agile, DevOps and SAFe. It helps give visibility to the business leaders, align software development and puts the focus on the value streams.
There are 4 flow items (types of work): features, defects, risk (security/compliance), and technical debt. With 4 corresponding business results: Value, Cost, Quality, Happiness.
We need the Flow Framework to help answer these questions:
~[1 - pg 66]
Start with the customer. What are we delivering to the customers?
The Value Stream Networks allows “measuring the four flow metrics in real time across all value streams” Flow Velocity [1 - pg 98], Flow Time [1 - pg 102], Flow Load [1 - pg 106], Flow Efficiency [1 - pg 107]. Use data to help decision makers see where investments need to be made.
~ Screenshot from https://flowframework.org/about/
I’m not really doing this justice. There was a lot more to the flow framework and some I didn’t get all of. Get the book and read it, listen to the IdealCast , checkout the TaskTop website.
TaskTop Viz Demo is impressive and shows all the parts of the Flow Framework in dashboard. I grabbed a screenshot from the demo.
Let’s say we are working for a company that sells it software system to other companies (we either host and manage it for them or they can install it in their servers). These companies sell services directly to customers. They like how our software is integrated and let’s them setup offerings, track sales opportunities, make the sale and provide customer support and integrate with billing and accounting.
Currently, there are several software UIs that support this. People from different timezones work on different UIs and backend services to support the software suite. This company often follows “Taylorism” (bring people to work) and team members feel disconnected. Developers will complete their work, wait for QA to test, then create an installer or drop for activations and support to move into the production environments. It often feels that the teams are competing against each other, waiting for each other and sometimes pointing fingers.
Can this be split up into value streams and cross-functional teams be created? Would this improve team work and change the focus to creating value and lead to better eNPS (Net Promoter Score and happiness at work)?
The business leaders and clients see the full suite as the value. Everyone would have to start to think differently.
We should start by thinking of the customer, how will this feature create value for them or how does this bug affect them.
We’d have to:
One take away I have so far, is Mik’s idea on how to setup feature teams. He says to focus on the “value stream” or the role of the customer. The team would focus on that section. Code and data could be organized and stored that way. Some day, deployments could be done by value stream instead of all as one big chunk.
Could we track the value stream items in Azure DevOps by applying tags and running queries?
It’s a big shift, so would require more thinking, but is very intriguing. I’m open to your thoughts, feedback and comments. Have you actually used TaskTop’s system? What am I missing?
Please consider using Brave and adding me to your BAT payment ledger. Then you won't have to see ads! (when I get to $100 in Google Ads for a payout, I pledge to turn off ads)
Also check out my Resources Page for referrals that would help me.