The history of lean and kanban is a challenge to boil down, so inevitably, I know there are aspects that are missing here. The title says “short” because, while there is a lot of information here, it is short in terms of how more is out there! Additionally, there are often disagreements on certain aspects and points around the history, and we’ve sourced the various elements included in this outline. A key part of understanding kanban is going beyond the principles and practices, to understand what is behind it work. The history points us to a critical key.
Delivery Process
Kanban Principles for Success (Part 2)
The kanban principles we use and I mention in What is Kanban? are fairly straightforward, yet often ignored in organizations who say they are doing kanban. I want to dig into a bit more depth on each of the principles, for those are are less familiar with them (or perhaps even for some that are).
What is Kanban (看板)? [Part 1]
This is a common question, since Kanban can have several word uses and meanings in the agile space. The term gets thrown around a lot, making it even more confusing. In order to understand Kanban and where it comes from, let’s start with some basic definitions and the foundations. We start with the basics, because there is often confusion around what kanban is.
Simple definitions of kanban:
- a signboard or billboard in Japanese
- a just-in-time method of inventory control, originally developed in Japanese automobile factories
- a Japanese lean manufacturing system in which the supply of components is regulated through the use of an instruction card sent along the production line
- an agile approach or framework
What to do when someone asks for an agile checklist or agile metrics checklist?
I hear these requests all the time. “What are the best agile metrics?”, “How can we measure an agile team?” and “I know we can’t just measure agile. . . but, what should be on an “organizational agility checklist?”
There are so many places you can go with these questions and there are even various companies selling ways to measure agile organizations and agile teams. When someone asks me about agility checklists or agile metrics, I tend to start with a few core themes of elements. I use these themes to have conversations with the people who want the measurements and the people who will be measured (before anyone starts using them).
Why Project Retrospectives Are Challenging
Project retrospectives are challenging. I spoke a bit about this in lessons learned vs. project retrospectives. You might look at a merger, acquisition, implementation of a new ERP system, or even a major upgrade of an ERP or CRM system. These are non-reoccurring events. A retrospective of this type is quite different from a typical agile retrospective, primarily because on this type of project, people will change and the project will not repeat (the definition of a project is that it is a unique endeavor). At issue here is the fact that if the people will not be the same and the project does not reoccur – then they can’t come up with actions they will apply right away based on what they learned. Ideas for change often just end up in a spreadsheet, a book shelf, or some electronic tool. A big book of “lessons learned” that sits on the shelf gathering dust does not provide much, if any, value.
Scrum Commitment or Forecast
I’ve been training, talking, coaching, and writing recently on the topic of commitment and realized that anytime that comes up, it reminds me of the old (seems old – but not really that old!) discussion on commitment or forecast. I still find there are many questions on this topic. It certainly has not been put to bed. The approach I like to take is to step back and ask “what is the real problem?” Is a word stopping you from succeeding or is something else causing the problem? What am I talking about? — I’m talking about when the Scrum Guide was updated to change commit to forecast.
Agile Safari – Best Agile Project Management Software
No, I don’t hate agile project management software — it can serve a purpose. At issue is if there is an actual purpose and if it is misused. Often the software stalls progress or worse, move us backwards. For any readers who are not familiar with agile or don’t work in software — the idea here is that instead of using the monitor to display some type of software tracking tool, the new scrum master just used sticky-notes and stuck them on the monitor. What is the simplest thing that works in your world?
Focusing Agile Retrospectives
The most common agile retrospective focus is on the sprint (or iteration) that was just completed. For most agile teams, this is the past two weeks. We have many more options for retrospectives than simply looking back on the last sprint. We can look at a specific topic, an event, use a future focus, or look at a much longer timeline. Regardless of the focus, we are aiming to learn, generate ideas, and (ideally) agree on actions to take moving forward to improve to sustain.
Bad Standard: Plus-Minus-Delta Agile Retrospectives
Many people dislike the 3 question, plus-minus-delta retrospective. I am one of them. The plus-minus-delta agile retrospective leads to many problems. I say it was never the “standard” in the title, so why are so many people confused? Or…am I the one confused?
While co-coaching recently, the other coach and I had a brief exchange about how the “standard” agile retrospective was not good. I was a little confused, since while I certainly do not always use ‘the standard’ or baseline agile retrospective, there is value to it — at least I thought so? The baseline retrospective I employ is a solid method to teach people how to do an agile retrospective. I asked a few more questions and realized that while we were both using the term “standard retrospective,” we had different definitions of the term.
Agile Area Rugs- Covering Opportunities with Longer Sprints?
Will longer agile sprints or iterations cover up opportunities to improve and cause you to view these opportunities as unsolvable problems?
The typical agile sprint size is 2 weeks. What percentage of teams use 2 weeks? I don’t have statistics on it, but I’d guess over 90%. I’m working on a product where we are doing 1 week sprints. It’s a startup and things are changing a lot so 1 week works well. I also know some teams that use 3 week sprints and it is working for them. I’m not saying it has to be a certain number of weeks – but please don’t kid yourself with what length will actually work for you.
I’ve seen situations where people are doing 3 week sprints, but then have a 1 week “hardening” sprint. Personally, I’m not a big fan of hardening sprints. I can see many “logical” arguments on why people need them, but in the 3+1 week sprints – I’d say stop kidding yourself. You have a 4 week sprint! Maybe that is the best you can do right now and you are ACTIVELY working to eliminate the hardening sprint – but if you believe you will always need one you are likely stuck.