Category Archives: Kanban
Agile or Lean or Agilean? There is a lot of confusion about the relationship between these two . Some people say they are completely different, some say they overlap and some say lean startup is a fusion of the two.
If we take a look at the Lean Software development principles according to Mary Poppendieck in her book on Lean Software Development:
- Eliminate Waste
- Build Quality In
- Create Knowledge
- Defer Commitment
- Deliver Fast
- Respect People
- Optimize the Whole.
Then we take a look at the original Agile manifesto.
We are uncovering better ways of developing
software by doing it and helping others do it.
Through this work we have come to value:
Individuals and interactions over
processes and tools
Working software over
Customer collaboration over
Responding to change over
following a plan
That is, while there is value in the items on
the right, we value the items on the left more.
There of course quite a few things that overlap it we dissect these statements.
“Eliminate Waste” is the principle of getting rid of things that don’t produce value. Retrospective is a very recommended practise where teams try to hone their process and see what is working and what isn’t. Essentially getting rid of waste.
“Build Quality In” seems to have similar qualities to “Working software”. Also Test Driven Development is a very common technical practise usually considered an “agile” practices. Also Poppendieck agrees this is essential to Lean when applied to software.
“Create Knowledge” underlies the importance of communication so that people know what they are doing and understand the problem domain the same way. This is again very essential to agile as well. The manifesto states that “customer collaboration over contract negotiation” which can be understood as a way of creating knowledge.
“Defer Commitment” has it’s relative in the agile world. Let’s take scrum for example. You only work on the items with top priority in the product backlog. You only work and talk about just enough items to fill the sprint backlog. All the rest are just titles. Product backlog item is just a promise of a further conversation.
“Respect People” is clearly similar to the first phrase of the manifesto “Individuals and interactions”. Both approaches put a lot of importance to people.
“Optimize the whole”. This might actually something where there is actual difference. Agile is very open to transparency and openness and scrum is very open to everyone attending defined practices like daily stand-up to listen or management participation is recommended for retrospectives, but still it is generally very concentrated on the development team.
Agile and Lean might not be equivalent, but they certainly have quite a lot in common when it comes to values, principles and even roots. I consider Lean to be an approach to improve effectiveness and it does have roots in manufacturing industry. Primarily Lean is about getting rid of things that are useless – in lean terms – waste. Agile on the other hand come into being when 17 experience software professionals got together and talked about giving a common name to practices they had found useful. Practises that were similar in nature: reactive, adaptive etc. A lot of those things also had roots in manufacturing industry, especially in the way Toyota worked and still works.
Saying Lean and Agile are not equivalent is one thing, saying they have nothing to do with each other is another.
Scrum is definitely the most successful agile methodology so far. Everywhere you go you can now hear the word scrum in the most absurd context. Scrum roles and titles have partly replaced more traditional titles.
Scrum becoming mainstream is not only it being superior to any other option. Today there are two major organizations offering their courses and certification services: Scrum Alliance & Scrum.org.
Kanban is not as far with certifications, but the kanban community seems to be heading that way as well. Last year the Lean-Kanban University started to hand out accredited kanban trainer -badges and more recently accredited kanban coach -badges appeared so the writing on the wall is clear.
Certifications might not be much to be proud of these days, but does not mean the classes are not any good. Still these classes are as good as the teacher and I for one got very lucky with the instructors I had in my both certified Scrum classes.
I had the privilege to attend a certified Scrum Master class by Jim Coplien and he is one of the so called gatekeepers of the official Scrum guide and he´s been around since the digital stone ages. As expected his expertise exceeds far beyond scrum and I still consider it the best crash course in agile. Later I had the chance to attend Scrum Product Owner class by Gabrielle Benefield and that also was as good as a two day class can be. Not because of Scrum, but because of the vast amount of experience she shared with us was not only enlightening, but also inspiring.
If my memory serves me correct, I attended the first official Kanban class by David Andersson in Finland. Kanban definitely has merit as a methodology, but you could still tell that the course content nor trainer was not as polished as the aforementioned Scrum counterparts. Now more and more Kanban trainers are popping up and with more trainers and organized courses the courses and their content will get better due to more experience in the kanban community.
Classes are as good as the trainers and the certificates are just a semi necessary by product. Certainly classes by different trainers have similar agendas, but the trainers definitely have more than enough room to accommodate attendee requests and add their own spice to it.
Still certificates themselves should not be considered essential. After all you can get a bunch of certificates even from w3schools.com. The bottom line is that although the certificate might not be much to brag about, these well established classes can still provide a lot of value.
Last week I had the pleasure of attending David Anderson’s two day class of Kanban. His analytical take on agile development was actually quite refreshing and you can always appreciate someone willing to share his vast experience.
I’m somewhat a statistical geek myself, so his preference to statistical information over estimates make a lot of sense and really sounds good to. Estimating is hard and pretty much useless after a while, when you have some decent statistics about velocity. There is still a place and need for splitting user stories to tasks.
Maybe the biggest surprise was that he doesn’t consider Kanban to be a software management process at all, it’s something applied to your current process. So starting from scratch is not an option, you need to have a starting point.
Other key point was how correct use of classes of service can drive to customer satisfaction. Classes of service and predictable lead time will drive customer satisfaction without a doubt.
On a side note I got a bunch of new tips what books to read. Specially Switch Switch – How To Change Things When Change Is Hard (Chip, Dan Heath) sounds like a book that could help me fight the emotional resistance that change always triggers in people.