WIP? WIP! Or how to decrease time to market using Jira Agile Boards
Introduction
In this article, I will outline why focusing on time to market is essential for software development companies. I will focus primarily on Kanban and limiting work in progress (WIP) as quick gains in optimizing your time to market. I will also cover different levels of Kanban maturity in order to shed light on what kind of WIPs we can track and optimize. And, of course, the Atlassian Jira ecosystem together with Marketplace Apps will be the main consideration for the toolset.
Time to market matters?
The World is spinning quicker and quicker every single day. Time is getting to be the most critical resource for companies and individuals at the same time. Focus on innovations requires an abilty to perform rapid testing of multiple hypotheses and failing fast to avoid wasting resources on non-workable ideas. Furthermore, innovative, speedy and dynamic companies can beat the competition and disrupt — industries that feature slow “classic market leaders“.
The key to being fast is time to market (TTM). Nowadays, this metric is becoming the primary focus in contrast to resource utilization, — time spent etc. Even well established, classic planning approaches are getting to be less important as people, more and more, spend time on development and responding to feedback from the market or from customers instead of building solid plans.
The boom in startups and the availability of venture capital is also changing the mindset of the people who want to search for new innovations, test them as quickly as possible and to move on to another idea if the first one is not successful.
Even enterprises are now tending to adopt or maintain a startup and entrepreneurial spirit, simplifying bureaucracy and creating as flat an organisational structure as possible to maintain the flexible business processes. (The Soul of a Start-Up, How To Keep Your Entrepreneurial Spirit Alive As The Company You Work For Grows)
All these factors are driving a change in project management methodologies. Waterfall, which was the de facto standard years ago, is hardly ever used nowadays. Even dependable Scrum is now considered too slow in some cases. Software development companies are decreasing TTM by implementing a continuous delivery process, improving automation so they are able to immediately release the feature as soon as it has been developed.
Kanban used to be solely a framework for small teams with unpredictable task flows or for production lines. Now, the situation has fundamentally changed. Kanban is widely used at various levels of the organization including portfolio and program levels. A number of organizations have developed comprehensive frameworks and training courses (e.g.Kanban Maturity Model , Kanban University ) and have accumulated masses of practical experience in rolling out these practices in real-world organizations.
So implementing Kanban can help you to be focused on TTM measurement and continual improvements.
I personally have Deja Vu with the same process when Scaled Agile Framework started to become popular almost 10 long years ago.
How good are we in Kanban?
While Kanban is becoming more popular, companies are starting to ask questions:
- How well do we do with Kanban?
- How can we improve and what will we gain?
- What should be our next steps for us in order to achieve it?
Personally, Iad the same questions when working in a company that started moving away from Scrum to Kanban and found the answers in Kanban Maturity Model (KMM). I believe the KMM creators have done a great job in structuring practical experience and building a solid improvement path.
I will not be touching on all the details, focussing on limiting WIP only and showing how we can improve time to market right now, and with minimal outlay.
Why limiting work in progress is important.
According to Little’s law (Little’s law) lead time (or TTM in our case) is the number of items in progress divided by throughput (or processing rate, which correlates with the number of people in the team or organization).
By simplifying things, we can decrease time to market by decreasing the WIP limit or adding more people to the team.
Decreasing the WIP could be a quick and cheap solution in comparison to adding more people to the team.
Yes, this might seem counterintuitive but you can see how this works by watching the “Flip the coin“ simulation that can illustrate the same principle in real life (Penny Game / Coin Flip Game / Agile Coin Game you can jump straight to the results from ~ 20:00 if you don’t have enough time to watch the whole video)
Okay, now we can get started?
There are multiple options to apply WIP and improve the process. To give it some structure we decided to use KMM as a roadmap of our implementation and focus on WIPs based on the maturity of our processes.
The first thing we need to do is start by evaluating the current Kanban maturity level. The Kanban maturity model can help with that.
As we begin discussing this topic in connection with Atlassian Jira I will be referring to core functionality or to Marketplace Apps in order to achieve since some functionality is missing from Jira Software.
In following KMM, let’s start from the zero level that is called, “Oblivious“.
0. “Oblivious“
At this maturity level, personal kanban boards are available. Each team member can see their work and limit their personal WIP limits.
This functionality is available in Jira out of the box; you can create multiple boards and make slight adjustments to the JQL filter to get a tailored view for each team member.
1. “Team focused”
At this maturity level, the team creates a single team board and defines WIP limits for the whole team for each column. It brings a number of benefits, starting from taking a holistic view and finishing with the flexibility to assign any available person to the next task in the backlog.
In fact, this way of organizing the workload is suggested by Jira out of the box, when you create a new Kanban Project or Board.
Also, KMM is able to suggest creating per person swimlanes as well as apply a WIP limit to each swimlane, but this option is not available in Jira out of the box. Since out-of-the-box Jira Kanban boards do not cover all the functionality for all the levels, I want to present an App from the marketplace. So where possible, I will be demonstrating the implementation with Jira standard kanban board. In other cases, I will be showing kanban board from the App: Advanced Agile Boards | Atlassian Marketplace
2. “Customer-Driven”
On this maturity level, no changes are touching on WIP at this level, so let’s move on to the next level.
3. “Fit-for-Purpose”
On this maturity level, from the WIP limit point of view, the first thing that we can do is adding Pull Signals. A Pull Signal is a clear indicator that a task item is ready to be pulled by the next process step. Some teams make use of Pull Signals such as an internal Done column.
For example, we have a software development process. Within the Development step, there is an Ongoing and a Done column. The Done column signals to the person in charge of the Testing step that any work item within this column is ready for testing.
In addition, we can establish bracket WIP limits across activities and sub-states: 4 maximum items for Development and 2 for QA and Deployment:
After that, we can add a minimum WIP limit for upstream replenishment. In our case, at least one item will be ready for testing and at least 2 items in the backlog:
Unfortunately, Jira can’t support WIP implementation of this level out of the box, so we would again need to employ Marketplace Apps to make it work. For instance the app from Level 1.
4. “Risk-Hedged”
On this maturity level, WIP is going to be applied for
- Dependency parking lot
- By type of work
- Class of service
In contrast to Level 3 requirements, this functionality is available in the standard Jira Kanban boards and the add-on.
We are able to define swimlanes for dependencies, class of service or work type and define a WIP for the entire swimlane:
How this could be done in Jira
And the add on:
In the add-on, we can also apply the WIP limit for the intersection of the column (column bracket ) and the swimlane.
A separate swimlane may be created so as to visualize external dependencies. The WIP limit should be defined for this swimlane as well. This functionality is available in the add-on only.
5. “Market Leader” and 6. “Built for Survival:
On these maturity levels, no other improvements of WIP limits are expected and changes are made in other areas, so I will skip an explanation of these levels in this article.
You can always read more details on Kanban Maturity Model
Conclusion
In this article, I have shared with you the importance of tracking and optimizing time to market. Kanban, with a focus on limiting WIP, can help achieve this. By using the Kanban maturity model, you are able to assess your organization and build an improvement path.
On each level of maturity, various types of work in progress limits should be applied. On top of this, the model demonstrates the correct sequence of implementation.
Out of the box, Jira can help with the implementation of Kanban on level of maturity 0, 1 and partially 2. Levels 3 and 4 require the use of extra Marketplace applications. We are working with this one: Advanced Agile Boards | Atlassian Marketplace.
I hope this article can help you progress in doing less in return for getting more.
As usual, I would be very happy to hear your feedback in the comments under this article.