Achieving greater Transparency with Kanban

Here, I am going to talk about Kanban and how Kanban methodology can be used as a tool to achieve greater transparency upholding the agile values and principles. I shall be sharing a case study of my recent assignment on how moving away from Scrum and embracing Kanban, with the same spirit of empiricism, helped my team in improving delivery, as well as brought a sense of togetherness across dependent teams. Towards the end of the article, I shall share how small changes in teams’ ways of working can result into tangible and visible benefits. The intent is not to compare Scrum and Kanban — but to see how a combination of traits of both frameworks when supplemented by tools can provide immense value.

Transparency being one of the pillars of Empiricism, coming up with different ways to visualize the progress of a team have become an inherent need for all Agile teams. This empowers teams to see and assess the current state & pushes to think on what needs to be improved — holding onto the other two pillars of empiricism — Inspection and Adaptation. This has largely benefitted teams in identifying issues and bottlenecks faster, resulting into early resolution of impediments helping into reducing the “Cost of Delay”.

Scrum upholds the pillar of transparency and empowers teams by providing many tools to use within its framework. However, not all teams can best fit into the Scrum ways of working.

For all of us to be on the same page, let me give a quick brief about Scrum and Kanban

Scrum is a framework for developing, delivering, and sustaining complex products. It employs an iterative, incremental approach to optimize predictability and control risk.

The Scrum framework consists of Scrum Teams and their associated roles, events, artifacts, and rules. Roles are namely — the Product Owner, Scrum Master and Development team; Events are the Sprint Planning, Daily Scrum, Sprint Review followed by the Sprint Retrospective. The artifacts are namely the Product Backlog — owned by the Product Owner, The Sprint Backlog and Increment — owned by the Development Team. Here, the Scrum Master owns the process. The heart of Scrum lies in small teams and the concept of Timeboxing. If you are new to Scrum, reading the Scrum Guide will definitely help.

Coming to Kanban, It is a visual system for managing work as it moves through a process. Kanban visualizes both the process (the workflow) and the actual work passing through that process. The goal of Kanban is to identify potential bottlenecks in your process and fix them so work can flow through it cost-effectively at an optimal speed or throughput. The heart of Kanban is “Continuous Flow”. It does not specify about time-boxing or any specific roles. It is believed that we can start with Kanban immediately, provided we already have a process in place. There are 6 practices of the Kanban method namely –

1. Visualizing the flow of work

2. Limiting Work in Progress

3. Managing the flow

4. Making Policies explicit

5. Implement Feedback loops

6. Improve collaboratively, Evolve experimentally

These practices, if neatly applied, Kanban can help deliver faster.

Moving ahead with my recent experience, being a Scrum Master for a Deployment solutions team was a learning experience where the expectations from me were to manage multiple stakeholders, facilitate scope management in addition to coaching the team planning & forecasting methods. This team was primarily responsible for :

• Delivering automated solutions and services to the Development and IT teams

• Researching on new solutions and tools which can be rolled across the organization

Looking back to my initial days in the team, the routine was really chaotic, and the direction and vision was unclear to the team. This resulted in:

• Everybody being too busy, but no work seemed to be completed.

• Each engineer having a different understanding of the definition of done.

• Zero documentation — requirements were normally shared in daily stand-ups.

• Mismatch of expectation due to unorganized communication within & across teams contributing to never-ending work.

• Research initiatives either took humungous amount of time or the closure never happened due to cross team dependencies.

However, there were multiple strengths within the group of individuals which could be leveraged to form a team. Some of the indicators were:

• Multi-Skilled individuals

• Can-do attitude of engineers even under pressure

• Tech leads were cooperative and open for feedback

• Willingness to research and adopt newer DevOps tools and practices

• Team was welcoming Agile adoption

After assessing the performance of the team for a few weeks, a retrospective session was held to share all observations and possible action items to change existing ways of working. The DevOps Engineers were virtually divided into 3 streams, namely Continuous Integration, Continuous Deployment, and Continuous Monitoring with one lead in each stream.

Scrum mode on!

Teams agreed to welcome Scrum with an optimistic intent which would result into:

• Stabilization of the inflow of requirements as agreed in Sprint Planning event

• Predictability for a week and focused work based on team’s estimation

• Sprint Review to compare actuals with planned items

Sprint Cadence was set in a way so that the team gets maximum development time with less distractions. Many key changes were done in the team such as — Leads acted as Product Owners, JIRA Scrum Boards were used to track progress, multiple training sessions were held for the team, estimation started & appropriate closure at the end of every week with review and retrospective sessions. Team started making tasks visible, things were getting done, a sense of accomplishment arrived.

However, some issues continued over a quarter such as:

• Ad-hoc high priority requests within sprints

• Missing the targeted scope as IT dependencies identified later in the sprint

• Monolithic pull requests — review and merge used to take more time than usual

• Requirement detailing was weak due to Tech Lead turning into a PO

Time for a team offsite — resulting into embracing Kanban

Team offsite is always beneficial to bring in positive changes in the team. This also invites time to open up minds as part of a bigger retrospective. Practicing Scrum helped the team in identifying strengths to leverage within the team and shortcomings to resolve. Time boxing helped in creating some discipline within the team; however, it was a challenge to formulate a goal for the team each Sprint due to the nature of inflow of work and the need to address adhoc requests.

Hence, resulting into the idea of trying out Kanban with the beneficial habits inherited from Scrum. So, we went with Kanbanizing Scrum.

This is the phase where we made changes to our practices, current ways of working by giving up on Time boxing & embracing the key Kanban practices. Some of the key highlights of the changes in practices were:

• Planning and Review — Weekly Planning and Review sessions were time-boxed to 1 hour & 30 mins each with the entire team’s participation. Review sessions were majorly to assess the progress and understand situations on why items could not be completed.

• Backlog Refinement — Team Leads fortnightly reviewed and refined the backlog to add description to the upcoming requirements. This being a collective activity for the three Leads, helped them to figure out dependencies and accordingly assign correct prioritization for team to voluntarily pull items to working scope.

• WIP (Work in Progress) limits — Defining WIP limits in the “In Progress” and “In Review” columns helped the team to stay focused. The natural tendency of multi-tasking has slowed down significantly.

• Defining Done — Definition of Done (DoD) was formalized for the team where an item was considered Done only after a Pull Request (PR) was merged to the Master branch & a round of review was conducted. Before a PR is merged, code changes were to be reviewed and approved by at least 2 team members which takes care of the quality requirements.

• Changes in JIRA workflow: The initial JIRA workflow was updated to include states which helps in categorizing the actual progress and state. These changes helped in increased usage of the Kanban board as the team found it easier to drag and drop tickets to appropriate status. Also, dependencies were much clearer for teams to highlight and callout for help.

• Making use of large screen: Visual Stand-ups helped team to daily go through the planned backlog and re-prioritize items as necessary. Blockers were identified by looking at the board and intra team dependencies were resolved immediately. Scrum Master used to facilitate the inter-team dependencies and IT blockers.

• Introducing Metrics: Scrum Master continued to share weekly metrics with the team which includes — Throughput, Avg. Cycle time, Cumulative Flow diagram and Flow Efficiency. Flow efficiency resulted into highlighting the process overhead as compared to the effort required.

• Including IT Engineers in stand-ups: Based on the Flow efficiency & Cycle Time metrics shared, a mutual agreement was set with the IT team that a point of contact would join the stand-ups to note and share progress of any IT dependencies. This led to much faster closure of IT tickets.

We might still have a question on what could have been the Key Benefits of this change. The answer lies next -

These changes were impactful and resulted into major qualitative and quantitative benefits for the teams and the organization -

• A much happier, motivated and self-organized team with engineers from DevOps, Development and ITOps

• Average wait time of IT tickets resolution dropped from 23 days to 8 days and then to 3 days over a period of 7 months.

• Flow Efficiency increased from 18% to 39% to 62% over 7 months.

Nelson Mendela once said, “Education is the most powerful weapon which you can use to change the world.”

In the Agile world of Software development, Transparency is the weapon towards educating teams and the organization. Use of Kanban with custom ways of working enables transparency, which results into identification and implementation of positive changes towards continuous improvement and faster delivery.

If carefully observed, all changes we made while working on Kanban resulted into making things more transparent for the team and other stakeholders. Each small change went through more than a couple of iterations of careful review and intense discussion before being implemented. Impact of changes may not be very apparent right away, but we should remember that every cloud has a silver lining.

As a Scrum Master/Facilitator/Coach, what had helped me in the journey was my continuous interrogation to self — “Am I seeing the real picture of the team or it is just what is being shown?” and the quest to find the response by making things as visible as possible.

Always be transparent! Transparency builds Trust & Trust accelerates Success!