Kidzban/Personal Kanban 2nd grade elementary school class experience report

The purpose
As a parent to a 2nd grade school girl I want to deliver a personal kanban / KidzBan class in a school show & tell parents activity so that kids are exposed to this interesting approach to plan & navigate their activities that can help them take ownership. Desired side effect – for her princess to be proud of her father.
Well, I’m not a Kidzban or Personal Kanban expert. Far from it. We’ve played occasionally with Kidzban at home but we are certainly not practicing it on an ongoing basis. Far from it. I’m also much more of an Enterprise Kanban kind of guy. But since talking about Hierarchical boards, Expand/collapse patterns, various ways to Limit WIP, MMFs, MVPs, Feature teams, Classes of Service and cycle time control charts in 2nd grade might have been an interesting experiment, I’m not sure either I or my daughter would have been proud of the outcomes.  So I decided to take a shot at a personal kanban/Kidzban class, with the understanding that the kids will still NOT understand what I’m doing for a living afterwards…
As an initial structure I planned to start with why an approach like personal kanban is even interesting to the kids, and then show very basic Personal Kanban using an example and then let them experience it by building their own Personal Kanbans and doing dry runs on them in small groups.
Then, I consulted both with Danko (Danny Kovatch – my friend at AgileSparks) and Shirly (@ShirlyRonenRL) who together are advocates of this field in Israel and also wrote the nice ebook Agile Kids as well the online #PersonalKanban/#kidzban crowd ( @topsurf @ourfounder @maritzavdh and others like @YvesHanoulle @markusandrezak pitched in as well – isn’t twitter great when you have such great online friends?) for some tips about how to do it. Key insights were: Let the kids experience it themselves, Don’t talk that much – less talking more doing, Don’t show and tell, actually build it together, Use lots of colorful post-it notes, Let them draw pictograms if they want, choose themes like planning birthday parties, packing for a family vacation, chores mom asks you to do.
Based on all these great tips I decided to build the initial example together with the kids using the example of home activities mixing chores and wants, with the goal of navigating the chores/wants better in order to get to as many of the wants as possible not by neglecting the chores but by mixing them in and by using kanban to be more focused and responsible. I then planned to indeed let groups choose their theme from the list above or other activities the kids suggest as things they plan and do that might require something like kanban. I also planned to have a takeaway session at the end for kids to talk about what they like about the approach, and if they want to do anything with it at home.
Responding to Change over Following the plan
2014-01-17 08.26.44
Come friday morning this nice plan didn’t really survive contact with the enemy. Oh Sorry, the class 🙂 Actually the kids were lovely and engaged and we had lots of fun experiencing kanban and discussing the world of chores, wants, the connection between the two, while drawing boards and moving a lot of colorful post-its and stattys notes around. They were so engaged and excited that it was hard to push forward in the activity as everyone had to share their ideas, not necessarily in a way that is very related to Kanban itself but it is very hard to be an aggressive facilitator with kids, at least for me… Telling them lets park it was hard and I decided that as long as they are having a fun discussion and experience that is even more important than getting the whole point across (even though I actually had limited points to get across).
The key thing I would like to have improved outcome wise is to be more certain they actually understand how the actual operation of the kanban works on a daily basis. We exercised it in several scenarios, with them guiding me what card to move next, as well as volunteers moving them in several scenarios, but I still have a feeling that they mainly grasped activities like “map what you need/want to do” (a.k.a. create a backlog) as well as “plan your day” (a.k.a. pull to the “today” area) but that the whole flow of pull into “In Progress/Now” and all the way to “Done” didn’t really sink in. Maybe it is the fact they were so excited about discussing their wants/needs/chores that focused them on this area. Maybe it is something about the way I facilitated this discussion. But if I do it again I will certainly look for ways to get much faster to the actual act of pulling cards and experiencing the full flow and deemphasize creating lists, maybe by providing some initial ones, or by stopping this discussion earlier.
In addition I felt that the concept of dry-running was too abstract for the kids which was why when they exercised their own boards creating the plan resonated while creating the “In progress” lanes and actually playing to try it was very tough to get them to try. This repeated with almost everyone.
Another interesting area was the comparison with the calendar/timetable they use for their classes at school/extra-curricular activities. I felt it was non-trivial to get them to grasp the challenges with a fixed timetable that would drive them to use a dynamic system like kanban. I see this with my daughter for example. On several occasions I saw she feels much more comfortable planning a calendar/timetable rather than a kanban style pull system. Even the kanban board she and a friend created in class had some form of timetable swimming lanes in it. After talking to her about it some more she says she now gets why with kanban you don’t need those timetables and why it might be a better option sometimes, but I think we haven’t got to the root cause of this yet so definitely an interesting area to explore further.

Who would have thought Personal Kanban would end up being the counter-measure to stalled Kaizen / Continuous Improvement?

Paying attention to Management attention

I’ve been talking recently about the challenges of keeping sustainable sticky Continuous Improvement programs. An aspect I’ve mentioned but not emphasized enough is the lack of management attention. In this blog post I will focus on why management attention is so important in improvement programs, why is it lacking and what might we do about it.

Why we need management attention

Basically to change the system of work you need the attention of people that are in charge of it and can change it. If they don’t have enough capacity to work on the system you will end up stuck. You might find yourself focusing on local optimizations, you might even make progress in things that affect the overall system, but changing things like management decision filters, approach to targets (or lack of them…), relations between silos and the like will be difficult.

You might rightly ask: “Aren’t we supposed to trust the people working in the system and empower them to take charge of the system design and improvement?”. Yes we should! But getting to such a system typically requires significant change/transformation of how the system of “changing the system” works. You need attention of the people in charge of that system to change it. We’re back at square one aren’t we.

You might make a case for Guerilla warfare – working with people on the ground to change the system of work without showing up on the organization’s radar or at least without requiring formal support. That might work for initial “scouting” and establishing a case for new ways of working. I haven’t seen or heard of cases where the guerilla warfare was able to scale the change in a persistent healthy way throughout the organization.

So basically, can we agree that at least at some point of changing the system of work or system of improvement we need the people managing the system to start investing attention/capacity cycles in studying and improving?

For my inspiration on this term of “Management Attention” and it being the constraint of our systems you should watch Exploiting the Constraint: Management Attention by Eli Goldratt.


Why are we lacking Management Attention to Improvement work

Many managers don’t pay as much PERSONAL attention as we’d like to studying and improving the system of work or in the capabilities of their organization. Why is that?

Some managers thrive on urgency and opportunities for heroism. One can probably inquire about the ecosystem in which those managers thrive and who is responsible for changing that system. Basically as long as the organization cherishes and commends this kind of management rather than quiet steady capabilities-focused management we shouldn’t be surprised. The counter-measure? Seek to change this “policy” constraint which typically is driven from way up… This can be hard, but if you don’t deal with it don’t expect much traction.

Other managers DO care about improving the capabilities of their organization. They DO care about the system. They just don’t have the capacity / cycles to invest in it.

Let’s pause for a second and reflect on this issue from a different perspective. We’re all familiar with the team that is so busy delivering value that doesn’t have time to retrospect let alone take action towards improvement. What can such teams do? They can start by bringing their system of work under control using approaches like Kanban or Scrum. Then they can start allocating capacity to improvement. Scrum forces team to spend at least the “Retrospective” ceremony time for improvement but still many teams don’t take action based on the retrospective. Allocating capacity towards “Improving the system”/”Housekeeping”/”Engineering Improvements” or however you want to call it is key to getting actual results and feeling that the time spent in Retrospectives or Kaizen events is well spent. This allocation of capacity can be achieved in Kanban by always having one experiment in progress for example. Or one experiment in every Sprint Backlog if Scrum is more your cup of tea. So what can we learn from our advice to teams?

Personal Agility for Managers – Exploiting the constraint

A manager can start to bring his work under control by using an approach like Personal Kanban. Once under control he can start allocating capacity and attention towards improving. Improving his personal system of work, so he can free more and more capacity to strategic themes in his system of work. What might those be? For example driving and supporting improvement agendas of the organization he’s in charge of.

If managers are a key leverage point for improvement programs, we can also see them as bottlenecks/constraints for the “System of Improvement”. What we are suggesting here is to focus on this constraint and ensure managers achieve the best results they can with the time they have.

Decentralized Control – Subordinating to the Constraint

The next step is to subordinate to this constraint. Subordinating means to look at the system and finding opportunities to divert work from the constraint elsewhere, or do work in a way that makes the work of the constraint easier/faster. One way to achieve that is to Decentralize Control. If more and more work can be decentralized, we can free management attention/time. This can be “work” decisions such as what to pull, how to deal with conflicts etc. It can also be “improvement” work. They key though is to do it right. Not just decentralize but give good guidance as to the Intent of what we are trying to achieve. For a great talk on this subject watch Donald Reinertsen’s LSSC12 Talk.

 Takeaways for Lean/Agile Journeys

My current thinking is that helping managers improve their personal agility using approaches like “Personal Kanban” should be a key building block of successful improvement program. I started nudging managers I’m working with to consider this when I’ve seen them become the constraint for the “Improvement Journey”.

It shouldn’t come as a surprise that many of AgileSparks‘s current clients are exploring “Personal Kanban” in parallel to improving their wider systems. We are also working to help them pro-actively. AgileSparks coaches such as Danny Kovatch have been working on Personal Agility programs and approaches for a while now, Jim Benson exposed many people in israel to Personal Kanban in his Agile Israel 2012 talk as well as a workshop he ran when he was here.

A great side effect of working on something like “Personal Kanban” while running or preparing for a “Kanban Method” journey is that a key group of stakeholders for the journey are experiencing it first hand and leading by example. If they can “Limit WIP” and show to people they are doing it, there’s a higher chance that “Stop Starting Start Finishing” will stick on the team kanban board. Or on the portfolio board. It might be an interesting approach to start with Personal Kanban as preparation ground, even before management attention surfaces as the constraint. OTOH we might be working on a non-issue. If managers are not the constraint in a specific situation, should we still start with their personal agility? I can go either way on this, and would love to hear what other Kanban practitioners/consultants think.

Bottom line

There’s a good chance management attention is the constraint of your system. Identify if that is the case. Exploit it by offering managers “Personal Kanban” as an approach that can help them free scarce capacity. Subordinate to this constraint by Decentralizing Control intelligently while aligning using strong Intent. Leverage the cool side effect of having managers use similar approaches to take control of their work that their group is using to take control of its work.

TODO in a future post: How can we reliably identify if management attention IS the constraint? I have several thoughts on this, but will leave them to a future post.

Your turn

What do you think? Is management attention a typical system constraint? Is personal agility a good way to deal with it? Have you found other ways that worked for you?

If productivity experts tell me to keep email closed most of the day – why shouldn’t I avoid looking at defects for most of the release?

An interesting question was raised to one of our coaches at Agilesparks. 

Question: Isn't it more efficient to wait till the end of the release and then all together handle all the bugs?

One of us answered that same like you probably prefer to answer emails throughout the day rather than at the end, you want to deal with bugs during the sprints. 

I of course fully agree that you need to deal with bugs during the sprint/release, or in other words keep the Bugs In Progress number limited. (Anyone for Limited BIP society?)

But this answer doesn't convince me. 



many productivity experts (e.g. will tell you to turn email off for most of the day, and open it in specific slots throughout the day, to avoid context switches, etc. This will protect your flow on the tasks you should be focused on. This is btw different between managers and makers, and is similar to how their calendars look like (see a great post by Paul Graham ). I would say that the more reactive your role is, the more responsive you probably need to be to email, and the less actual creative flow you can expect. When you do need to make something, TURN YOUR EMAIL OFF. 
I would add a caveat to this rule to say that in collaborative environments like Agile teams, care and balance need to be applied to allow both Flow to happen, as well as collaboration and fast feedback/osmosis in the team. 
Now what do we tell those makers of software, that we instruct to ignore their EMAILs for most of the day? that they need to deal with defects as soon as possible? Why?
The reason its different is that emails during the day don't really "ROT" like the vegetables in the market, do they? or at least a major part of them doesn't.  The cost of addressing an email a few hours late is not much different than addressing it a few minutes after its sent. 
Again, the caveat is those decisions others are making in our team, that they want fast feedback and collaboration on. We should find a way to allow those to come in (maybe by coming by and talking?), maybe by marking the emails from the team as higher priority, whatever. 
With defects or decisions in software development in general its different. the cost to deal with late feedback is exponentially higher as time goes by. Also, having the large inventory of those issues risks the release since you don't exactly know how long it will take you to fix all of them. 
Back to email – yes, if you keep all emails to the end of the day, you don't know exactly how much time it will take to fully address them. but you can decide whether you are scope-driven so you get to inbox zero every day (check out 0boxer btw for a nice gmail extension that makes a game out of this…), or whether you give a time-slot priority based and do what you can, and periodically deal with the overflow. 
For sure, probably reading your mailing lists (e.g. kanbandev, agile-testing) are all highly valuable, but can be described as intangible benefits to the day, so can be scoped out if necessary. Again, some of us actually see participation in the lists as a tangible ROI, but then probably the way to deal with that is put it on our schedule, think about the appropriate SLA, etc. If its important enough to answer in realtime – then by all means make kanbandev a high priority email in your inbox and let it thru. Have it SMS you, twit you, whatever. But be aware of the decisions you are making. This is similar to managing demand for a product development group…
The decision about the level of WIP and cycle time you are shooting for should be an economy-driven decision. both context switches as well as late feedback have a price, in the waste they create. you need to weigh the price and decide what is best for your context. 
The reality of product development in most of the projects out there, seems to be that its MUCH more economic to build quality in and don't let defects rot outside in the sun. 
PS If MY inbox was turned off, I would probably not see this email from my colleague and write this post. Now what would be the price if I answer him in the evening? Probably the cost of answering and dealing with the feedback would be the same. Thinking about it caused me to context switch and write this blog post. Now I usually just defer answering to such emails, and writing blog items (I use and have various draft post ideas there that I get to at some point). If I was perfect, my algorithm for when to answer and when to defer would really be economically sound. Since I'm not, it's probably more about enjoying the moment and the journey. Which is something this colleague of mine especially appreciates 🙂 you know who you are!