Once upon a time, I decided to join a digital signage startup.
Back then, Nave was a software development agency and our purpose was to help startups drive their development efforts in the right direction.
The company was aiming to deliver the first streaming service for public displays. Developing a cutting-edge digital signage solution that aims to disrupt the status quo is a big deal, especially if your entrepreneurial initiative is just starting out.
The problem with the current value propositions on the market was that they didn’t provide the possibility to present real-time content. The startup recognized this opportunity and they were very well-positioned to make a huge impact in the digital signage industry.
The cross-functional team consisted of 5 people, who were managed directly by the two founding partners of the company. And what the partners wanted was to have full confidence in the team to hit their targets.
A Sneak Peek Into The Reality
Let me give you some more context.
The demand was overwhelming. Every day a new priority emerged and it wouldn’t necessarily follow any established approach, or aim to bring either customer value or transparency to the decision-making process.
The team had adopted Scrum, but the implementation of the framework was really poor. The thing is, teams can only experience the full benefits of Scrum by understanding and adhering to the values and principles the framework promotes. And here, that simply wasn’t the case.
This is what a typical business day looked like: the managing partners came up with an idea, it felt interesting, and so it was pushed onto the team while they were in the middle of a sprint. There was no attention to the amount of work the team was already handling, and so tasks that were already in progress were constantly being interrupted. And finally, there was an expectation that all of the work should be delivered within the current sprint.
The team was constantly switching their context, suspending what they’d been working on, and starting the new idea that had just arrived. They stayed up till 5 in the morning to be able to meet the impossible deadlines. But, despite their efforts, they were always late. A huge amount of the scope of the current sprint was being moved to the next sprint, and that was happening over and over again.
And the fact is, they simply did not have the capacity to handle the constant stream of new requests. At one point, things became really tough. The managing partners were feeling super frustrated, because the team never managed to deliver the work they’d committed to on the release date, the quality of the deliverables they managed to finish was quite poor and the development cost went through the roof.
I assume it’s needless to say that the engagement and the motivation levels of these people were really low. Fingers were being pointed at each other all the time, the working environment was toxic. The team felt like their work never brought any value. There was no appreciation, trust, or respect. One after another, they started to resign.
It’s Time for a Change
Something had to change immediately! I was actively exploring the Kanban Method at the time, and it felt like exactly the approach we needed. All the concepts behind the method resonated with our current situation.
And probably the main strategy that sold me on Kanban was the data-driven approach to decision-making that it recommended.
It was time to bring some order to the chaos.
Back then, we used Trello to track our work, and there was no Kanban Analytics solution on the market that integrated with this platform. Switching to a Kanban tool was out of the question, so we decided to build our own internal solution. The star of Nave was born.
As we kept building more and more Kanban analytical charts that enabled us to analyze our performance and understand the root cause of the problem, it became obvious that the team needed to align the demand with their capacity and focus on finishing the outstanding work, rather than starting any new work.
At the very beginning, the first thing we did was discard all the aborted work items on the board. This was incredibly difficult for the team; they’d spent their nights and weekends working on these tasks, and it felt like all their effort was for nothing. But, they knew it was the start of a new beginning, so they were still really open-minded about the change.
The next step was to limit the work in progress and implement a Kanban pull system. Let’s dive deeper into the message our data communicated, and how it enabled us to head in the right direction.
Your Data Is Talking to You, Listen
To optimize your workflow performance, you need to break down your delivery times and evaluate the improvement opportunities. This is best achieved by using the Cycle Time Breakdown Chart.
The chart displays the cycle times of your completed tasks split by process state. By analyzing the different sections on the bars, you can assess how the time spent in each state affects the overall time needed to finish your work.
For example, here the data is split by week. In the week Jul 16th – Jul 22nd, tasks spent a significant amount of time in the light pink zone, corresponding to the Code Review (Done) state.
Following on from this analysis, there were two main objectives for the team that came up.
1. They knew that a tremendous amount of the time their work spent in Development was actually caused by suspending what they’ve started. They decided to stop multitasking and only start new work when they had finished their old work.
2. There was an obvious bottleneck in the Testing state. 1 QA was definitely not enough to handle the work produced by 4 developers. As a result, the work was piling up in front of the Testing state – which explained the huge amount of time the work items spent in Code Review (Done).
They decided to allocate multiple developers to the testing phase, so that they could handle the demand and enable the work to move forward. The focus was set on finishing the work, rather than starting new work. And from the beginning of August, you can see the results – these sections were reduced by about 4 times. And that was a huge motivation boost for the team.
You can see what the Aging Chart of the team looked like back in June 2018. There was a high number of aging work items either being blocked by an external dependency or simply being neglected, due to another high-priority item.
And this is what it looked like after we started managing the flow of work effectively. Essentially, what we did was keep track of how much time each work item spent in progress to monitor their WIP age and then follow up on anything that went above the 70th percentile.
The results? A steady flow of work and no more aborted tasks in the middle of the workflow. The entire workload was positioned below the orange zone, which meant our current work took less time than 85% of our previous work.
I want you to take a moment and acknowledge how the ultimate performance improvement that we’d managed to achieve actually had nothing to do with how individuals were performing. It was all about resolving the obstacles that prevented us from delivering on our commitments.
Our throughput became much more consistent, too. Let’s analyze the Throughput Run Chart.
The chart displays the throughput of your team for a specific time frame – you can group your data by day, week, 2 weeks, or month. The horizontal axis represents a timeline, while the vertical axis shows your throughput. Each bar consists of colored sections representing the type of completed work.
Here, we see that up until the end of July, the throughput of the team was very inconsistent. For many weeks, they only managed to keep it at a high level because they were working overtime and pushing themselves beyond their limits to be able to deliver.
After they limited their work in progress and adopted a pull system, the overburden was eliminated and the team went back to normal working hours. The workload was aligned to their capacity. The total working time reduced and as a result, the development cost reduced as well. Their throughput, though, increased and it became much more consistent and predictable.
I have to tell you, at the beginning of all this, the two founders felt really uncomfortable. Knowing that everything was delayed, they felt the urge to push even more work to make up for the delays. Now, they had to put a stop which, naturally, met resistance.
They only managed to shift their mindset once they actually saw the results – the reduced delivery times, the increased throughput, and most importantly, the predictability and the consistency we managed to achieve. Finishing work in progress before starting new work was fundamental for the business.
These approaches were so successful, and they led to such an amazing improvement in the team’s performance and the organizational culture, that I decided to move on and fully dedicate my time and energy to developing the concept of Nave and providing a bespoke value proposition to the market.
You Have the Power to Make a Difference
And this is what I really want you to understand.
If you are struggling to deliver on your commitments, if you want the process of estimating to be easier, less time consuming and to actually work… If you wish to deliver results in a consistent predictable manner, without overburdening your teams…
If you’re tired of the overwhelming stream of incoming requests… If you see how your team falls into the throes of full-fledged burnout while trying to meet impossible deadlines… If you’re looking for reliable approaches to set up and manage realistic goals… It’s time for a change!
It’s time to take control of your management practices and start making reliable decisions!
You have the power to make a difference. Use that power!
Start as early as tomorrow morning. Don’t delay! After all, continuous improvement builds over time, with one small win following another.
Commit to promoting evolutionary change and a culture of continuous improvement. Commit now. What is the next small step you’ll take to make a difference?
If you’re willing to explore the proven roadmap to building predictable delivery workflows, I’d be thrilled to welcome you to our Sustainable Predictability program!
