Are You Also a Kanban Team Squeezed into Scrum?
Is it possible for a group of unhappy people forced to do Scrum to turn themselves into a highly self-motivated, energized, and ideating Kanban team in 30 minutes?
As an agile advisor, I’ve seen many agile teams that were happy to go from a Command and Control’ish matrix organization to a Scrum set-up.
But after Agile became a fad, I keep seeing too many managers bragging about how many so-called Scrum teams they have formed in no time, claiming “Now we are agile”. The result is a bunch of teams that suffer.
In this article, I
- argue how using the wrong frameworks that are unfit for the situation is very demotivating and inefficient for teams
- describe a lightweight facilitation principle that can be used to make demotivated teams invent their own effective way of working with their board(s)
Unfortunately, when well-meaning managers pronounce their (fake) agility, I see what happens to some of the demotivated teams they so proudly call “our new Scrum Teams”. Let me give you an example.
Team Unhappy
A highly regulated company had transformed more or less overnight into many so-called Scrum Teams in a scaled set-up. Coaches and management consultants had told the managers which teams to form, who should work in which teams, and what to do from there: Train everyone by forcing them into a 2-day (scaled) Scrum Course conducted by a management consulting company.
Many former team leads and project managers were offered the Scrum Master role and given a Scrum Master course. Product Owners were allocated a few hours a week to each team, and some POs were offered a Scrum PO course.
Does this sound familiar to you?
Team Unhappy had been part of all this. They used to be a core team of satisfied colleagues who liked their job. They had their team extended with new colleagues so that you can become more cross-functional, they were told.
“Now you do Scrum”, they were told by the management consultants.
The company’s tool for handling Incidents had been extended with a backlog functionality, Features, Stories, points, note tracking, etc.
“Now use this tool to manage Scrum and Sprints”, they were told by the managers.
The group of former satisfied and efficient people started becoming more and more unhappy. It was not crystal clear to me why that happened.
Local leadership tried to help the best they could. Instead of changing ‘the system’ (e.g. the scaled framework), they held many meetings to find out what was wrong with the team members and what to do. People were openly sharing their concerns and complaints. A few changes in the team composition were done, but they kept acting like an unhappy team.
Team Happy
I worked as an agile advisor for another Scrum Team and some managers in this scaled set-up. I called them Team Happy because that’s what they were. I did not see a lot of development activities, innovation, or high complexity that we often see in Scrum Teams. I noticed, however, that Team Happy did a few exploration and requirements elicitation activities, analysis- and design documents were handed to a 3rd party development team outside of the company. A few releases per year fitted the end-users well, so that was their release cadence. I also noticed how many teams were constantly moving undone Stories to the next sprint. To me, they looked like ordinary tasks, not User Stories.
It turned out that the team was primarily working on keeping the existing systems in good shape — ‘maintenance’ is a good term for what they were doing.
I had a hunch, that maybe this team, and eventually other teams as well, did not really benefit a lot from working in a Scrum’ish set-up, but they were happy and leadership was happy. They had achieved more transparency now from the bi-weekly Review- and Demos and the new product ownership (now conducted by real end-users) ensured that the teams were delivering the right products to a higher extent than before. So far, so good.
But not for Team Unhappy.
Maybe Team Unhappy was also squeezed into something they were not. But I could not know for sure.
What were they actually doing?
If the triangle below illustrates what the Scrum teams were forced to do (such as Scrum Events, PBI refinements, and using the usual artifacts mentioned in the Scrum Guide), then the squares represent stuff that in my view added some value to them (e.g. close user interaction, solving Incidents, answering questions from end-users, and keeping systems running on a daily basis).
In my opinion, they were doing and using a lot of non-value-adding stuff illustrated as the empty space in the triangles. A total waste.
Some teams, BTW, did stuff that added value but was not included in the scaled Scrum set-up. Not to speak of the required waterfall’ish stuff they had to do because their 3rd party developers were not at all capable of delivering iteratively and incrementally. Illustrated in the first triangle.
I saw a lot of recurring maintenance tasks on the teams’ boards of which quite many were unfit to be put into a Sprint for very many reasons. For many of them, it would be stupid to break them into smaller slices just in order to fit into a Sprint.
I noticed what they called Features (larger chunks of work) that were just placeholders for a group of identical tasks they called Stories. For example, optimizations of end users’ workflows — never-ending improvement loops that could just go on and on. And I saw Features like: “Do an analysis of this-and-that”. “Write a design document for this-and-that”. And every sprint I saw the same Stories copied again and again. ‘Attend meeting X’. ‘Check the incident queue for requests’. ‘Configure Y‘. “Do regression test after bug fixes”, etc.
But most importantly:
The teams only rarely demonstrated (i.e. had reviewed according to Scrum terminology) anything but powerpoints at the end of sprints.
I could be wrong!
But at the end of the day, I perceived them primarily as maintenance teams that did exploration activities such as requirements elicitation and wrote some requirements- and analysis documentation for the external development teams. Very few of the so-called Scrum teams were actually developing anything themselves, and could hardly be called cross-functional in that sense.
Of course, I would offend everybody in the organization who believed they were agile if I cried out this loud.
That was not my intention. Further, I could be wrong.
Preparing
I humbly decided to let my colleagues do some discovery themselves of potentially more suitable ways of working, at a pace that suited them, gently supported by me as a facilitator — and mentor, if they wished.
I was puzzled about the situation: I knew I might be able to give them a few hints, but I also knew that maybe they could invent better ideas themselves.
So, I invited all teams and leadership to a short Kanban Appetizer event.
1.5 hours including 30 minutes of group work in arbitrarily formed groups.
Participation would be by invitation — no one to be forced, nor expected to show up.
I designed one exercise to distinguish a Kanban board from a typical board used by a Scrum Team. I wanted to illustrate that it takes more than a board to identify that (see the two boards below). Hint: Most probably the rightmost board would be characterized as a Kanban board with well-defined WIP limits.
Some trainers confuse people by calling a Scrum Team’s board a “Kanban board”. That caused a lot of confusion for Team Unhappy, by the way.
Workshop #1 - Kanban Appetizer
At the first workshop, the Kanban Appetizer, approximately 50% of the workforce showed up with app. 30% of those staying for the full event. I was happy. This was more than I had hoped for.
I wanted to Go with the willing people only (ref. my mentor Daniel Mezick [1]). Never impose, always invite.
I introduced the very basics of Kanban [2] in the workshop:
Focus on the flow. Back to basics — the Toyota Production System, TPS. Compare that to systems development. The alternative board with maybe different columns than we usually see on a Scrum Board. The WIP limits. Kanban principles. And maybe most importantly:
I visualized how complex tasks are different from complicated tasks (a small fragment of the Cynefin framework [3]). I showed how the high complexity problems fit well into a Scrum (or similar) set-up with experiments etc., and how some of the complicated stuff that still requires highly skilled specialists (like the teams in this company) could be well fitted into a Kanban framework.
This is too, or at least extremely over-simplified, I know. But it served its purpose: Being an appetizer.
Then they worked in small groups to discuss which Cynefin domain the typical tasks of their Scrum Teams most probably belong to.
When they re-assembled they were astonished:
- 90% of their work was not complex at all, but primarily complicated.
- And many tasks, I could tell from their presentation, belonged to what Dave Snowden would call Simple.
At the end of the session, I invited them to a new 5-hour Kanban Deep Dive workshop one month later. To experiment and innovate with Kanban and the following:
HYPOTHESIS
Might our team actually become more efficient and happy with a Kanban board using a Kanban framework, etc. to complement the mandated scaled Scrum set-up?
Preparing the Kanban Deep Dive Experiment
The next month I speculated like crazy because I wanted the invitation to this experiment to be so open that they could decide at the beginning of the workshop whether they wanted to join or not:
- How on earth could I prepare the facilitation of a workshop with an unknown number of participants, in an online set-up because they were distributed teams?
- What would be my (personal) success criteria?
- What if only one person showed up?
- What if all 70 people showed up?
- What if some would be destructive?
- What if ‘the willing people’ were not sufficiently skilled to work with Kanban? (meaning: if my first Kanban appetizer workshop was not enough for them to experiment with Kanban by themselves)
Of course: All my fears were later put to shame.
I decided to plan with very light facilitation. Providing the boundaries, the hypothesis, being the timekeeper, and nothing more (except maybe for providing the Zoom details).
I would be 100% open with the participants and admit that EVERYTHING COULD HAPPEN and that we depended on each other’s knowledge.
I would convey to them I did not have all the answers. But that I would do my best to involve and engage them, that we might disprove the hypothesis, that there would be a lot of learnings, and that there would exist no such things in the zoom room as mistakes or errors. Only learnings.
WORKSHOP #2 — Kanban Deep Dive Experiment
30 persons showed up to the introduction. I had no idea how many of them would follow me to the Zoom room right after where the Kanban workshop would take place. I opened the room, held my breath for a few seconds, and got overly excited:
Five persons immediately showed up. It turned out they were from Team Unhappy. To my big surprise. Wow! Their Scrum Master was there too.
I was prepared for everything and nothing. Whoever shows up are the right people. I was prepared to be surprised.
And then…
The Game Changer
After a short welcome and introduction, we warmed up with four open questions that I facilitated as Silent Brainstorming using Ideaboardz:
- What triggered you to want to investigate Kanban?
- What would you like to get out of this workshop?
- What challenges do you experience with backlogs, planning sessions, sprints, or other relevant issues?
- What would you like to have happen?
Let’s look at some of their answers in the Ideaboardz:
1. What triggered you to want to investigate Kanban?
Team Unhappy’s individual team members all noted that their maintenance tasks did not fit into Sprints, that those tasks were not appropriately visible on their (mandated) Scrum Board, and that they would like to work with and visualize a more flexible flow of tasks that provided a better overview and progress (I noted that they wrote tasks, not Stories).
2. What would you like to get out of this workshop?
The team representatives wanted to get some hands-on experience with a Kanban Board using the Kanban framework — but not abandoning the (mandated) Scrum Board. They just envisioned using Scrum for what Scrum is suited for, and Kanban for what that is well suited for.
3. What challenges do you experience today?
They felt they were spending too much time on (mandated) Scrum Events that did not support the way they were working with support- and maintenance tasks that, after all, included about 90% of their workday. The team had somehow during the transformation into a Scrum Team been divided into those who primarily did maintenance and a few who primarily did a little more development’ish activities. They felt it was extremely difficult to make their tasks fit into 2-week sprints even though they tried to slice them differently. That applied to development tasks as well as maintenance tasks. They said they were tired of constantly moving tasks from one sprint to the next (i.e. spillover, or just repeating the same tasks in every sprint).
And now to what turned out to become the real Game Changer question:
4. What would you like to have happened?
They wanted their maintenance tasks to become equally transparent on the board as the development tasks. That they could feel like one unit, not a fragmented team. Focus on the fact that *also* maintenance activities can be improved/optimized.
How could I facilitate that?
Basically, all I did was ask the four above questions at the beginning of the workshop and then continued:
How do you wish to proceed from here?
They wanted to work with the existing ITIL tool that was mandated as their Scrum tool, to see if it could be used for Kanban boards.
Ah okay. And so they did.
It quickly turned out that one of them actually knew a lot about the tool, and he showed the others a lot of tips and tricks. After 30 minutes I heard in the virtual room things like: “Wow — is that actually possible?” and “Wee — this is cool!”, and “Hey — I am truly inspired by what I see”.
I could help them now-and-then with some tips on how they would also need to adopt some changes in attitude during their workday.
Maybe adjust their Daily Scrum, shorten the time for backlog refinements, and so on.
I reminded them that a fool with a tool is still a fool (I forgot who first said that many years ago) and that they were right now taking action on that by discussing not only the tool (their new to-be Kanban Board) but also all the new politics, WIP limits, etc. when taking it into use.
After 4 hours in the workshop including a few 7 minutes breaks, they were happy with their new Kanban Board and their agreements on how they would continue the experiment and start working with it.
The fifth hour was spent on one more break and planning how to demo their results to their curious colleagues right after the workshop.
THE SECRET SAUCE
Their next question also took me by surprise:
How did you make us do this?
Hm… really? I hesitated before I answered.
Actually, I practically did nothing. YOU did everything, I said. And that was the truth.
No, no, no — we felt you were there with us all the time — although on Zoom — but guiding us along, helped us to stay focused and on the right track. And the opening questions were SO helpful!
I smiled. Now I understood. My facilitation strategy had worked. I told them I had used the principle:
Do Less — Accomplish More
Of course, I had prepared a lot before the workshop.
Primarily mentally, using this philosophical principle all along the way.
And I had to use it during the workshop as well because I had decided to let everything remain open until the very beginning where the willing people showed up at the workshop.
It takes courage — and for me meditation — to gain inner strength and belief in the process as well as a lot of guts to plan with such lightweight facilitation.
The participants’ perception was correct, of course. They felt I played an active role during their experimentation. But basically, I was quiet most of the time. They just didn’t notice that. In Open Space Technology we call it ‘Holding the space. I think that’s what I just did:
“The ideal event facilitator is “fully present and totally invisible”, “holding a space” for participants to self-organize, rather than micro-managing activity and conversations (paraphrase)” [4]
Team Unhappy had turned themselves into Team Excited in 30 minutes and Team Happy in 4 hours.
Now their daily focus would be on flow, limiting work in process, and a few not-so-time-consuming Scrum Events so that they were able to visualize and present their long-term plan for the relatively small number of complex tasks to leadership.
Learning
- Don’t train people — educate. Focus on lifelong learning!
- Unleash the inner potential of people!
- Always question what consultants (including me) try to convince you!
You train dogs, and educate homo sapiens, my wise and highly esteemed mentor, James Coplien, always reminds me.
You can’t ask people to scale Scrum before they know what Scrum is and before they experience the fundamentals that later need to work in a scaled set-up. Nevertheless, that’s what most companies are advised to do by management consultants — scale, scale, scale. The sooner the better. No, no, no — for crying out loud! If you only have a small number of Scrum Teams working on the same product, encourage the relevant people to talk, talk, talk instead of scale, scale, scale. That’s where the value is — but not the money for the expensive consultants, of course.
Don’t count on management consultants from business schools to be able to tell you which framework suits your teams and the organization best. If they cannot distinguish complex from complicated, you should never allow them into your company the first time.
And last, but not least:
Use Scrum when it supports what you’re doing. Otherwise use something else.
Use stuff like Kanban, Extreme Programming, Crystal, just a board with some appropriate lanes, a Sharepoint list, an excel sheet, or whatever.
But don’t act like a blindfolded duck and accept anything you’re told. That also applies to what I have stated in this article. Try it out for yourselves. Let the team decide. Experiment - and remember the hypothesis 😉.
Conclusion
Team Unhappy experimented with Kanban and found it useful for now. Maybe they will change to something else that even fits them better — who knows? I certainly don’t. But I know that less is more.
References
[1] Inviting Leadership, Daniel Mezick, 2018
[2] Kanban: I don’t want to give any reference here to Kanban Frameworks except that I will mention the origin of Kanban at TPS, the Toyota Production System. There are many ‘Kanban Schools’, and I don’t convey myself to one specific. What I cover in this article is the very basics of a Kanban system.
[3] Cynefin: Snowden, David J. & Mary E. Boone, A Leaders Framework for Decision Making, 2007. https://hbr.org/2007/11/a-leaders-framework-for-decision-making, accessed 26-Sep-2020
[4] Open Space Technology, by Harrison Owen. See e.g. https://en.wikipedia.org/wiki/Open_Space_Technology, accessed February 21–2021
