Kanban suggests we manage work in process (WIP). Many people interpret this to mean add WIP limits on queues. But that’s not the only way to do it. And it often takes a very disciplined team to do that.
An easy way to start managing WIP is to simply build a habit of looking to finish something before starting something new.
Habit – manage Work in Process
Trigger: When you complete a task.
Action: Look to see if there’s another task that’s already been started that you can finish. If it’s yours, just finish it. If it’s someone else’s see how you can help them.
Intention: Avoid increasing WIP above capacity without having to put a lot of effort on it while also creating opportunities for cross-learning and collaboration.
I’ve been talking a lot about what’s needed in the Agile space is a better training method and a better way to use frameworks. I’ve also talked about how many company’s getting to Agile are late adopters. I often write letters to would be participants of proposed training and I realized that many companies are not late adopters but rather have been rightfully concerned about what Agile training they’ll get. They want improvements, not frameworks which at best are a means to an end.
I recently wrote such a letter and thought it’d be worth sharing. This was for a proposal for a small-scale adoption of Lean-Agile (small scale is 3-10 teams with associated product owners).
Here it is:
First, those of you who are concerned about getting Agile training, I don’t blame you. Most “Agile” training isn’t about Agile really, but rather about Scrum. These are two different things. I don’t believe in frameworks that force you to do things so that you’ll get better. I prefer providing insights to people so they can use them to get better. You’re already capable, knowledgeable people who know your job much better than me. Most of you probably know a good amount about Scrum anyway and learning more may or may not have value.
A little bit about me. My background is as a developer / architect. I’ve written two technical books – Design Patterns Explained and Essential Skills for the Agile Developer. I believe you can only teach what you’ve done and I’ve done a lot of development and product management. Although I have taught Scrum for almost 20 years and Kanban for over 10, I can assure you it was always in support of the real goal – improving the capabilities of the people being trained. I have no interest in teaching you frameworks or methods. My interest is in helping you get your job done in a more effective and efficient manner. As someone who developed software for over 3 decades, I’ve been there. I also promise you you won’t hear any dogma from me.
The training that’s being proposed has four main aspects to it:
How to identify the most important work to be done
How to provide that to the teams
How teams can break these targeted business increments down into small stories in a way that also provides clarity on the behavior that’s needed and in such a way that it’s easier to implement
The light ceremonies needed to keep the teams coordinated
To be clear, the training is not about teaching you “Agile” so you can figure out how to work better. It is about providing insights and patterns that you can use to do your work better. We won’t focus on standups or retros, but rather on things such as how getting clarity on requirements helps inform design and why smaller is better.
The best way for people to learn is on the job over time. The worst is in a 2-4 day course with where you learn information about something but don’t get a chance to try it. Studies have shown that 90% of what was learned in a classroom is forgotten in less than a week.
5 years ago I asked myself – “what would I do if a company asked me to train their thousands of Agile coaches who needed to become more proficient?”
We think we’ve come up with the best way to deliver on this. It also turns out to also be the most economical. The format we use is called “flipped classroom”, a method developed at Harvard. Essentially each lesson starts with a reading and video. An assignment is then given that participants work on with their team. Two live sessions are also provided so participants can ask questions before and after their assignment. Participants learn by doing while having the support they need. In addition, participants are provided access to an online support system that covers virtually all of the common challenges faced by teams. In this way participants can learn both the curriculum they need and get help on their own specific problems. The next program starts 1/28. Contact me if interested.
There are many things I, and many other consultants believe, that are not politically correct to talk about. I am going to talk about them now. The reason is if you are a practitioner and these resonate with you, then you might want to consider working with people like me to help you get better. If you don’t want to work with me, then use this as a checklist to vet your potential providers.
Both coaching & training is more expensive than they need to be. Much of this happens because the certifying bodies control the number of trainers by quantity. Many of the top trainers in the industry have no certification by choice.
The biggest problem with the Scrum-Kanban confrontation is that neither are the right thing to do all of the time. Usually some combination of the two is best.
Intense training, except where people do hands on work is effective. True learning takes place over time in the learner’s workplace.
People need a support system that can be used to provide them insights into their own problems. Reinventing the wheel should not be required.
AFAIK our Advanced Scrum Master / Kanban Online Workshop is the only workshop that fits the above. It’s worth checking out.
Scrum and Kanban are the two most popular Agile team level methods available. While the difference between them is mostly thought to be sprint based or flow based that is just one aspect of how they differ. More significantly, they differ in how to start, how to improve and how people should be organized. They are also based on different theories of how to manage software development work and whether you need to change your roles. The differences between Scrum and Kanban in these areas is very significant and creates other differences as a result. These include the amount of discipline to use them and in which cultures they fit well.
The Differences Between Scrum and Kanban
We’ll go through these differences in a little more detail:
Organization of the team
How to start
Level of discipline required
How to improve
Theory based on
Roles in Scrum and Kanban
Scrum has predefined roles – the product owner, the Scrum Master and the development team. Kanban can work with whatever roles already are present. If your folks are attached to their roles, Scrum may cause problems.
Organization of the team
The heart of Scrum is a cross-functional team. Kanban can work with however the teams are organized. Cross-functional teams are good, of course, but if they are either not viable or it will take some time to create them, Kanban may be a better choice.
How to start
Scrum requires a start by shifting into its predefined roles and team structure. Kanban can start where you are. Sometimes a big shift is a good thing, sometimes it’s not.
The biggest differences is that Scrum uses time-boxing (sprints) while Kanban uses a flow model with cadence. That means that things are done in small batches of work while checking in with each other on a regular basis to prepare backlogs, do demos and reflect.
Scrum works best in a culture where people are looking for something to tell them what to do and where the team needs protection from outside the team. Kanban is more self-generating and based on visibility.
Level of discipline required
Scrum requires less discipline to do than Kanban since the rules and events of Scrum tell you what to do in a more concrete, specific manner than Kanban does.
How to improve
Scrum’s focus is on doing the Scrum events, following its rules while creating its artifacts with its roles. Anything that impedes you from doing this is presumed to be an impediment from achieving Agile. Kanban’s focus is on the actual work being done. It creates explicit visibility of both the work and agreements between people on and off the team. This is perhaps the biggest different between the two: Scrum focusing on its practices, rules & artifacts which presumably make the work go better and Kanban focusing directly on the work and workflow.
Theory They Are based on.
From the Scrum Guide: Scrum is founded on empirical process control theory, or empiricism. Empiricism asserts that knowledge comes from experience and making decisions based on what is known. Scrum employs an iterative, incremental approach to optimize predictability and control risk.
Kanban is based on Theory of Constraints incorporating principles of Lean flow. Kanban is not fully based on Lean since it does not attend to organizational structure which is a central Lean tenet.
The net difference here is that Scrum works towards improving outcomes by doing regular inspect and adapt reviews to see how to improve the teams practices. Kanban, on the other hand, looks at the flow of the work and sees how it can be improved.
Time-boxing or a flow model.
Time-boxing creates a great context within which the team can get its work done. With a flow model it is up to the team to ensure they are following what they’ve said they should be doing. Flow models require more discipline to ensure that work items remain small as there is no sprint they are required to fit into.
The figure below summaries these differences.
What These Differences Mean
Our experience is that different teams have different needs. They often need a blend of the Scrum and Kanban. The fact that both are defined to be used as a whole has more to do with their proponents trying to create approaches that work for everybody. But individual companies and the teams within them are different – and these differences should be accounted for.
However, the outcomes required by virtually all teams are the same – quick feedback, collaboration, validated code, building small increments, continuously improving, … The challenge here is that even though teams are supposed to self-organize, it doesn’t mean that they can just arbitrarily pick what they want to do. Doing so will certainly lead to holes in any approach they undertake. What is needed is a method for understanding the purpose (intent) of a role, rule, artifact or event and to ensure that if substituted, the new practice manifests what the one being substituted was attempting to do.
What coaches for Agile Teams Need to Know
When teams took on Agile in isolation knowing just Scrum was good enough. But now, virtually all organizations have teams where a blend of Scrum and Kanban are needed. Even when Scrum is to be used managing the capacity of critical people can be improved with Kanban. Agile coaches now need to know a blend of the two.
This is not difficult to provide. Unfortunately, most training provide only one side of the story.
How Workshops for Coaches Need To Be Delivered
It takes time for people to become good coaches. Unfortunately, most coach training takes place in 2-4 days. Not only is not much retained, but when students have difficult in adopting what’s been learned, there’s often no one to help them. Real learning in a classroom is also difficult.
The ideal workshop needs to focus on learning effectiveness, real adoption of what’s been learned, cost and overall support. Ideally it will take place over a few months with 1-2 hours required each week. This both enables people to learn in small steps while taking little time away from their job. This can be accomplished by using online training with flipped-classroom style learning methods.
A support system should also be provided.
This is exactly what the Net Objectives Advanced Scrum Master / Kanban Online Workshop is. At $595 it is half the cost of the Certified Advanced Scrum Master course, but provides twice the content. Enrollments after the first are only $500 each. If you have embedded coaches you can get about 180 Scrum Masters go through our workshop for the cost of only one embedded coach.
How Is This Savings Possible?
Even though I’ve been working on how to lower the high cost of coaching for 5 years with advanced learning methods, this ratio of being able to grow 180 of your own coaches for the cost of one embedded coach seemed far-fetched. So here’s an analysis of why it is possible:
Coaches do not provide a support system for the people they are coaching. Most teams have the same types of challenges as others. 1 on 1 coaching is not needed to help with many of these. Solving them this way is expensive.
The use of scaled learning methods greatly increases retention while lowering costs by 80%
With the growth of Agile most coaches don’t have the requisite 10,000 hours to be truly expert
Coaches who only know Scrum well (putting a few Kanban practices into Scrum is far from knowing Kanban) precludes teams being provided solutions that require kanban. Poorer solutions require more effort to implement.
Avoids dogma and the argument of which is better, Scrum or Kanban. Both are needed.
A 15 minute chat is all it’ll take for you to clearly see why.
I mostly love Scrum, but I am concerned with that it:
1) doesn’t work everywhere but is promoted as if it does
2) sets up a sub-conscious resistance to go beyond it as because the case where “We do Scrum, but we do X instead of Y” is virtually always considered negative whether it is or isn’t. Also, when you are certified in Scrum and go beyond it the value of your certification is lessened
Lean-Scrum differs from Scrum in the following ways:
1) Scrum practices & roles are considered to be ways of achieving particular intentions
2) The team needs to fit into the context of the organization
3) Any part of Scrum can be modified as long its intention is still retained. This may have you no longer be doing Scrum but you should still be doing some form of team-agility
4) It considers Scrum as a tool in a toolbox with other tools being needed (e.g., Kanban)
5) Scrum mostly works iterations & cross-functional teams are advisable
6) We don’t really care if we’re doing Scrum or not as long as we’re consistent with Lean principles
Lean-Scrum is an approach where use take what’s useful and leave what isn’t.
Be clear, Lean-Scrum is not Scrum. But my 19 years of doing & helping others do Scrum has demonstrated it is more effective
These two have to go together. The result of enhancement without simplification is complicated. The result of simplification without enhancement is simplistic. In tour complex world both of these extremes are high risk approaches.
In the “enhance alone” approach we have people trying to follow something that tends to grow over time. But this inherently creates confusion. People also don’t usually have the time to learn all of the necessary intricacies. What happens is they proceed with a limited understanding and make up things as they go forward. This causes confusion and going back to old habits.
In the “let’s keep it simple” approach, people are forced to figure things out to fill in the gaps. This may work for early adopters, but is not so good for others. The result is again going back to old habits.
We often hear proponents of frameworks following one of these approaches exclaim that things would work if people would only use the framework. But that ignores the reality of how people adopt new ideas. Without clarity, old habits return.
While it is difficult to create an elegant approach, it can be done, and you should not accept less.
There is no question that Agile at scale has crossed the chasm. I would say that even the late majority is now involved. But where are the innovators and early adopters now? I would say they are:
Using operating models instead of frameworks
Focusing on business agility
Driving from Lean principles
The use of scaled leraning
However, as I go to conferences & write posts on social media I see that these endeavors are not limited to innovators anymore but are being pursued by many early adopters – the so-called “pragmatists.” The “chasm” between early adopters and the early majority is already being crossed.
I am seeing more and more companies who are looking for what works, even if they have to fill in the blanks a little themselves. While frameworks provide set solutions with some leeway for filling in the blanks, they rarely fit organizations perfectly. Also, current frameworks are based more on Agile than on Lean (even SAFe which incorporates many Lean principles supports a bottom up implementation approach). I think (and hope) that 2019 will see a crossing the chasm of the above topics. To facilitate this is the purpose of my new book and some new social media collaborations. Let me know if you’re interested.
FLEX is based on a different mindset than current frameworks. Most frameworks have a set structure within which you can add practices. People want to know what to do and frameworks provide this. But the pervading idea is that at the beginning people must just adopt the framework. This has two bad side-effects which I believe are the causes of much of the bad Agile we see out there. The first is that the framework rarely fits the organization perfectly. A slight variance is not bad, but the disparity between the framework’s starting point and what would fit them better creates a dissonance. This not only hurts effectiveness but often creates resistance because the dissonance will create extra work for people who are already overloaded. The second side effect is that you are subtly teaching people to follow.
The way to solve these two challenges is not difficult but takes experience. The first is that some method of tailoring the framework or starting point must be used. The second is that you always emphasize the why of any practice and provide a method for improving or substituting it when challenges occur. Both of these can draw from the deep experience 20 years of Agile now provides – giving us patterns of challenge and success.
Experience has shown that virtually all workflow problems can be distilled down to delays in:
feedback after a decision or activity
These all not only delay value delivered but they literally increase the amount of work to be done. Lowering them is critical and can be done by:
Having small batches
Having a test-first attitude at acceptance and unit level
It is important to note that most frameworks’ practices work on these items indirectly. Consider the impact of time-boxing & retrospectives.
There is no reason not to work on these directly. One, of course, can add this to most any frameworks, but be forewarned, doing so will likely lead to activities inconsistent with the framework.
My belief is that frameworks should be designed by working on these issues directly & giving practices that support them as a starting point. Then as people learn more they can refine their practices. That way we can use the framework but not be limited to its practices while still being clear whether what we’re doing is good or not.