More
CALL To Agility
To Know
-
Kanban Safari
Kanban - Agile is not only Scrum
CALL To Agility
—
Apr 2023
Three years ago, Agility Lab Team collaborated and helped the Celfocus Safaricom team to experiment with a new thing, let us call it "Kanban Safari", and until this day we can remember people's faces. This article tries to share the point of view from three roles, the Agile Coach, Analyst/Value Specialist and Delivery Manager. More roles in the team: a Scrum Master, an Operations SPOC, the Creators with cross-functional skills.
There are regular discussions about optimizing the workflow, but we do not talk as often about who should be doing that optimization. Should it be the manager, or some dedicated process specialist, or should it be leaving it up to the team to figure out their own workflow?
Spoiler: We should let the team figure it out.
First, the team is the closest to the work and has the most information available about how to optimize it. They may want access to a process specialist to help them understand options, but they have more knowledge of how the system works than any outsider will.
In his book “Turn the Ship Around”, David Marquet talks about moving authority to information so that the people who know the most can make the decisions that affect them.
Adding a little context, Celfocus had a contract with Safaricom, having a support team and a development team. At the beginning of 2022, the contract with Safaricom was renewed, re-shaping both streams, “development” and “operations” into a unified one. Safaricom and Celfocus Agility Lab collaborating since January, participating in the bootstrap sessions with our Agility Lab Team and being an active voice in the definition of the Team Agreements.
Requirements typically reach us from diverse sources: emailed by the PO, Safaricom Stakeholders, focus groups sessions (three sessions at the time), from the PO (Product Owner) during the Events (Planning and Refinement).
Along the bootstrap we learned that the Value Stream wasn’t clear, so the first experiment result is like(picture below):
PO likes to act as a bridge, centralizing all the information, consequently, it’s harder to get access and have effective discussions about Product Backlog Items with the stakeholders.
Main Challenges, from this behavior: Items blocked in the Upstream Flow (since customer request till “Ready” for the Team can start to work on it) for too long, in some cases, they even send the requirement having dependencies on their end. Other times the waiting time for clarifications from the business was too long, with an increase of the Cycle Time of the PBI item, then impacts the Lead Time of the project Milestones. Lack of engagement and planning from the Safaricom team for the UAT (User Acceptance Tests), delaying Time to Delivery.
Experiments: Unique Project Backlog, combining in ONE project view Operations and Development tasks. Stimulating good and honest communication, and transparency, fostering the perception that we are all working for a common goal, trust levels increased to excellent between PO and us, started to give us more access to the stakeholders, more feedback, clear project backlog items, improved the solution.
The analysis work is both a functional and a technical skill. We believe that this iterative refinement, supported by effective communication, makes us close to deliver what was expected from the clients.
Some challenges to this believe, documentation is on our end (JIRA Celfocus), low “maturity” in the new way of working Model from the Value Team, and lack of product Vision. Experiments: Full autonomy to manage the documentation and tasks, a draft of a project Roadmap for high-level overview and Safaricom stakeholder’s several initiatives and budget prioritization. These experiments Increased even more the relationship with the client.
Client trust in us is an outcome of the work that the Team has been doing, especially the colleagues who have been working with Safaricom for a long time.
In manufacturing processes, process and output variability is something we strive to remove. If we have a production line, we want every item out of that production line to come out in a very consistent manner and with little variability. However, this does not apply to complex uncertain work such as knowledge work. In these environments, variability is an inherent attribute. We strive to make our work items as small as possible.
I really like how Dan Vacanti talks about this in his scrum.org white paper “Little’s Law for Professional Scrum with Kanban”
“[…] more importantly, the variability in work item size is probably not the variability that is killing your predictability. Your bigger predictability problems are usually too much WIP, the frequency with which you violate Little’s Law’s assumptions.”
Adding my personal perspective, if Demand and Delivery Capacity aren't aligned, we start to see signals that create a system of “pushing” work to people, instead of “Pull”, creating invisible queues, everyone is 110% time busy, the dark side of this situation soon emerges, Lead time (the time that customer perceives is too much long, things get too much time to be delivered, we-work) customer unhappy, you know.
Also, Velocity alone doesn´t measure success. Not one single metric will, unfortunately. Success is more complicated than that and it can rarely, if ever, be measured with a single metric. Most teams and organizations do not just want to deliver things. They want to deliver excellent quality things and deliver them quickly on top of consistently delivering things. Wanting to succeed, let us start accepting uncertainty.
"Improve Flow Be Predictable" is a vision from Kanban experts actionable agile, to provide accurate forecasts that answer our customer's most important question: When will it be done?
What does this mean in fact?
Jira instance (used by the project to visualize and monitor project work) was configured with additional settings to collect "start time" and "end time" in each work Item at every workflow step. This data is then exported to a “forecaster tool”. Data are collected from the Upstream & Downstream kanban boards, and the team started to use and track some key Flow metrics:
Cycle Time -75% of our Work items take less than 24 days!
Throughput - 75% chance that the team can finish 8 or less Work items per week.
We can increase the confidence intervals and include more outliers and have “more predictability”, this was “good enough for now” to track performance and client engagement and happiness.
It has been a long and pleasant journey on all levels from Safaricom and Celfocus.
Practically, there is no such thing as applying 100% Scrum or Kanban in a delivery context.
We have been given the toolkit for doing “things” following patterns, but you always have to adapt to the customer’s context. And that’s what both teams did. We adapted… and we will continue adapting. That’s the magic of any delivery methodology. Challenges are infinite…
We don’t dare to think that “ok now we are doing great, we control everything...” At any point in time, something will happen that will force you to adapt again… And that is ok still. As long as you don’t “destroy” the teamwork agreements and the theory basics, it will still work.
Three years ago, Agility Lab Team collaborated and helped the Celfocus Safaricom team to experiment with a new thing, let us call it "Kanban Safari", and until this day we can remember people's faces. This article tries to share the point of view from three roles, the Agile Coach, Analyst/Value Specialist and Delivery Manager. More roles in the team: a Scrum Master, an Operations SPOC, the Creators with cross-functional skills.
There are regular discussions about optimizing the workflow, but we do not talk as often about who should be doing that optimization. Should it be the manager, or some dedicated process specialist, or should it be leaving it up to the team to figure out their own workflow?
Spoiler: We should let the team figure it out.
First, the team is the closest to the work and has the most information available about how to optimize it. They may want access to a process specialist to help them understand options, but they have more knowledge of how the system works than any outsider will.
In his book “Turn the Ship Around”, David Marquet talks about moving authority to information so that the people who know the most can make the decisions that affect them.
Adding a little context, Celfocus had a contract with Safaricom, having a support team and a development team. At the beginning of 2022, the contract with Safaricom was renewed, re-shaping both streams, “development” and “operations” into a unified one. Safaricom and Celfocus Agility Lab collaborating since January, participating in the bootstrap sessions with our Agility Lab Team and being an active voice in the definition of the Team Agreements.
Requirements typically reach us from diverse sources: emailed by the PO, Safaricom Stakeholders, focus groups sessions (three sessions at the time), from the PO (Product Owner) during the Events (Planning and Refinement).
Along the bootstrap we learned that the Value Stream wasn’t clear, so the first experiment result is like(picture below):
PO likes to act as a bridge, centralizing all the information, consequently, it’s harder to get access and have effective discussions about Product Backlog Items with the stakeholders.
Main Challenges, from this behavior: Items blocked in the Upstream Flow (since customer request till “Ready” for the Team can start to work on it) for too long, in some cases, they even send the requirement having dependencies on their end. Other times the waiting time for clarifications from the business was too long, with an increase of the Cycle Time of the PBI item, then impacts the Lead Time of the project Milestones. Lack of engagement and planning from the Safaricom team for the UAT (User Acceptance Tests), delaying Time to Delivery.
Experiments: Unique Project Backlog, combining in ONE project view Operations and Development tasks. Stimulating good and honest communication, and transparency, fostering the perception that we are all working for a common goal, trust levels increased to excellent between PO and us, started to give us more access to the stakeholders, more feedback, clear project backlog items, improved the solution.
The analysis work is both a functional and a technical skill. We believe that this iterative refinement, supported by effective communication, makes us close to deliver what was expected from the clients.
Some challenges to this believe, documentation is on our end (JIRA Celfocus), low “maturity” in the new way of working Model from the Value Team, and lack of product Vision. Experiments: Full autonomy to manage the documentation and tasks, a draft of a project Roadmap for high-level overview and Safaricom stakeholder’s several initiatives and budget prioritization. These experiments Increased even more the relationship with the client.
Client trust in us is an outcome of the work that the Team has been doing, especially the colleagues who have been working with Safaricom for a long time.
In manufacturing processes, process and output variability is something we strive to remove. If we have a production line, we want every item out of that production line to come out in a very consistent manner and with little variability. However, this does not apply to complex uncertain work such as knowledge work. In these environments, variability is an inherent attribute. We strive to make our work items as small as possible.
I really like how Dan Vacanti talks about this in his scrum.org white paper “Little’s Law for Professional Scrum with Kanban”
“[…] more importantly, the variability in work item size is probably not the variability that is killing your predictability. Your bigger predictability problems are usually too much WIP, the frequency with which you violate Little’s Law’s assumptions.”
Adding my personal perspective, if Demand and Delivery Capacity aren't aligned, we start to see signals that create a system of “pushing” work to people, instead of “Pull”, creating invisible queues, everyone is 110% time busy, the dark side of this situation soon emerges, Lead time (the time that customer perceives is too much long, things get too much time to be delivered, we-work) customer unhappy, you know.
Also, Velocity alone doesn´t measure success. Not one single metric will, unfortunately. Success is more complicated than that and it can rarely, if ever, be measured with a single metric. Most teams and organizations do not just want to deliver things. They want to deliver excellent quality things and deliver them quickly on top of consistently delivering things. Wanting to succeed, let us start accepting uncertainty.
"Improve Flow Be Predictable" is a vision from Kanban experts actionable agile, to provide accurate forecasts that answer our customer's most important question: When will it be done?
What does this mean in fact?
Jira instance (used by the project to visualize and monitor project work) was configured with additional settings to collect "start time" and "end time" in each work Item at every workflow step. This data is then exported to a “forecaster tool”. Data are collected from the Upstream & Downstream kanban boards, and the team started to use and track some key Flow metrics:
Cycle Time -75% of our Work items take less than 24 days!
Throughput - 75% chance that the team can finish 8 or less Work items per week.
We can increase the confidence intervals and include more outliers and have “more predictability”, this was “good enough for now” to track performance and client engagement and happiness.
It has been a long and pleasant journey on all levels from Safaricom and Celfocus.
Practically, there is no such thing as applying 100% Scrum or Kanban in a delivery context.
We have been given the toolkit for doing “things” following patterns, but you always have to adapt to the customer’s context. And that’s what both teams did. We adapted… and we will continue adapting. That’s the magic of any delivery methodology. Challenges are infinite…
We don’t dare to think that “ok now we are doing great, we control everything...” At any point in time, something will happen that will force you to adapt again… And that is ok still. As long as you don’t “destroy” the teamwork agreements and the theory basics, it will still work.
Three years ago, Agility Lab Team collaborated and helped the Celfocus Safaricom team to experiment with a new thing, let us call it "Kanban Safari", and until this day we can remember people's faces. This article tries to share the point of view from three roles, the Agile Coach, Analyst/Value Specialist and Delivery Manager. More roles in the team: a Scrum Master, an Operations SPOC, the Creators with cross-functional skills.
There are regular discussions about optimizing the workflow, but we do not talk as often about who should be doing that optimization. Should it be the manager, or some dedicated process specialist, or should it be leaving it up to the team to figure out their own workflow?
Spoiler: We should let the team figure it out.
First, the team is the closest to the work and has the most information available about how to optimize it. They may want access to a process specialist to help them understand options, but they have more knowledge of how the system works than any outsider will.
In his book “Turn the Ship Around”, David Marquet talks about moving authority to information so that the people who know the most can make the decisions that affect them.
Adding a little context, Celfocus had a contract with Safaricom, having a support team and a development team. At the beginning of 2022, the contract with Safaricom was renewed, re-shaping both streams, “development” and “operations” into a unified one. Safaricom and Celfocus Agility Lab collaborating since January, participating in the bootstrap sessions with our Agility Lab Team and being an active voice in the definition of the Team Agreements.
Requirements typically reach us from diverse sources: emailed by the PO, Safaricom Stakeholders, focus groups sessions (three sessions at the time), from the PO (Product Owner) during the Events (Planning and Refinement).
Along the bootstrap we learned that the Value Stream wasn’t clear, so the first experiment result is like(picture below):
PO likes to act as a bridge, centralizing all the information, consequently, it’s harder to get access and have effective discussions about Product Backlog Items with the stakeholders.
Main Challenges, from this behavior: Items blocked in the Upstream Flow (since customer request till “Ready” for the Team can start to work on it) for too long, in some cases, they even send the requirement having dependencies on their end. Other times the waiting time for clarifications from the business was too long, with an increase of the Cycle Time of the PBI item, then impacts the Lead Time of the project Milestones. Lack of engagement and planning from the Safaricom team for the UAT (User Acceptance Tests), delaying Time to Delivery.
Experiments: Unique Project Backlog, combining in ONE project view Operations and Development tasks. Stimulating good and honest communication, and transparency, fostering the perception that we are all working for a common goal, trust levels increased to excellent between PO and us, started to give us more access to the stakeholders, more feedback, clear project backlog items, improved the solution.
The analysis work is both a functional and a technical skill. We believe that this iterative refinement, supported by effective communication, makes us close to deliver what was expected from the clients.
Some challenges to this believe, documentation is on our end (JIRA Celfocus), low “maturity” in the new way of working Model from the Value Team, and lack of product Vision. Experiments: Full autonomy to manage the documentation and tasks, a draft of a project Roadmap for high-level overview and Safaricom stakeholder’s several initiatives and budget prioritization. These experiments Increased even more the relationship with the client.
Client trust in us is an outcome of the work that the Team has been doing, especially the colleagues who have been working with Safaricom for a long time.
In manufacturing processes, process and output variability is something we strive to remove. If we have a production line, we want every item out of that production line to come out in a very consistent manner and with little variability. However, this does not apply to complex uncertain work such as knowledge work. In these environments, variability is an inherent attribute. We strive to make our work items as small as possible.
I really like how Dan Vacanti talks about this in his scrum.org white paper “Little’s Law for Professional Scrum with Kanban”
“[…] more importantly, the variability in work item size is probably not the variability that is killing your predictability. Your bigger predictability problems are usually too much WIP, the frequency with which you violate Little’s Law’s assumptions.”
Adding my personal perspective, if Demand and Delivery Capacity aren't aligned, we start to see signals that create a system of “pushing” work to people, instead of “Pull”, creating invisible queues, everyone is 110% time busy, the dark side of this situation soon emerges, Lead time (the time that customer perceives is too much long, things get too much time to be delivered, we-work) customer unhappy, you know.
Also, Velocity alone doesn´t measure success. Not one single metric will, unfortunately. Success is more complicated than that and it can rarely, if ever, be measured with a single metric. Most teams and organizations do not just want to deliver things. They want to deliver excellent quality things and deliver them quickly on top of consistently delivering things. Wanting to succeed, let us start accepting uncertainty.
"Improve Flow Be Predictable" is a vision from Kanban experts actionable agile, to provide accurate forecasts that answer our customer's most important question: When will it be done?
What does this mean in fact?
Jira instance (used by the project to visualize and monitor project work) was configured with additional settings to collect "start time" and "end time" in each work Item at every workflow step. This data is then exported to a “forecaster tool”. Data are collected from the Upstream & Downstream kanban boards, and the team started to use and track some key Flow metrics:
Cycle Time -75% of our Work items take less than 24 days!
Throughput - 75% chance that the team can finish 8 or less Work items per week.
We can increase the confidence intervals and include more outliers and have “more predictability”, this was “good enough for now” to track performance and client engagement and happiness.
It has been a long and pleasant journey on all levels from Safaricom and Celfocus.
Practically, there is no such thing as applying 100% Scrum or Kanban in a delivery context.
We have been given the toolkit for doing “things” following patterns, but you always have to adapt to the customer’s context. And that’s what both teams did. We adapted… and we will continue adapting. That’s the magic of any delivery methodology. Challenges are infinite…
We don’t dare to think that “ok now we are doing great, we control everything...” At any point in time, something will happen that will force you to adapt again… And that is ok still. As long as you don’t “destroy” the teamwork agreements and the theory basics, it will still work.
.png)
