Monday, February 1, 2016

What's the difference Scrum or Kanban?

Scrum or Kanban, that is the question that keeps coming up! But is it really an either/or question? Some people would have you choose. I believe they are complementary approaches and a pragmatic approach is to use each when appropriate. Let's look at what is Kanban, what is Scrum, and how they are similar and different.

Here's the short answer:

Both are reflective and adaptive. Kanban is focused on limiting work in progress whereas Scrum limits the time you can spend on a problem before you have to produce a result. If your product were a car, Scrum would be saying check your oil and tire pressure every month, and Kanban would be the warning lights on the dashboard that turn red when something is amiss. Both the maintenance intervals and the warning lights have value, and it would be silly to ignore either one.

Here's the long answer:

If I remember David Anderson's Kanban course correctly: Every sentence has a subject, a verb, and an elbow directed towards Scrum! OK, I exaggerate slightly ;-) Let's look at this more closely...

What is Kanban?

The purpose of Kanban is to create a culture of continuous improvement aka a "Kai-Zen Culture".  Kanban does not define a destination, but rather strives to create a culture that is willing to improve.

This essence of Kanban can be summed up in three steps:
  • Don't change anything. Change causes fear. Respect people and their roles. So leave existing roles and processes unchanged.
  • Agree to get better.
  • As a first step to improvement, visualize your work flow.
Visualization will enable you to see where things are getting stuck. When people see things are getting stuck, intelligent people people will generally do something about it. Limiting WIP creates a signaling mechanism, which is usually missing in Waterfall, to limit requests upstream and smooth out the flow.

I believe Alistair Cockburn phrased it this way: Kanban is reflective and adaptive, with reflection and adaption primarily triggered by examining the state of work.

What is Scrum?

Scrum is a simple, team-based framework for solving complex problems. Scrum is based on successful patterns for developing products. Scrum implements a small set of patterns:
  • Inspect and Adapt at regular intervals
  • An interdisciplinary team solves the problem
  • The team produces something the customer might value at regular intervals
  • One voice speaks for the customers and stakeholders
  • A coach helps the team and the organization get better
In the words of Alistair Cockburn: Scrum is reflective and adaptive, with reflection and adaption primarily triggered by time-boxing.

How are Scrum and Kanban similar?

Both are reflective and adaptive. Kanban is focused on WIP whereas Scrum uses Time-boxing. If your product were a car, Scrum would be saying check your oil and tires every month, and Kanban would be the warning lights on the dashboard that turn red when something is amiss.

When I listened to David Anderson talking about his case studies, I thought a mature Kanban team is surprisingly similar to a mature Scrum team. What the Scrum Community call sprint planing and review takes on a strategic character, features get done during the sprint., not just at the end of the Sprint. Stories need to be trimmed to size. Scrum has sprints, Kanban has "cadence." You can even limit WIP in a sprint.

How has Kanban influenced my teaching of Scrum?

I have recognized a couple of things:
  1. The easiest route to change starts with an agreement of the parties involved.
  2. If people look at how they work today, its well represented by Kanban
  3. If people think back to their best projects, they find a lot of commonality with Scrum. This recognition creates often creates a willingness to try Scrum.
  4. As it is primarily an attitude and a visualization tool, Kanban is applicable in some contexts where Scrum is not.
  5. As it is primarily an attitude and a visualization tool, Kanban does not directly address the people issues, especially at the team level.
If we consider our goal is to reach some mountain top called "High-Performance," then both Scrum and Kanban represent (I wish I could find and quote the coach who first made this analogy in a video -- can someone help me?). I believe Scrum represents are higher base camp than Kanban, but Scrum is not the destination, just a starting point.

I have found it most effective to consider Scrum to be a "reference implementation." No one will ever do it exactly like it is in the book, but they should do their best to get as close they can to the reference at the beginning. As they master it, their local improvements may very well take the team away from pure Scrum (think Spotify), but if they are inspecting and adapting frequently, it's OK.

By considering Scrum a point of departure, rather than a Nirvana to be achieved, we take away much of the pressure for compliance. This concept of Scrum as a standard to optimize from rather than a process to adhere to brings it philosophically in alignment with Kanban.

So I don't see an either-or. I use Kanban. I use Scrum. Let's get some work done!

Friday, October 9, 2015

10 Warning Signs, that your team is not self-organizing

How do you know that self-organization is working? The Bern Chapter of Scrum Breakfast Club looked into this questions, and identified the following warning signs (which I have taken the liberty of translating).

  1. The team reports to the Scrum Master at the Daily Scrum
  2. People wait for instructions from the Scrum Master
  3. Team members don't hold each other responsible [for their commitments]
  4. The same impediment comes up twice
  5. "That's the way it is" => resignation
  6. "I" instead of "We"
  7. Flip charts are lonely
  8. Culture of conflict-avoidance
  9. Decisions processes are unclear, nor are they discussed
  10. Personal goals are more important than team goals

To this list I would add my a couple of my favorites:
  1. you don't see a triangle on the task board (not working according prioritization of stories)
  2. after the daily Scrum, people return directly to their desks (no collaboration)
  3. there are a least as many stories in progress as team members (no pairing)

P.S. You can join the discussion or solve your own challenges at a future event! And here is the original list (in German).

EDIT: Here is the second slide:

  • Retrospectives are superficial
  • Agile Mindset Not Present => No inspect and adapt
  • The Team has no influence on the backlog (order, content, priority)
  • The Team is not interested in improving their performance
  • Changes in Team Composition are not managed by the Team
  • New members are not introduced by the whole team
(Suggestions for improved translation are most welcome!)

Wednesday, August 12, 2015

10 tips for doing Scrum when you're decentralized, part-time or doing other stuff you're not supposed to do

How do you use Scrum when you're
  • integrating existing packages, not developing software
  • deploying a visual design
  • working with a decentralized team
  • working with a part-time team?
The new Scrum Breakfast Club portal is based on Wordpress and who knows how many plugins. My part-time "team" and I have been working on this project for about 6 months. Calling us a team might be a bit optimistic, because we were:
  • 5 part-time people, 
  • located in two countries (6 hours apart)
  • working no more than 40% on the project
  • working for five different companies, and
  • only 2 people have been involved for the entire project.
Despite these obstacles, we did produce a cool product (IMHO) and we enjoy working together (also IMHO)!

As we have gone through process of creating Wordpress-based web presences using Scrum, I have learned a couple lessons which I will carry forward.
  1. Produce something that works every week. This is a wonderful constraint which prevents both individuals and the project as a whole from wandering off.
  2. Do functionality first. It's easier to get the design right when you know what the system is supposed to do. You may even iterate on your target audience, which would cause the design to change.  A good design requires understanding the deeper why of your system or product and its customer and users. Especially in a startup context, it may take awhile for that to emerge.
  3. You can iterate on design. An excellent template architecture is a helpful, so most of the changes are in CSS. In our case:
    • Version 1 focused on functionality only. It had just enough design, standard templates really, so that we could work with the system. 
    • Version 2 was slightly embarrassing, but more or less attractive. People could work with it, but there was some stuff that was bad or downright evil in design or usability. 
    • Version 3 - what we are about to publish - is something for the public, and even here, we are implementing it in iterations 3.1, 3.2, 3.3 etc. We designed for the overall goal (market, usability). We started implementing and deploying with the most visible pages. Then polish and minor pages.
    • Don't break stuff that already works. 
    • Postpone activating design elements that require new functionality, until the corresponding functionality is present. For example, we want to do some fancy pop-open login and registration widgets, but those are going to wait until we can implement them.
  4. Trello is your friend for communication. Trello is nice lightweight Kanban board. Our workflow is basically: Backlog->Ready->Forecast->In Progress->Ready to Review->Ready to Deploy->Done. We use tags, columns and email notifications to enable rapid and effective communication throughout the team.
  5. Focus on getting things done. We agreed to always pull from the rightmost column on the board. Spillover, is almost always sign of something bad. The story might be too big; the acceptance criteria might not be clear; the team member might be working on something else. or the team worked on it at the last minute. 
  6. Grow up, then grow out. First we added functionality to Wordpress, often in the form of a new plugin. Then we discovered what we broke. Since many plugins are poorly documented, and the interactions between them even less so, we couldn't always prevent things from breaking. So we fixed everything we could find before moving on to new functionality. Basically a stop the line mentality. In Trello, we added a column "Bugs" and tagged the items in yellow. If a bug was present, it was handled with top priority. This is getting things really done!
  7. Definition of ready is your friend for getting things done. For each column in our Trello workflow, we created a permanent card with the definition of ready to enter that column. To enter the Ready column, each story had to have a how-to-demo checklist. This makes it much easier to know how to implement the story and how to confirm that we have achieved the goal during the Review. To leave Ready and enter the Forecast column, the team (member) had to be confident they could get the story by the end of the sprint.
  8. Do the work at the beginning of the sprint. Did I say get stuff done? Get it done early. The biggest danger with part-time staff is that they work on other things until they feel they can't postpone your stuff any longer. If they do their 20% on the first day of the sprint rather than the last, their chances of getting stuff done are much higher! Getting stuff done also removes a major source of tension between the players in the project.
  9. Wordpress is the friend I love to hate. There is plugin for that. Yes, and the interactions between those plugins can be quite unpredictable. It enabled us to get started quickly, but I suspect before our product is done we will have reimplemented all of the key plugins to suit our needs. I'm not complaining, because my site is live and I can generate potentially revenue to pay for that development.
  10. Automation is your dearest friend. This includes virtualization, backup and source code control. Yesterday, a system programming error during the sprint review managed to destroy all three instances of our system. Embarrassing, but...  We recovered the system by creating a new virtual machine on linode from the daily backup, restored the Wordpress configuration (database) from the daily Updraft Plus backup, and the current file configuration from the source code control. 45 minutes later we were back online and there was no impact on our schedule. If fact, we are actually deploying a week earlier than I had hoped! We will also get better reliability, because this incident convinced us to separate test and production on separate nodes.
As a final thought, for me as Product Owner (and entrepreneur), Sprint Planning is an opportunity to ask:
What is the best possible step forward for the business, given what I know today?

The answer might not be software development. I ask myself that question every week, and it really helps me to do the right thing!

Monday, July 27, 2015

Is your Scrum User Group really a user group?

Ken Schwaber recently chided the Scrum Alliance for having a trademark on the term "Scrum User Group." Man! There is something about the way divorced couples can fight forever through their kids. I'd like to ignore the couple for a moment, and talk about the children: What is the state of user groups in the Scrum and Agile community?

After a period of working too hard, I have been able to attend a few user group meetings this year. A couple of patterns have stood out for me. Patterns that don't feel right, but maybe I am exaggerating? Do you recognise any of these?
  • The user group is associated with an agile consultancy.
  • The user group event starts with some promotion of said consultancy.
  • The user group doesn't have a website or even a meet-up page.
  • The user group website is mostly promoting high-value courses.
  • Membership is free (just sign up for our mailing list).
  • The user group event is mostly attended by beginners 
  • The only really experienced Agilist present is the group's host.
  • The user group events are mostly talks by managers, coaches or trainers (in other words, they are a form of self-promotion).
Is a user group more than a marketing arm of a consultancy? Or am I being too harsh? What is your experience with Scrum user groups? What do you think a good user group should be?

Tuesday, July 7, 2015

What powerful questions does Scrum help you answer?

The video on powerful questions made me think about the deeper purpose of the various Scrum activities. Can I formulate Scrum as a series of Powerful Questions to be general enough, that they might be useful outside of software development? Here is the image I came up with and below are the questions I think each of the Scrum Activities and artefacts strives to help you answer.


  • The Sprint is a container to limit ourselves to setting reasonable medium-term goals. 
  • What can we reasonably expect to accomplish by the end of the sprint?


  • How will our efforts make the world a better place?
  • Who needs our product and why?
  • Why should we build it?

Product Backlog

  • What characteristics should our product have?
  • What goals must we accomplish to achieve our vision?

Backlog Refinement

  • What could we do to get us closer to our vision?
  • What small steps could take us nearer to our goal?
  • How can we make the steps smaller and more likely of success?

Sprint Planning

  • Part 1 - What is the best possible step forward, given what we know today?
  • Part 2 - How can we accomplish these steps?

Daily Scrum

  • What are our goals for the day?
  • How will we accomplish them?
  • What help do we need?
  • Who needs to talk about what?
  • What could be slowing us down?

Sprint Review

  • What have we accomplished or learned?
  • How does this change our vision?


  • How can we work more effectively?
  • What could be slowing us down?

Definition of Done

  • How do we know a step was successful?
  • How do we ensure the quality of our work?
  • How do we know that what was done in the last sprint is still done in this sprint?

Monday, July 6, 2015

What is a powerful question?

Have you ever noticed that some questions cause people to pause and think before answering, while others provoke an automatic, non-constructive response? What's the difference?

Powerful questions challenge you to think deeply and often help to get unstuck and find solutions to your difficult, challenging problems.

At the Product Owner Camp #POcampCH in Sursee Agile Filmakers extrrodinaires Karen Greaves and Sam Laing led our group through the creation of a short educational video on Powerful Questions.

In one hour, we learned about Powerful Questions, the 4-C's teaching method, (Connection, Content, Concrete Examples and Conclusions) and how to make an attractive educational video.

Thanks to Karen and Sam, plus Deb Hartmann, Véronique Hyde, and Yves Bertrand for a great collaborative learning experience!

Saturday, May 9, 2015

More tips for CST Aspirants

What does it take to become a Certified Scrum Trainer (CST)? Passion and Energy. You should stand out from the crowd!

Aspirant: How high do we have to climb?
TAC: What we really want is someone who can leap tall buildings in a single bound!
The Scrum Alliance Trainer Acceptance Committee held its first ever workshop for CST Aspirants last week at SGPHX, the Phoenix Scrum Gathering. This gave candidates a chance to ask questions and understand what is really expected of a CST to get through the final examination.

The answers to two questions really stood out for me in this workshop:

  • Why do I have to submit my own learning materials?
  • How many students must I have taught?

Why do you have to submit your own learning materials?

Many Aspirants today work for a company that has already created a "deck" for teaching Scrum. I am told that even requires their trainers to train to a standardized deck. Why reinvent the wheel? 

If an Aspirant is using someone else's materials, here is a typical conversation during the final interview:
  • Examiner: What does this diagram on page 35 mean?
  • Aspirant: <dances around the question without really answering it>
  • Examiner: Try again. What does it really mean?
  • Aspirant: I'm not sure. It's something the company put in, but I don't really use it in my course.
A CST must know their stuff! A CST should not be training materials that they do not understand or support fully. If you don't create it, it's almost impossible to learn it well enough to teach from it effectively and without blind spots.

How many students must you teach?

The Scrum Alliance requires an Aspirant to have taught at least 100 students in CSM-like context (2 day course). This should demonstrate that you are capable of doing the job of a CST. 

Does training 100 students guarantee that you will be accepted? No.

The Scrum Alliance wants its trainers to come from the top 1%. That top 1% are the people who motivate and convince others to want to do Scrum and do it well. You're job is to convince the TAC that you belong there already, so all they have to do is recognize your accomplishment!

A CST is not merely a trainer. A CST is an ambassador of Scrum. So the criteria on the Scrum Alliance website are perhaps best to be understood not as acceptance criteria, but as exclusion criteria. If you don't meet these criteria, don't bother applying. If your objective is simply to satisfy the absolute minimum requirements necessary, then you probably haven't understood what being a CST is really about, and are therefore unlikely to pass.

What does it take to become a CST?

Above all else, perseverance! Don't give up. Not everyone makes on the first try. I needed four tries, an extreme case, to be sure, but many need two tries to get through, and some very good trainers even needed three. Passion, energy, and perseverance! 

P.S. To my padawans who came up for evaluation in Phoenix: Congratulations and high fives to Joe Justice! Joe needed two tries to get through. And to Lizzie Morris, I say don't give up! Both of you are awesome trainers who deserve to be recognized as such!

P.P.S. Are you a CST Aspirant? If are on the path to becoming CST, check out our network