Lean

Lean Tribe 30 – Adjustable organizations

Last week I visited a Lean Tribe here in Stockholm. It was number 30 in the order, and the theme this time was adjustable organizations. First seven short speeches (ten minutes each), an open space, and then the evening ended with a new thing for lean tribe, a keynote. It was Henrik Kniberg who shared his experiences with SAFe@Lego. SAFe stands for Scalable Agile Framework. I appreciated all presentations, as well as the individual conversations in between.

I’ve turned my personal notes from this four hour event long into the presentation below.

All the best,
 Tomas from TheAgileist

Crisp vs. Modus Cooperandi

Welcome, today I have something a bit out of the ordinary. This blog post is a reflection about two very influential companies in the world of lean and agile.

””Crisp

Crisp

When you first look at Crisp’s homepage, they look just like any other consultant company. Crisp offers agile experts that develop and improve products, methods, processes, teams and organizations. Nothing in particular about that. However, if you dig deeper (and know where to look) Crisp is quite an amazing company. They have developed a very specific company DNA, and they have even published it as open-source! None of the 30+ consultants are employed by Crisp. There are no managers, not even a CEO. The main purpose of the company is to make their consultants happy. The consultants are 100% autonomous. ”Is this true? Can this really work?”, you might ask. You can try it our for yourself, start by copying the Crisp DNA.

My reason for this blog post is however not the DNA, but rather the specular agile footprint that Crisp have. Henrik Kniberg works for Crisp. I guess you can say that he is ”the number one agile person” in Sweden, with admirable experiences from companies like Spotify and Lego. Now you might think that being good at agile is a team effort and not a ”one man show”, and of course you are correct! Let’s look at what Henrik’s colleagues at Crisp have contributed with to the world of agile. You can can count number of blog posts, how often they speak at conferences and so on, but I have chosen to look at books that they have written. I think that writing a book shows the highest form of commitment and willingness to share your knowledge.

Books on lean and agile from Crisp

Using a popular online book store here in Sweden, I search for their respective names and here is the list I got back:

  • ”Prioritera, fokusera, leverera : din snabbguide till Lean, Agile, Scrum och XP”, book in Swedish written by Hans Brattberg and Tomas Björkholm
  • ”Jennie discovers! – insights, trumps, ideas : a book about agile and lean”, short book written by Hans Brattberg & Jimmy Janlén
  • ”Scrum and XP from the Trenches”, by Henrik Kniberg
  • ”Kanban and Scrum – Making the Most of Both”, by Henrik Kniberg and Mattias Skarin
  • ”Lean from the Trenches: Managing Large-Scale Projects with Kanban”, by Henrik Kniberg
  • ”Real-World Kanban: Do Less, Accomplish More with Lean Thinking”, by Mattias Skarin
  • ”Tillsammans : så skapar du flyt och egenmakt med agile och lean”, book in Swedish written by Peter Antman
  • ”Kanban in 30 Days”, by Tomas Björkholm and Jannika Björkholm (not working at Crisp)

That is quite an impressive collection of eight books on lean and agile! Four of them covering Kanban. I also happen to know that Jimmy Janlén (since I follow him on twitter) is working with another book called ”Visualization examples” that soon will be release to make nine books on the list. Is this unique in the world? Can there be any other companies this influential in agile?

Modus Cooperandi

The only one that I can think of is Modus Cooperandi. It is a small consulting company owned and operated by Jim Benson and Tonianne DiMaria Berry. From ”Personal Kanban” written by Jim and Tonianne, I recall that Modus was started in 2008 by there persons, namely Corey Ladas, David J. Anderson and Jim Benson! How about that for tres amigos in agile!

Books on lean and agile from Modus Cooperandi

Using a popular American online book store, I search for their respective names and here is the list I got back:

  • ”Scrumban: Essays on Kanban Systems for Lean Software Development”, by Corey Ladas
  • ”Kanban”, by David J. Anderson
  • ”Agile Management for Software Engineering: Applying the Theory of Constraints for Business Results”, by David J. Anderson
  • ”Lessons in Agile Management: On the Road to Kanban”, by David J. Anderson
  • ”Personal Kanban: Mapping Work | Navigating Life”, by Jim Benson and Tonianne DiMaria Berry
  • ”Why Plans Fail: Cognitive Bias, Decision Making, and Your Business”, by Jim Benson
  • ”Why Limit WIP”, by Jim Benson
  • ”Beyond Agile: Tales of Continuous Improvement”, co-authored by Jim Benson with Maritza van den Heuvel & Joanne Ho (last two not working at Modus)

A long lists that sums up to the total number of *drumroll* eight books! Among those books I consider both ”Kanban” and ”Personal Kanban” to be a monumental pieces in the spreading of Kanban.

Summary

So, who won this competition? Exactly the same number of books calls for a draw. As a Swede I of course think that it’s fascinating that a small company like Crisp can be so influential in the agile world. Especially when it comes to Kanban. In fact, I found a review that claims that ”the best books on Kanban come from North European authors”!

All the best,
 Tomas from TheAgileist

Note: Both Corey Ladas and David J. Anderson are no longer working for Modus Cooperandi.

Disclaimer: I’m not in any means associated with Crisp or Modus Cooperandi.

The Phoenix Project

Update: Now the “squel” to this book is out, it’s called “The Unicorn Project” and you find my review here.

A friend of mine, who also happens to be an agileist, suggested that I should read the book ”The Phoenix Project”.  It’s written by Gene Kim, Kevin Behr and George Spafford and was originally released in 2013. On the cover the following is stated: ”A Novel About IT, DevOps, and Helping Your Business Win”. A novel? Yes, a novel so you can say that the format is different than most of the other agile books out there. I like this format, the story is interesting, and it is easy to keep on reading chapter after chapter.

””The

Content

The book has 35 chapters separated in three parts, but I guess you all wonder what the novel is all about? The story starts in part one when Bill Palmer gets promoted and become VP IT Operations at the company Parts Unlimited. The company was really struggling and a gigantic project named Phoenix was launched in order to save Parts Unlimited. When Phoenix was put into production, it all failed and was deemed a huge disaster. This went hand in hand with other catastrophes within the IT operations (for example no salaries from the payment system and so on).

In part two Bill gets in contact with a lean ”guru” whose name was Erik. He arranged for Bill to visit a manufacturing company to study lean. Erik starts to act as a mentor to Bill, and with this help he manages to bring some order into IT Operations to start a turnaround. In the final part a new project Unicorn is launched, it is all the good parts from Phoenix but done in an agile way. Now things really get going and using DevOps the development- and operations-departments are working together to achieve success! The goal they are striving for is to deploy to production ten times a day!

Takeaways

First of all, I take with me that change must come from some sort of failure or crisis. Without pain there is nothing to gain, and status quo will prevail. Second it’s the concept of a work center that is made up of four things:

  • The machine
  • The man
  • The method
  • The measures

A deployment pipeline is the entire value stream from code check-in to production. Everything needs to be version controlled. The term DevOps is referred to as the outcome of applying Lean principles to the IT value stream.

The Three ways describes the underpinning principles of DevOps:

  • The first way is about the left-to-right flow of work from Development to IT Operations to the customer.
  • The second way is about the constant flow of fast feedback from right-to-left at all stages of the value stream.
  • The third way is about creating a culture that fosters two things: continual experimentation and understanding that repetition and practice is the prerequisite to mastery.

Finally the four types of work that IT does:

  • Business projects
  • Internal IT projects
  • Changes
  • Unplanned work or recovery work

Recommendation

A novel and the story presented in this book is a very pleasant and nice way to to learn new things. If you want to now more about DevOps I can really recommend this book!

All the best,
 Tomas from TheAgileist

Learning Agile

I have to admit, I have a little quest going on. To read all books that come up on the first page (12 items) when searching for the word ”Kanban” in Books on Amazon.com (sorted by relevance). It’s a fun quest, but I don’t know if I will ever complete it though, since the search result keeps on changing over time 🙂 Anyhow, in that quest, I have read ”Learning Agile” by Andrew Stellman and Jennifer Greene. The book was released in November 2014 and the sub title is ”Understanding Scrum, XP, Lean, and Kanban”.

””Learning

Content

The book has ten chapters and they are:

  1. Learning Agile
  2. Understanding Agile Values
  3. The Agile Principles
  4. Scrum and Self-Organizing Teams
  5. Scrum Planning and Collective Management
  6. XP and Embracing Change
  7. XP, Simplicity, and Incremental Design
  8. Lean, Eliminating Waste, and Seeing the Whole
  9. Kanban, Flow, and Constantly Improving
  10. The Agile Coach.

The first chapter sets the agenda for the book by presenting what Agile is (”Agile is a set of methods and methodologies that help your team to think more effectively, work more efficiently, and make better decisions”) and how it is structured.

In the second chapter the Manifesto for Agile Software Development is introduced. This and all the following chapters are structured in a very pedagogical way. The subjects are first described in ”plain text”, broad up again in a narrative (fictive stories), summed up as key points and finished off as a FAQ (Frequently Asked Questions). This redundancy is intentional according to the authors ”we do it to help you get that ’aha’ moment”. For me, that have read a few other books on Agile, this gets a little boring and time consuming with all the repetition. The book spans 420 pages which could have, in my option, been less to be a truly ”agile” book.

Moving on, the third chapter explains The 12 Principles of Agile Software in greater detail. This is a good chapter to get a deeper understanding of the Agile principles!

Forth chapter starts off with a good slogan from the board game Othello: ”A minute to learn, a lifetime to master”. This can be applied to all Agile methodologies described in this book (well, maybe not just a minute to learn, but they are all very simple to get started with but needs a lot of practice to ”master”). If you want to know the basics of Scrum, you can download the official Scrum Guide. More in this chapter are the five Scrum values:

  • Courage
  • Commitment
  • Respect
  • Focus
  • Openness.

Chapter 5 completes Scrum, it has a reference to a survey (on page 142) that states that 64% of the features in software is never used! It can be due to something called gold-plating. Developers that, with the best of intent, throw in extra functionality that never has been requested.

Chapter 6 & 7 covers XP (eXtreme Programming) that has similarities with Scrum. A personal takeaway from this section (though I’m not programming anymore) was the section about code smells or anti patterns (”a pattern of behavior that a team exhibits that cause problems with the project”). Those being listed are:

  • Shotgun surgery – A small change to one part of the code requires another change in another part of the code than in turn requires yet another change somewhere else in the code and so on.
  • Half-baked code – An object that needs to initialize other (irrelevant) objects as well to be used.
  • Very large classes – Hard to read and maintain.
  • Duplicated code – Identical (or almost identical) blocks of code that does the same thing.
  • Spaghetti code – Code with complex and tangled structure.
  • Lasagna code – Too many layers.
  • Hook – A hook added for future use (but then never used).
  • Edge case – Code that handles an edge case that seldom (never) will happen but makes the ”normal flow” much more complex to understand and maintain.

”A system that’s designed to immediately report a failure as soon as it happens is called a fast-fail system” – Andrew Stellman & Jennifer Greene

I would also like to list the XP practices:

  • Pair programming
  • Continuous integration
  • Energized work
  • Ten-minute build
  • Incremental design
  • Whole team
  • Refactoring
  • Sit together
  • Test-driven development.

Chapter 8 talks about Lean that is a mindset with its own values and principles. The values are:

  • Eliminate waste
  • Amplify learning
  • Decide as late as possible
  • Deliver as fast as possible
  • Empower the team
  • Build integrity in
  • See the whole.

Reaching the end here, chapter 9 is about Kanban, flow and constantly improving (kaizen). Not so much new stuff for me here, once again WIP (Work in Process) limits are enforced and described as the ”secret sauce” behind Kanban.

”Kanban is about helping a team improve the way that they build software” – Andrew Stellman & Jennifer Greene

Final chapter tells you about the agile coach that helps the team adopt agile. The team needs an agile mindset to be successful with an agile methodology.

Recommendation

If your are new to Agile, and have a lot of time to read, I can recommend this book to get more knowledge about Scrum, XP, Lean and Kanban. If you only want to know about a specific method, or have short of time, there are other more suitable books around.

All the best,
 Tomas from TheAgileist

Tillsammans / Together

This is the first time I do a review on a book written in Swedish, my native language. I realize that many of you will never get a opportunity to read the book, but according to my blog statistics Sweden is in third place when it comes to visitors (after USA and UK). The book is ”Tillsammans” (”Together”) with the sub title ”Så skapar du flyt och egenmakt med agile och lean” written by Peter Antman (@peterantman on Twitter).

””Tillsammans/Together””

Content

According to the table of content the book has three main parts/chapters and they are:

  • ”Flyt och kunskap med agile och lean” (”Flow and knowledge with agile and lean”)
  • ”Team – en agile organism” (”Team – an agile organism”)
  • ”När chefen inte längre leder och fördelar arbetet” (”When the manager is no longer acting in ’command & control’-mode”)

For all of you to understand I will stick to English from now on (i.e., I’ve done my own translation from Swedish to English, any mistakes during that process is mine only). Instead of a formal review that I usually do, I will give you five short stories/lists that are presented in the book. I hope you enjoy them.

”Bread maker”
This history from the 1980s tells that the management at Matsushita (now Panasonic, a Japanese multinational electronics corporation – my comment) had formulated an idea of a kitchen appliance that could bake bread. The vision was that you should be able to get up in the morning and smell fresh bread without too much work. The engineers were not able to complete the bread maker, no matter how much work they put in. The bread never turned out good enough. Finally someone asked: ”Can we actually bake bread?”. The engineers had to leave the drawing board and go to practice at the best bakery in Tokyo. When they returned, they rather quickly solved the problems and got the bread maker to work.

My comment: This story tells me that you really need to know your product, and of course the customers that shall use it.

”Broken windows”
The broken window theory was introduced in 1982 by two social scientists. Most of us are familiar with it: Someone breaks a window. If it’s quickly fixed, broken windows will happen but it is not the normal state. But if it’s not fixed? Then people stop caring and persons that normally behave is more likely to also smash a window.

My comment: What can we learn from this? My takeaway is that we alway should strive for highest quality. That we have 100% pass on our tests. If it drops lower, even with ”known errors”, we start to care less.

”Go green”
During several years the metaphor ”go green” was very important for Peter Antman’s working life. Put in context it was filled with purpose; focus on quality, tests, visual feedback and hard work. In the working group the metaphor became part of their culture, and affected their mental picture of the reality and their acting within it.

My comment: ”Go green” relates back to the previous story, where ”green” means pass on all tests. ”Green” shall be the normal state. If an error is introduced, i.e., the tests will go ”red”, it shall be fixed as soon as possible to go back to the normal ”green” state. Hard work is required to get this up and running, so it has to be in the mindset of the teams.

”Grow an agile culture – With phrases”
For Peter Antman and his teams the essence of scrum, agile and lean could be expressed in a few key phrases, they were:

  • Last responsible moment
  • One-piece-flow
  • Adapt to capacity
  • Cult of quality
  • Stop-the-line
  • Art of the possible
  • Always releasable
  • Inspect & Adapt
  • Take it to the team.

My comment: All things on the list above is explained in more detail in the book.

”Agile mindset”
The last list from the book that I would like to share with you holds the foundation of agile thinking, with respect for human beings and our capability to do good work when we are not limited by things out of our control. We emphasize:

  • Self-organizing teams are our lowest organizational unit.
  • People are driven by intrinsic motivation and we need to let it free.
  • We focus on value and to only do things when they are needed.
  • It’s pointless to have detailed long term plans since the reality will always change.
  • We have short feedback loops since we constantly need to learn new things.
  • It’s the system we change when we try to correct things that are not working.

My comment: I can only agree with this list!

Recommendation

I can recommend this book if you want to read about Lean & Agile in the Swedish language. There’s not so many books available about that in Swedish, hopefully this one can increase the understanding beyond the IT department in companies throughout Sweden and the other Nordic countries.

All the best,
 Tomas from TheAgileist

The Essence of Flow

Summertime is here, and for many of us that means vacation. During the vacation period I can take time to do more reading than I normally do. Do you want to do some more reading as well? Maybe I can interest you in my article ”The Essence of Flow”, that has been published on InfoQ.

””The

(Picture taken from http://www.infoq.com)

Here is a short description:

”How do you get good flow? A common scenario in a software company is that too much is going on at once. We need a shift in mindset, to go from focus on resource efficiency to focus on flow efficiency.”

You can read the full article here.

All the best,
 Tomas from TheAgileist

WIP limits

In a previous blog post I mentioned that we are in a transition from Scrum to Kanban. Or to be more precise, we have been using Kanban for almost a year, but some of the ”Scrum thinking” is still present in our teams. This doesn’t necessarily have to be a bad thing, but one thing we are really struggling with, is putting limits on WIP (work in process).

””Kanban

Can you see, there is something missing in the picture above?

Yes, you are correct, there are no explicit WIP limits present. Putting limits on work in process is essential to achieve flow through your work process and it also ”high-lights” problems that are candidates to be fixed in the name of kaizen (continuous improvements to your process). The WIP limits were there initially, but the teams didn’t see ”the meaning” with them, and removed them (after all, the teams are autonomous). In trying to put the WIP limit ”back” on the Kanban boards, I seek help from some fellows in the Kanban community. Their answers to my question ”How do you get the teams to use WIP limits?” are found below.

Mike Burrows

Mike seems to be a really nice guy and he is also the author of ”Kanban from the Inside”, find my review of this book here.

I tend to approach the question of limits rather indirectly, and (as you’ll know from my book) I’m interested in more than just column limits, being open to limiting WIP in multiple, cross-cutting ways. Tips?

1) I tend to start from the right hand side of the board, looking at the flow of work through (say) validation, deployment, acceptance etc. Not much point in optimizing the flow through development if the work is only going to pile up somewhere else.

2) I’m careful not to celebrate partially-done work (eg in status reports) and to report cycle times that go beyond development.

3) I like to organize work horizontally also and to explore the allocation of effort across those. In my current situation I’m seeing an interesting difference in performance between two workstreams that could be explained by a lack of discipline with regard to WIP.

Marcus Hammarberg

Marcus has helped us a lot. We are even reading the book that he co-authored, ”Kanban in Action”, as a book circle at work. I’ve also made a review of this book.

Hmm, I’ve seen this myself also. I think the most important thing is not to enforce anything: ”DO LIKE THIS! NOW!! This will only lead to alienation and the team will not feel that they ’own’ their Kanban board.

Ask the team – this is simplest, and hardest way; why is it that we always have more things to do than our WIP limit states? Is it too low? Why? I think it is also important to understand that WIP limits is not a law or a ”correct number”. It is a tool to find improvements. Breaching a WIP limit shall trigger a discussion; ”fine we are beaching the WIP limit now, but we do it on purpose”. Some teams that I heard about had a mini-retrospective each time it happened.

Summary

So how did we actually solve the problem? I leave you with a ”cliff hanger” for next week, when I present our approach in limiting WIP 🙂

All the best,
 Tomas from TheAgileist