Written by How do you use Kanban in the Scaled Agile Framework for the development teams? Now you might have seen Kanban at various levels at the portfolio level, program level at those levels; Kanban is more used to refine their portfolio backlog and program backlog. Still, at a development team level, Kanban is used to facilitate the complete development process.
Now, most of us are familiar with scrum, and we know that we use scrum for developing complexes, perhaps, and when you are going into a considerable scale development. So you realize that to support the full product, maybe some teams can benefit from using Kanban.
In my observation, I see the teams that provide either a foundation to other groups or work as integrators of other team components may benefit from using Kanban. I am not at all recommending that they have to use Kanban. But if we see that the team finds it difficult to predict their work for two weeks, for a sprint duration. As their work is dependent on other team’s events, if the other team faces some issue or is struck for some clarification, the teamwork is impacted, and it’s difficult for them to predict the depth of the job with certainty for two weeks.
In those cases, they may start using a flow-based system that supports other teams to achieve their sprint objectives.
So it’s like this in a 7-8 team, you may have, say, five teams using scrum and two teams using Kanban, and if they end up in those situations, how do you operate in that context in the Scaled Agile framework. So we explore that further now a little bit on Kanban as understood across is more about visualizing work and workflow.
In a Kanban space, we create various workflow stages that help us see how the work moves from one step to another. The Kanban system also establishes a pull mechanism by which it’s not necessarily a one person to assign work to other people. So the visualization of the amount of work and inflow can make people act. They can set their work as they find a capacity. So this is often seen with the help of some Kanban cards, or you can use stickiness notes for here, and Kanban may also have their team backlog.
In simple words, when we are talking about the Scaled Agile framework context, when you go for your program increment meeting for PI boundaries once in ten weeks, the Kanban team also creates their team backlog in that particular meeting. The Kanban team’s backlog may emerge more as things evolve, but they do have something that they plan in their team backlog during the initial stage. On top of it, maybe every week they look at their team backlog and plan things for a given week, so this is something they can do every week, this is something they can do daily, or on a three-week basis, the idea is that the flexibility. They can maintain and not necessarily plan their work for every two weeks. It may happen they plan some work items that are a little bit long-term development-oriented. They arrange it for two weeks, but the other thing keeps emerging based on the demand of other teams.
They keep planning based on flexibility to take and visualize things as they go through various stages. So it is just an example; it’s not like a recommendation that you need to have settings like this. As many steps make sense, we create those stages and see how things move till an acceptance stage to keep things moving the way Kanban promotes across the safe Kanban. The team also focuses on limiting work-in-progress at each stage many times.
Sometimes they also limit the overall work in progress at a given workflow level. To optimize things further—many Kanban teams in SAFe use a class of services to identify tasks to be picked up early. Some items are in a fixed state-based now. For example, if you have committed something in your PI planning meeting and that other team needs that particular feature to deliver their commitment, you may have fixed date-type work items. So you may also apply the selected date type of work items now. What is the difference between a Kanban team? You may have a work item that may get started on week one, and it may finish on the three or week four.
So you don’t have to split the items in two and make it fit into a two weeks sprint or two weeks iteration. The scrum teams in SAFe will end up doing that. They will have all items they start developing, and that item would fix into two weeks boundaries. But the Kanban team may have that flexibility. They may not see splitting unnecessary items to make them fit into two weeks. It can just keep flowing and whenever it gets finished during the pi boundaries. So it achieves its objective even though it may use a fixed state class of service frequently. So rather than saying we are doing it in sprint 2, we can tell it will complete during sprint three. Kanban teams are now getting this type of flexibility. You can see across this kind of structure. In my personal experience, I find it helpful when you are picking up the work or providing services to other teams.
Now, this is something we looked at how a Kanban team can operate in SAFe. There are some constraints; the Kanban team on a SAFe still needs to follow the overall framework of the Scaled Agile framework. They are part of the release teams. They are not independent now to participate in the release teams. They still need to do planning and forecasting at a PI boundaries level. So typically the PI boundaries are 10 PI boundaries, so all scrum and Kanban teams participate in a PI planning meeting. They do forecast and commit their work for these Stanwick boundaries. The difference is the scrum teams will divide those commitments and their team backlog in a two to two weeks sprint. They will give a demo at the end of two weeks. Still, the Kanban team may keep working across this time, say ten weeks, but the ninth and 10th week is inspected. So I can say for the eight weeks, they may have things coming at a later stage. However, they still need to plan, and they need to commit to the overall boundary. They also need to participate in program-level events so the scrum teams, at the end of an iteration. They produce a demo, and this all work goes at a program level, and you produce a system demo.
How do you use Kanban in the Scaled Agile Framework for the development teams? Now you might have seen Kanban at various levels at the portfolio level, program level at those levels; Kanban is more used to refine their portfolio backlog and program backlog. Still, at a development team level, Kanban is used to facilitate the complete development process. Now, most of us are familiar with scrum, and we know that we use scrum for developing complexes, perhaps, and when you are going into a considerable scale development. So you realize that to support the full product, maybe some teams can benefit from using Kanban. In my observation, I see the teams that provide either a foundation to other groups or work as integrators of other team components may benefit from using Kanban. I am not at all recommending that they have to use Kanban. But if we see that the team finds it difficult to predict their work for two weeks, for a sprint duration. As their work is dependent on other team’s events, if the other team faces some issue or is struck for some clarification, the teamwork is impacted, and it’s difficult for them to predict the depth of the job with certainty for two weeks. In those cases, they may start using a flow-based system that supports other teams to achieve their sprint objectives. So it’s like this in a 7-8 team, you may have, say, five teams using scrum and two teams using Kanban, and if they end up in those situations, how do you operate in that context in the Scaled Agile framework. So we explore that further now a little bit on Kanban as understood across is more about visualizing work and workflow. In a Kanban space, we create various workflow stages that help us see how the work moves from one step to another. The Kanban system also establishes a pull mechanism by which it’s not necessarily a one person to assign work to other people. So the visualization of the amount of work and inflow can make people act. They can set their work as they find a capacity. So this is often seen with the help of some Kanban cards, or you can use stickiness notes for here, and Kanban may also have their team backlog. In simple words, when we are talking about the Scaled Agile framework context, when you go for your program increment meeting for PI boundaries once in ten weeks, the Kanban team also creates their team backlog in that particular meeting. The Kanban team’s backlog may emerge more as things evolve, but they do have something that they plan in their team backlog during the initial stage. On top of it, maybe every week they look at their team backlog and plan things for a given week, so this is something they can do every week, this is something they can do daily, or on a three-week basis, the idea is that the flexibility. They can maintain and not necessarily plan their work for every two weeks. It may happen they plan some work items that are a little bit long-term development-oriented. They arrange it for two weeks, but the other thing keeps emerging based on the demand of other teams. They keep planning based on flexibility to take and visualize things as they go through various stages. So it is just an example; it’s not like a recommendation that you need to have settings like this. As many steps make sense, we create those stages and see how things move till an acceptance stage to keep things moving the way Kanban promotes across the safe Kanban. The team also focuses on limiting work-in-progress at each stage many times. Sometimes they also limit the overall work in progress at a given workflow level. To optimize things further—many Kanban teams in SAFe use a class of services to identify tasks to be picked up early. Some items are in a fixed state-based now. For example, if you have committed something in your PI planning meeting and that other team needs that particular feature to deliver their commitment, you may have fixed date-type work items. So you may also apply the selected date type of work items now. What is the difference between a Kanban team? You may have a work item that may get started on week one, and it may finish on the three or week four. So you don’t have to split the items in two and make it fit into a two weeks sprint or two weeks iteration. The scrum teams in SAFe will end up doing that. They will have all items they start developing, and that item would fix into two weeks boundaries. But the Kanban team may have that flexibility. They may not see splitting unnecessary items to make them fit into two weeks. It can just keep flowing and whenever it gets finished during the pi boundaries. So it achieves its objective even though it may use a fixed state class of service frequently. So rather than saying we are doing it in sprint 2, we can tell it will complete during sprint three. Kanban teams are now getting this type of flexibility. You can see across this kind of structure. In my personal experience, I find it helpful when you are picking up the work or providing services to other teams. Now, this is something we looked at how a Kanban team can operate in SAFe. There are some constraints; the Kanban team on a SAFe still needs to follow the overall framework of the Scaled Agile framework. They are part of the release teams. They are not independent now to participate in the release teams. They still need to do planning and forecasting at a PI boundaries level. So typically the PI boundaries are 10 PI boundaries, so all scrum and Kanban teams participate in a PI planning meeting. They do forecast and commit their work for these Stanwick boundaries. The difference is the scrum teams will divide those commitments and their team backlog in a two to two weeks sprint. They will give a demo at the end of two weeks. Still, the Kanban team may keep working across this time, say ten weeks, but the ninth and 10th week is inspected. So I can say for the eight weeks, they may have things coming at a later stage. However, they still need to plan, and they need to commit to the overall boundary. They also need to participate in program-level events so the scrum teams, at the end of an iteration. They produce a demo, and this all work goes at a program level, and you produce a system demo. The Kanban teams also participate in the system demo. So their work also goes inside that particular two-week frequency system demo. So, all in all, the Kanban will also estimate their work item, and those estimations should be normalized with the scrum teams because, in a safe environment, we do have an aggregated velocity, aggregated forecasting, aggregate sizing of the complete release train. So we cannot leave a Kanban team as a different team that is not using estimation and not participating in the forecasting process. So that is a rule, or that is something a constraint applied on Kanban team rest. They do have flexibility in that window, and That is why we use them, or that is why the shield teams or the platform teams use the Kanban a lot.