I’ve been espousing (a nice word for rant) about the need for scaled learning methods and how 2-day classes have low retention. I’ve decided to integrate our On-the-Job Online Advanced Scrum Master / Kanban Coaching workshop with our Team-Agility Coach (our integration of Scrum/Kanban workshop.
Our online workshop is normally $595 but when you take our Scrum/Kanban master course we’ll include that for $200 a person. This means that our 2 day workshop followed by our 3 month program is $10,400 for 12 people ($500 for each additional person).
The onsite aspect of this integrates Scrum and Kanban. The three month program has me work with participants helping them apply what they’ve learned, as well as advanced topics of Agile, with their teams.
Please message me if you’re interested.
Using a predetermined set of roles, events, artifacts and rules is like having a GPS that just gives you the directions without the map. If you get lost or you can’t make a turn or you miss it you are lost.
Being given a map with alternatives to get there provides not only options that work for you but provide a way of getting back on track when you get lost. In the complex world of software development it is even more likely you’ll need this ability.
Many people require a given set path. But have it include where you are and have it provide you with a reset option when you get lost. This is what Lean-based team Agile does. Scrum doesn’t even try because you are out of Scrum by this time. Scrum proponents just call this Scrumbut and go on to the next team. This doesn’t mean you can’t use Scrum, it just means that when you do Scrum you should do it within the context of Lean.
Looking at differences between Scrum and Kanban can help us see which will work better for us.
1) Scrum requires planning the sprint ahead. You can plan in Kanban but it’s not necessary and normally isn’t done.
2) Scrum requires cross-functional teams, a good thing to have. Kanban doesn’t but this often misses the opportunity for team structure improvement.
3) Scrum requires starting with its roles, practices, events & artifacts. Kanban allows you to start where you are & provides a transition model for improvement.
4) Scrum improves by removing impediments. Kanban improves by focusing on shortening cycle time.
Teams that don’t like to be told what to do may resist Scrum. Kanban requires more discipline from the team than Scrum.
Factors to consider when deciding which to use:
* culture – including resistance to being told what to do and attachment to roles
* nature of work being done (plannable?)
* ability to create cross-functional teams
Note that executives can better relate to Kanban’s focus on flow. Combined with its insistence on visibility, executives can better understand the importance of managing workload.
In few cases is one clearly superior to the other. Taking a blend of the two often makes sense. Doing this is not difficult.
Given I’ve written 5 books, delivered 100s of courses/talks/ webinars, influenced Scrum, Kanban & SAFe, that’s a big statement. I think it’s true because I hope its introduction of proven methods of training/coaching developed at Harvard will prompt the Agile industry to improve current methods which I believe are outdated and one of the biggest impediments to the widespread adoption of effective Agile.
• Common training formats are ineffective and expensive. Intensive 2-4 day workshops have been shown to be the least effective method of conveying skills. These also incur the cost of lost days and possibly travel to take. Flipped classroom methods are both more effective and much less costly to deliver and incorporate follow up coaching
• Content. Being effective requires both Scrum and Kanban. Each are selective views of Lean, which is now recognized as a critical component of Agile beyond a team.
• Lack of a support system. There are patterns of challenge and solution which should be provided to students so they get assistance in solving problems on their own
Bottom line – this method can increase the effectiveness and content of a course while dramatically reducing real cost
You can learn more about this course here. Take the overview box (mostly black) for a 28 minute overview of the class that explains both content and format.
A development team working in harmony is a beautiful thing. Every two weeks they get together to decide what they are going to do over the next sprint, and then they proceed to do it. Daily retros keep them on track. Guided by a product owner the team incrementally builds their product increment. A demonstration at the end of the sprint produces value and important feedback to make sure they are going in the right direction. They get better each week with retros. Magic.
Getting to this may be a challenge, however. Well formed teams may not exist and it may be unclear how to make them happen when some people are needed by many teams. Also, the culture of an organization may be such that reorganization is not an easy move.
Another type of magic is possible, however. That’s when people make agreements to get any started work completed as soon as possible and not to start work if it will slow down more important work. They make all of their work visible to each other so they can work as a team even if they aren’t dedicated to it. They continuously improve with small changes. Also magic.
Any company that has more than a few teams can find magic in both approaches, but often only approach is magic for a particular team
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 way in which they differ. Other significant differences include how to start, how to improve, and how people should be organized. They are based on different theories of how to manage software development work and whether you need to change your roles. And this creates other differences such include the amount of discipline to use them and the cultures in which they fit. Continue reading “Why Agile Coaches Need to Know Both Scrum and Kanban”
1) management tells teams to do Scrum
2) they try but can’t. A common challenge is they don’t know how to break down big epics into small stories (which is often not taught in initial scrum training)
3) at some point they give up and do ScrumBut by not following sprints. They justify not doing Scrum by claiming that they are now doing Kanban (because they don’t have sprints). But they don’t do any of the things Kanban says to do. This is like saying “we do Agile because we don’t do documentation.”
4) their performance goes down
5) Scrum consultants are brought in and management is told the problem is “well, they’re not doing Scrum, can’t blame Scrum”
6) management tells the teams to do Scrum, because Kanban doesn’t work.
The solution is to teach Scrum, when it’s used for software development, with what is necessary to do software development.
The fact that Scrum can work anywhere works against you if you get generic Scrum training instead of Scrum training designed for you.
At a conference years ago Don Reinertsen & I were watching from the back of the room together & sometimes making comments between us about the presentations. At one point it was clear that there was a pattern of “this or that.” Don made a funny observation “these folks have been around 1s & 0s too long.” I had had the same feeling so laughed at his eloquence.
We’re still doing that. We look at Scrum as a thing & Kanban as a thing. Scrum has the cross-functional team be sacrosanct & David Anderson says “visualization not reorganization.” There is power to both. Both are proxies to what we need to do.
Conway’s law tells us “”organizations which design systems are constrained to produce designs which are copies of the communication structures of these organizations.” My corollary is that “When development groups change how their development staff are organized, their current application architecture will work against them.”
We have to recognize we’re in a very complex situation. Ultimately we need to have some simple guidance to help with decisions. The root of these are:
- make sure what you’re building has value
- look at time it takes from start to end (cycle time)
- shorten the time any part takes from start to completion
- attend to quality at each step
btw, if this looks like Lean to you that’s because it is. Lean, boileld down to its essence is:
- systems thinking
- just in time
- build quality in
I’m guessing most people are expecting me to talk about making a decision on whether to use Scrum or Kanban. But I don’t believe that’s the biggest decision to make. The first thing when starting Agile at the team is to ask “what’s in my way of creating and delivering value?”
Although Scrum proponents hail Scrum as a good way to figure this out there are other, faster methods available (mostly just look at your current situation and see where your blockages and large queues are – see Value Stream Impedance Scorecard for more).
Common challenges are:
- developers & testers don’t collaborate well together on stories
- people aren’t interacting well with each other
- the lack of cross-functional teams is causing delays
- work is not done in short cycles so feedback is hard to get
- teams are being overloaded with work
- teams don’t know how to write small stories
Clearly Scrum & Kanban both attempt to address this in their own way and it should be clear how each one addresses these. Your choice though is to learn a framework or method that helps you with these challenges or in your initial training work on them directly – and then adopt a Scrum/Kanban approach that best fits your situation.
People often conflate Scrum with Agile. But Scrum is not the same as Agile. Agile is considered by many to be a set of values, principles and way of being. Scrum is a framework consisting of roles, rules, artifacts and events. It is designed for teams to add those practices needed in order to become Agile.
XP is quite different. Continue reading “The biggest difference between Scrum, XP and Kanban”