Last week I gave a deep dive workshop in the Agile Games New England conference about the NEED for engagement and participation when implementing agile at scale using an approach like SAFe as well as how I use online games like Kahoot and Socrative and various points throughout the implementation to increase engagement and participation especially when working with big groups beyond the team. Here’s my slide deck from the talk:
The day has come for FLOWer to bloom (maybe we should call it “Hatzav” (maritime squeel) after the flower that brings the autumn here in israel… btw we are in the middle of october and it feels like July, can’t wait for the Vienna weather next week in Lean Kanban Central Europe 2012 – you’ve got your tickets already, right?)
A couple of months ago I’ve written about experiencing Kanban system design and if you’ve been waiting to see what I’m talking about, today AgileSparks is soft launching FLOWer. Well, at least an initial version of it focused on experiencing the effects of WIP on flow and ROI/Profit of the business. You are welcome to go try FLOWer now.
A couple of notes about the beta:
- Starting the simulator and seeing it in action doesn’t require any registration. Just open it and kick the wheels. Tweaking the settings requires registration which is currently done by simply associating your google account. We are assuming most people have a google account. We only keep your emails so we can be in touch, we don’t do anything else with your data.
- We are currently in beta mode which means we limit the amount of users registered to the system. Hurry up and register. First come first serve.
- We are still figuring out the pricing model. You can leverage that and enjoy it free at the moment. And we will make sure we take good care of early adopters that help us shape up the product.
- We are trying to make the simulator and the game self-explanatory. We’re probably not there yet, so please comment or leave feedback on the site itself with anything that wasn’t clear, didn’t work as you expected, or points you just felt stuck at.
- The simulator will run on any modern HTML5 browser. Chrome, Firefox, Safari… iPad Chrome/Safari… But that also means IE is NOT SUPPORTED.
So, what are you waiting for? Go ahead and play! (Sorry, we didn’t include a Boss Key… but maybe your boss would also like to see how intelligent context-specific and adaptive application of Stop Starting Start Finishing is a way to bring home more Benjamins!)
One of the approaches I’ve been using lately with clients is starting with whole system Kanban, focusing on Discovery and Delivery, and then potentially zoom into Team Agile in some/all streams as the organization understands the concepts of Flow, Stop Starting Start Finishing, Inspect and Adapt etc. It IS typically necessary to go to smaller batches earlier on so I recommend setting up Lean/Agile Discovery processes that pull market/product demand and create Features, MMFs and Stories from it.
I want to quickly share a Kanban exercise I ran today in a workshop focused on this approach. The organization decided to indeed start with a Kanban system and
I won’t go into too many details, but if I see there is interest I might blog more about it, or write a chapter in the upcoming book.
The first exercise I ran today was Jesper Boeg’s HairDresser.dk Story Mapping Exercise. I followed his exercise with a discussion and short exercise for how the Story Map would translate into a Discovery/Delivery Kanban System, and how it might look like in several points along the development life cycle.
This setup the basic building blocks for creating the real kanban network of the organization.
We identified the product streams – 5 real Product streams driven by Product Management, with an additional stream covering R&D housekeeping, Research, Automation, etc.
We then split into small groups, each covering one of the streams – with the real PM of that stream as well as actual people that will probably be involved in working that stream day to day.
We then Visualized the work – at the level of Features currently in the various stages of the Stream – Backlog, Analysis, Implementation, Ready to be Released, etc.
Now it becomes interesting. Each Feature in a stream might require work from several different technological teams (4-5 of them). We gave a color to each technology team/stream and each group marked each Feature with the technology streams that were involved. We played with various expand/collapse patterns when trying to visualize the flow of these technology aspects of the Features, and discussed whether that visibility was required for a Product Stream interest level or not.
Then we took a step back, and went Small Batches. We took a couple of Features and sliced them to Minimally Marketable Features and then User Stories. Since we still have technology teams we still had to slice the stories to technological aspects, but at a much smaller batch size which will provide much faster/earlier integration/testing and faster cycle times. All of this still without going Feature Teams. The value of Flow/Pull without Iterations in this model is clear – there is no unnecessary wait between the time a Team finishes its “Team Story” until Integration can happen or Testing can pull.
We then visualized the Technological Team Stories and had another discussion about visualization patterns.
Next step was zooming into Technology Team Boards. It was simply a matter of collecting all the colored cards from the different Product Stream boards and representing them on a single Team Board for each Technology Stream. We are not even sure those Boards will be used at the team level up front. We might start with a Kanban system used by the people involved at the work management (PMs, R&D Managers/Leaders) to learn the ropes of the system and then extend its usage.
We also discussed priorities between Product Streams and the R&D internal streams. The understanding that allocating WIP to each stream and creating a Weighted-Fair-Queuing system based on that was very important. Senior managers in the room felt that this would make it much easier to meet the portfolio allocations the organization decided on. By default when work for a stream is finished it would mean pulling a new card from that stream. But there is still the flexibility to deal with struggling items by optimizing globally across Product Streams.
Another board level is the “Big Picture” board where the MMFs from each of the Product Stream boards will be represented.
The exercise brought to life the complexity of the organization’s network but highlighted how a Kanban system can simplify its operation as well as drive towards improvement. There were several A-Ha moments of understanding how Limited WIP would solve systemic problems currently haunting the organization.
It also highlighted how creating Feature Teams allocated to a Product Stream would make life easier from a coordination perspective. This gives the organization incentive to try some form of Feature Team approach when the time is right.
The fact that we exercised all this using real work of the organization, real teams, discussed real problems of starvation, one technology team being the bottleneck, how overall WIP limits might affect that, etc. was a great way to understand what an organization-wide Kanban system is all about.
I wanted to share an exercise I created in a workshop last week
One of the topics we wanted to explore was the responsibilities/activities of Product Owners and the Agile Team and how do they relate.
The objective of the exercise was to understand the various activities and how they map in the continuum between PO and Team and across the product development life cycle.
The steps of the exercise are the following:
- Map all the activities related to the life cycle – typically this will be the lifecycle of a Feature. I came with a set of predefined steps but I think it can be useful to let the participants come up with the activities as a digesting activity.
- Where does each activity lie in the lifecycle? Use horizontal team estimation game – this means coming up with a continuum of activities where starting point is to the left side, ending point is to the right side (to be compatible with a typical Kanban Story Board)
- divide the time continuum to a couple of key phases (this can be used to be a starting point for a Kanban board btw, or you can use the existing kanban board the team uses if applicable )
- Which activity is associated with Product, Which with R&D? Use vertical team estimation game to drive a consensus among the team. The meaning of vertical is that you don’t touch the left-right placement, just the top-bottom. Top should be solely Product, Bottom solely R&D. Identify a middle area where work is done in collaboration. Even within that area it makes sense to discuss who is “leading” the activity.
- Debrief – Have a discussion about what this means, what are the surprises, does this make sense, what you would like to experiment with.
This exercise can of course be generalized to any interface between groups – Dev-Ops, Dev-Test, and outside of Product Development altogether… I’ll be glad to hear about interesting uses of the exercise.
A possible activity list (provided AS IS, no warranty attached… ;-):
- Decide how much to pull into sprint
- Estimate effort for stories
- Write ATDD Scenarios
- Estimate effort for MMFs
- Write confirmation DoD for Stories
- Break MMF to Stories
- Decide which Stories should stay in the MMF
- Approve Test Plan for Story
- Approve Test Plan for MMF
- Decide how much to pull into Release
- Decide which MMFs get priority
- Commit to delivery date of an MMF
- Decide delivery date of a Release
- Prioritize MMFs
- Break Feature to MMFs
- Guide UX Design
- Break PRD to Features
- Accept/Reject Stories
At Agilesparks we’ve recently been using the Kanban Board Game developed by Russell Heally (@getkanban) quite extensively. We use it as part of Kanban courses, sessions for Scrum teams that want to learn about Kanban, Kanban teams that are already working and want to raise their game, as well as in Kaizen sessions for project management teams.
We love what the game does, and it has actually become a challenge to coordinate which of us has the game kits at any point in time, especially because in large events we need 4 kits so we need to borrow from one of our nice clients that has 2 kits as well…
One idea we’ve been toying with for some time, is that it would be great to use something like this game to accelerate learning of Scrum as well. At a minimum, one of the questions I’m adding to the debrief for Scrum teams, is how would Scrum look like in this game, and what would be the effects. It seems clear to teams that Scrum would reduce throughput due to the need to clean the board every sprint, which means less ability to take advantage of the speciality of the Analysts/Developers/Testers. It would also make the game run slower due to the overhead of planning…
I’ve been reading some ideas from David Anderson and Russell about this, which helped me along. I’ll provide my take on this, but first a brief overview of the game to those not familiar with it.
The game simulates a process workflow where there is a stack (backlog) of cards which represent stories for development. The cards are pulled into a READY area, then pulled into Analysis, Development, Testing and finally deployed. There are different types of cards representing different work types/classes of service – a normal business value card, a fixed date card, a quality card, and an expedite card. Each card specifies the amount of work required to process it in each station, which provides the variability between work items so typical of product development and other knowledge creation areas. Another form of variability is the fact that how much work you are able to do each day is decided by throwing dice. You have dice in different colors that represent specialists in each area (Analysts, Developers, Testers), and you as the team playing the board can decide where to use each dice each day. Either use it in the specialty area of that person and gain a multiplier, or use it elsewhere without a multiplier. The game is played in cycles of days – each day you decide your strategy, throw the dice, play the game, update visibility charts, and also handle an event that might throw you some additional curve balls… That should suffice as a quick intro to understand the rest of the post, or at least as a teaser to find the opportunity to play the game. It really is highly recommended to anyone interested in Agile / Kanban / Scrum / Games. Exceptional work by Russell.
If you noticed so far, the game indeed simulates kanban. No time-boxes or batches, just flow and flow and flow. The only area where you get some sort of sprint behaviour is towards the end of the game. If you are approaching the end of the game and the teams know its coming, they will start to prefer cleaning the board and deploying items, rather than maintaining flow. That makes sense. If you announce end of the game on day 24 for example, but finish it a few days early without telling the teams, you will get flow behavior all the way to the end. You can play with that, depending what you want the teams to experience, and whether you want to have the timebox behavior as a pattern to discuss in the debriefing.
In general, it shouldn’t be too hard to make the adaptation of the whole game to timeboxes/sprints. maybe the biggest challenge is to have teams see the name Kanban on their new shiny Scrum process training 😉
But seriously, the main thing you need to take care of is the sprints. The concept of 3 day billing cycles in the game can be extended to portray a sprint. You would start the cycle with planning what cards you will work on in the cycle. This requires looking at your velocity in the last cycle, your capacity (cubes and statistics…) thinking about changes that were made in the environment (Carlos etc.), and the cards that are currently in the backlog. You would commit to what cards you plan to deliver.
Which gets us to the backlog… The trivial option is to make the READY area the backlog, and only pull into the READY area (into the board actually) cards that fit into the planning. This is not perfect though. For starters, how do we model the work that is done by the Product Owner? In addition, the whole flow from READY through analysis, development, testing might be a bit too long for a 3 day cycle.
That brings me to an alternative I’ve been thinking about – make the Analysis phase the work of a “Product Owner”. Use the analyst dice to represent the Product Owner, and the “Analysis Done” area the “Sprint Ready” backlog the teams can use for their planning.
This has the benefit of portraying the Product Owner work, it reduces the cycle time within a sprint which I think will provide a more reasonable simulation within a 3 days cycle, and can also bring about a discussion of the wastes of too much sprint ready backlog, versus a team that runs dry during a sprint. (Which is one of the common problems with Scrum teams, and a big benefit of doing this game with them I think)
So assuming the Analysis Done was the sprint candidate/ready backlog, the team does planning, pulls the planned stories into another queue between Analysis Done and Development in progress, which we can call – the Sprint Backlog
A sprint will be 3 days where the team works to finish and deploy all the cards in the Sprint Backlog – processing them through Development and Testing. Within this sprint the team also needs to take care to replenish the “Sprint Candidate/Ready Backlog”, because remember at the end of the cycle, there is another Sprint Planning, where they will need to have enough candidate cards that they can pull into the Sprint Backlog, to avoid starvation in the sprint. To properly simulate a real Scrum environment, it shouldn’t be allowed to pull cards within a sprint, because it is harder to plan within a sprint.
For advanced uses and for those Scrum people which are crying this is not fair, we can discuss a couple of options. One option is to allow pulling stories, while paying a fine for it to represent the cost of replanning. For example, you can put one of the dice on planning a story instead of executing it. Another option is to allow pulling quality cards during a sprint.
In general btw, we need to think how to portray the cost of planning. In a typical stable Scrum team, there is a cost of about 2-3 hours of planning per a 10 day sprint. This is about 4% which should be negligible in the game. Another option is to just compare the time it takes to do rounds of flow versus timeboxed rounds in the game and see what is the actual time it takes to run the game… I would expect flow to run much faster than the time-boxed version… but need to try it!
At the end of a sprint, what would happen is that you expect to have clean Sprint Backlog, Development and Testing stations, with all the cards deployed already. Any work that is not completed will probably be continued into the next timebox and should be included in the plans. I’m thinking a fine should be included here – every card that spills to another timebox should have a few points of work added to it (e.g. if there are 12 development points, the team finishes with 6 points of work left, in the new timebox there will be 6+3 points of work)
What would happen to Cycle Times? I’m quite sure cycle times will be much higher for a team doing timeboxes. The need to keep a queue of work ready for sprints will probably add about 2-4 days of cycle time, depending on how the team balances safety of having spare stories, versus the waste of having a story decay in the queue. Since the game doesn’t model a price for decaying stories, I assume teams will prefer more in the queue. The only thing that will stop them from doing that is limited amount of analysts… need to try it but I’m guessing there is a chance that the analyst will not be able to keep up, or at least we need to create scenarios that impede him from keeping up (e.g. blockers in analysis, reduced capacity of analysts, or taking stories that were analysed and cancelling them so now analysts have to rush to replenish the ready stories queue)
The event cards are another area which might need tweaking. For one, some events are unfair to introduce in the middle of a timebox because the team should know about them when planning. Need to look at them and align them with the timeboxes as necessary. Beyond that, some new kinds of events can be leveraged to spice up the timeboxes game (see above for example)
Will the effect of time-boxes be realistic enough? The concern is that if the time-box is too short, it will be hard to deliver stories and run an effective time-box. Similar to what teams experience when the story size is too large for the sprint. Basically, need to play around with it and see… I think that by removing the Analysis from the sprint itself I reduce the chance of this happening, but maybe its not enough. Worst case can play with multipliers on the cubes some to make the team capacity higher compared to the work, or strengthen the effect of the quality cards…
The WIP limits go away in this variant I think. The WIP limit is the Sprint Backlog which is time-based, not station based. An advanced team can decide to use WIP limits on the stations to work more effectively, or we can re-introduce the WIP limits as an event card during the game. While on this matter, a question I usually ask teams in debriefing is what would happen if there wasn’t a WIP limit. The answer I hear is that they would probably start more work than they can finish, and throughput and earnings will go down. QED 🙂
I think this is enough for one post. Should give you ideas how to play with the Kanban game in a time-boxed manner. There are probably other aspects that need to be taken care of, but lets be agile about it folks…
I’m hoping to try this on my own, probably with the AgileSparks team, sometime soon, and report. In the meantime, any comments or ideas are welcome.
And again, thanks Russell for the great game, which probably deserves to be a platform, with endless options of what to do with it. If we could have this as a Lego kit that we can play around with, it would be amazing.