That Was the Year That Was

I’ve promised
myself I would actually take some vacation this week, and fortunately
with small children in the house, it’s actually possible to do
so! So, before the kids wake up, a blitz retrospective: High Points,
Low Points and Potential for Improvement in 2009.

High Points

  • Becoming an
    independent Scrum
    Trainer and Coach
    . I really want my customers to say
    thank you for the work I do for them — while I am not averse to
    getting paid, a satisfied customer is what makes it all worthwhile.

  • Scrum
    Breakfast
    Community became the Swiss
    ICT Lean Agile Scrum Group
    . I figured as a one man
    show, I could never mount a “real” marketing campaign,
    so instead, I set out to build a community. This community helps build acceptance for
    Scrum (and by implication, my services). But a community only
    functions effectively if it the community belongs to its members.
    And when it does, it takes on a life of its own!

  • Quick
    Polls
    on my blog. I started doing them because they
    were good for getting attention. I like to think my poll on the
    Nokia test helped the Scrum Community discover Scrum-Butt
    and think about its implications.

  • CSM Course with
    Andreas Schliep. There is a lot of debate about the value
    of the CSM course and certification
    . Together with
    CST Andi, I have now stood on the other side of the podium and for
    me the value of a good CSM Course to the participant is clear. The
    students learn from the teachers and from each other in ways that
    you just can’t get from a book. Offering Scrum
    training
    has been a clear win on the
    “I-define-success-through-customer-satisfaction” scale.

  • Writing for
    AgileSoftwareDevelopment.com.
    When I look back at my first article… well… (blush). This has been a tremendous learning opportunity.
    Thank you Artem for providing this forum and for your editorial encouragement!

Low Points

  • The recession.
    Personally I think this economic Tsunami is going to resemble the
    storm Lothar, which knocked down some forests entirely, but left
    others nearby completely untouched (I am an optimist, and no, I have
    no idea which areas will emerge unscathed). Fundamentally, companies are
    successful by producing great products and services. Agile helps
    companies do that and companies will be under pressure to improve
    their performance. The time to start a conversation with management
    about Scrum and Agile has never been better.

  • You can lead a
    horse to water, but you can’t make him think. Sometimes you
    advise a customer, but he wants to stick with his old habits. Smile.
    Accept Fate. Maybe he’ll be around in year to ask for your
    advice again.

  • You can lead
    the horse to water and he’ll think what he wants! There are
    people out there who ask whether ‘Scrum
    has failed us
    ’ or that Scrum is not enough and
    look for other solutions. Some people will find their answers in
    Lean, some in XP, some even in RUP. One of my first coaching
    customers decided he liked Scrum Ban
    better and tried to get me interested. I wasn’t having any of
    it. In retrospect, I wish I had shown more interest — even though I am still convinced on Scrum !

  • Criticism of
    Scrum and Agile. There’s been both criticism of Scrum from
    within
    the agile community
    and more general criticism
    of agile from outside. Agile has become a buzz word which is getting
    applied way outside its original context. I think this is both
    healthy and a sign that Management is getting interested in the
    topic and a much larger segment of the population is being
    confronted with agile ideas.

Potential for Improvement

  • Community is the key to
    success, both at a personal level and an ideological level. If you
    want to do Scrum, Lean or Agile, then build and participate in the
    Agile community in your area. You help make it politically
    acceptable to do Agile, you create a support group, and you create a
    network which will help you find work you like.

  • I would like the Scrum
    community to better embrace growth and change. There are people out
    there such as Boris Gloger (with his vision of 3
    + 3 Rolls
    in Scrum) or Alan Shalloway (with his
    fusion of Lean,
    Scrum and Emergent Design
    ) who are enhancing Scrum in
    interesting ways. The beauty of Scrum is its simplicity and
    universality (hint: try holding a daily scrum with your spouse or
    using a task board to help your kids get ready for school each
    day) which mustn’t be compromised. But the simplicity of Scrum
    means we need other
    building blocks
    to achieve the whole project effectively.

  • My first New
    Year’s resolution is to listen better to all agile
    philosophies to better advise my customers. There is no monopoly on
    the truth. Personally, I look first to Scrum and then to Lean for
    management issues and to XP for engineering issues. But there are
    new ideas out there and many are worth looking at. And even old
    ideas have their merits.

  • My second New
    Year’s resolution is to listen better to my customers (and
    readers). In that vein, I have published a doodle
    – what would you like to read about
    ?

A parting wish

Do something! For each individual
company, the key to turning the recession around is getting your
customers to buy your products and services. So get together with
your best people, give yourselves three months, and create a great
new product that you can sell in Q2.

At this point, I
would like to wish everyone a good and productive start in to 2009.
May 2009 be happy, healthy and the most innovative year in your
experience.

Peter Stevens


Peter Stevens, CSM, CSP
http://tinyurl.com/Scrum-In-House-Training
http://scrum-breakfast.com
tel: +41 44 586 6450

Top on Agile Software Development (.com) in 2008

Year 2007 was a year of explosive growth on our site. In 2007 it was a purely private blog, in 2008 the site became a collective work of several highly creative contributors: Jurgen, Przemyslaw, Peter, Mike, Matt, Janusz and yours truly (you can become a contributor too). January to December we rocked from 12000 to well over 70000 pageviews a month.

 

Top stuff

According to Google Analytics ten most popular writings of the years are:

Enjoy!

My First Agile Project: So It’s Come To This – The Year In Review

Picture courtesy of Vegan Fellow on flickr

In the spirit of the season (Year-End Recap and Top 10 List season I mean), in this episode of My First Agile Project I’ll be going over the previous posts in the series and giving some behind-the-scenes comments. If you’ve read some of the series, keep reading for more you might like. And if you haven’t read any of my posts before, I’ve read some very kind things about the series on readers’ blogs so you don’t have to take my word for it when I say you will like it. If you don’t like it, I’ll give you your money back guaranteed.

My First Agile Project Series

  • Part 1: Doing 80%
  • This post was originally just for my personal blog and Artem liked it so he twittered me about possibly writing a series for this site. Don’t let anybody say Twitter or a personal blog is useless.

  • Part 2: Inception & Planning
  • The first post I wrote specifically for a site other than my own, although the idea was part of what I was going to write about for my own blog. This was a nerve-wracking one to do, for sure. I’ve been on the internet long enough to have seen my share of people attacking well-meaning writers. It’s one thing to write for my own blog, it’s another to write for a pretty well-trafficked professional site.

  • Part 3: Viral Videos and Bad Jokes in Scrum Demos
  • This is the first post where I tried to do a little better with the title. I want to entice people into reading but not be too cute about it. I try to keep my rambling down to a minimum with the posts to ASD as opposed to my own blog but this one is still a little all over the place.

  • Part 4: How to lose credibility and jeopardize your project with lack of management buy-in
  • I went a little over board on the title on this one. Whenever I see it I think of Tyler Durden from Fight Club “How’s that working out for you, being clever?” I like the post though and this is my favorite image I’ve used on a post.

  • Part 5: Our Top 5 Agile Mistakes
  • I think this is my most read post. Everybody loves lists and apparently everybody also loves reading about other people’s mistakes.

  • Part 6: The First End of Our Project
  • This one was hard to write. At the time of writing we were heading into a stressful period of hoping we could get the project done by our newest deadline (we didn’t) so thinking back on the first time we missed our deadline wasn’t easy. It’s never easy writing about missing commitments.

  • Part 7: Adventures in Agile Testing
  • My second favorite image I’ve used. I think this post turned out pretty well too, my rambling was kept to a minimum and I got the point across. I probably edited this one more than any other since there was so much I wanted to talk about.

  • Part 8: 9 Things We Disliked (and Liked) about ScrumWorks
  • My most heavily commented article by far. I thought that might happen since everybody likes talking about tools. This was probably my most controversial post too since I was talking about an older version of the product but the series is about my team’s experience, not about reviewing tools so I’m okay with it.

  • Part 9: Choosing A New Tool – VersionOne
  • I thought this one would be popular too and it was, but not to the level of the Scrumworks one since it was mostly positive. I’d actually started out to do both Scrumworks and V1 in one post but ended up writing 1000 words on Scrumworks alone and split it up.

  • Part 10: 5 Important Issues For Teams
  • This is one of my favorite posts. I love working with my team and it’ll be hard to go to work anywhere else where the team isn’t as cohesive and friendly.

  • Part 11: A Tale of Two Dark Clouds
  • I like using stories and connections from other disciplines or fields to make points. This story is one of my favorites too since it’s such a big thing and has such strong parallels to programming.

  • Part 12: The Good, The Bad, and The Ugly – Our Retrospectives
  • I felt like I really had my rambling tendencies under control the best in this one. I liked writing about this topic since I’ve thought a lot about it beforehand. I always thought our retrospectives were super valuable but could have been better.

  • Part 13: Reflecting on The Decline of Agile
  • This was my first attempt to use our past experience to look at something in the news and I liked how it turned out. I didn’t just want to do my thoughts on the mini-controversy, I wanted to see if our history had anything to say on the matter and I think it does.

  • Part 14: Did We Need A Coach? Does Anyone?
  • This post is why it pays to read comments. I got this idea from some comments on Part 13 and it worked out well. Since I’m not a professional writer sometimes thinking up what to write each time is the hardest part.

And that brings us to today. My First Agile Project, both the series and the real-life project, are taking a break until the new year. When we return to work in January we’re going to be starting crunch time in preparation for going live near the end of the month. The series is going to become a real time look at how we’re doing going live, then hopefully we’ll transition to looking at how our team goes from one project to a multi-project Agile team. I think it’ll be a good time both in my life and in terms of reading about it so stay tuned.

I’d like to sincerely thank any and all who read even one of my posts on ASD. I’m not a professional so being able to do this for the first time on a site with such a great and smart audience has been a treat. And super thanks to Artem, the editor of the site. My last bit of insider information will be to admit that I’m always late turning in my article and Artem has always been way better about it than he has to be. I promise I’m going to get my act together in the new year Artem! 🙂

Thanks again and stay tuned! Have a great holiday season and new year everybody!

Year 2008 in a nutshell

Picture courtesy of foxypar4@flickr

Christmas and New Year is coming so it’s time for some summary. I’ve never done this before but this year was quite awesome and I have something to be proud and loud.

Let’s start from January when I moved from my hometown to the glamorous French Riviera i.e Cote d’azur (yes, the sea here is pretty much azure).

I accomplished some cool stuff at work and one that I can share with you is the new generation hotel search engine – Wallaby (which is working but still in beta phase).

In 2008 I started interesting in the theory of Agile Software Development (after few years of using it) which resulted in inviting me to contributing to the AgileSoftwareDevelopment.com blog. It was a huge challenge for me as I’ve never been a good or even decent writer (especially in my native language – Polish) but it appeared to be kind of success. I have on my account some pretty cool posts that appeared to be big hits like these (each of the following posts was visited more than 5k times):

And the best posts were written pretty spontaneously in less than thirty minutes without any preparation. Just some kind of a thunder in my brain that triggered my grey matter to work – that was just it.

I’d like to thank Artem for inviting me to become a regular contributor – it was a good decision for me to join ASD. I hope I will keep at least the same level of inventiveness next year 🙂

During 2008 I’ve read over 18 technical books and I shortly reviewed some of them on my private blog.
More on numbers in 2008: my FeedBurner account shows quite an increase (260% from 25 to 65 – and counting) of regular readers of my private blog – that’s cool. Thank you readers!

Last but not least submitting my old and fresh posts to DZone gave my private blog a lot of visibility and doing this I increased number of visits by 1000% from ~930 to over 9K in just one month (I will not be able to keep these numbers but it anyway shows me that what I write is interesting and a lot of people like it). This is also thanks to ASD blog which gave me more visibility.

And now some conclusions. As I wrote earlier I moved to southern France in January 2008 and this was caused mostly by my previous employer – Intel – who simply laid off our team at the end of 2007. My friends who I worked with at Intel opened their own company and I was supposed to be their partner but I decided to move to France with my wife. And this was one of the best decisions we made in our life.

We live in a great place, have awesome friends and every week we do some cool stuff like skiing, hiking or just visiting some beautiful places like Monaco or Eze. And this is much more important that money that I could earn staying in Poland.

I learned a lot during year 2008, the Sun hasn’t burnt out my brain (yet) and consider it pretty awesome year privately as well as professionally. And I hope next year will be even better – but even if it will be a bit worse it will still be awesome 🙂 Yes – I’m the optimist. I’m not going to reveal my professional plans for the next year but I will probably share with you the results in 365 days.

As this is my last post this year I’d like to wish all the people around the World:

Merry Christmas
and
Happy New Year 2009

Scrum, the experimentation framework

Due to its exterior simplicity lately Scrum has become the most popular Agile method. What can be simpler, than few artifacts roles and procedure? The unfortunate consequence of this exterior simplicity is that often people try adopting the method without a deep thought and proper guidance. Some coaches consider it so big problem, that declare the fall of agile (I don’t think so).

One of the particularly interesting aspects that is missing from the simple method description is that Scrum is a powerful experimentation framework. The cadence of short iterations and mandatory reflection moments allows a team to try significant amount of improvements in a rather short period of time. You think making acceptance tests a mandatory part of all the requirements is useful? – Try it for a sprint or two and see if it works for you. Arguments about the effectiveness and social aspects of pair programming and colocation seem to be going forever? – Move the tables together and try pairing for a sprint. Some practices such as Test Driven Development might need some more time for a real try, but even in these cases them it is usually possible to figure out the required experiment length in advance. Scrum applied with a decent amount of rigor forces participants to focus on the goals and evaluation criteria of the potential improvements and arms the team with the regularly applied improvement cycle.

Large effect of the small improvements

Most of the improvements a team tries are often quite small. The trick is that sprint after sprint these small improvements add up to a significant advantage. Famous Toyota Production System that is heavily based on the same experimentation idea allows the company to make over 700000 (seven hundreds thousands!) improvements per average year and over the decades it contributed very well to making the Toyota the biggest automaker in the world.

Agile and Scrum are no silver bullet. We still need to think and the best thing Scrum can provide us with is the thinking tools that help framing wishes with the technical and time boundaries of the real world. Scrum helps us to transform some of the wishful thinking into short knowledge generating experiments.

Your experience

What about your team? How often do you try new things and how carefully do you frame these experiments?

My First Experience with Business Value Poker

Last week, I wrote down a new idea about how to determine business value using a variation of planning poker. At the same time, I tried out the method in a real project. How did Business Value Poker survive its first encounter with the real world?

Previously, the two product managers had come up with a list of functions. The dilemma was that Product Manager #1, the manufacturer of the complete system, valued new hardware sales generated by the software. P-M #2, a user of the system, valued operational savings. At the first attempt to prioritize, each manager was given 1000 points to distribute among the functions. The business value was the sum of each party’s vote. This produced a value but no consensus.

Establish the value of a Value Point

The first thing we did is talk about the value of each feature. What did the top priority features mean to #1 in potential hardware sales? What did they mean in potential cost savings to #2? So we calibrated the scale: 100 Value Points (VP) = X dollars of hardware sales or Y dollars of operational savings.

Challenge the existing valuations

Next, we reviewed the existing valuations based on our new found reference values. Had the P-Ms valued the functions consistently? It turned out one feature had been substantially over-valued, the rest were pretty consistent with the actual business potential.

Estimate new features using the Cohn Scale

We used a modified Cohn Scale (more or less) to estimate the value of new features. Each estimate of value is assumed to be +/- 50% and we have Fibonacci progression on possible values. The idea that an estimate has high intrinsic uncertainty is even more compelling when discussing potential revenues or cost savings. Feature X might generate sales of 1000 additional units, but it might only be 500 and could be as much as 1500. Our actual numbers (which were based on the results of the previous point distributions) were pretty much what I suggested last week: 125, 250, 400, 700, 1250.

Where Prioritizing makes a difference

There was widespread agreement about the top two features. The problem is that they are both fairly big, one has an external dependency, and it is not clear whether either can implemented in the time frame of the next release. The next 5 or 6 features on the list all had similar appraisals (250 to 400 points) and were probably much smaller to implement. Which ones to do first?

To answer the questions, the P-M # 1 was asked to go back to his sales people and find out which of these features could have the most short term impact on sales. At the same time, we broke the high level stories down to estimatable user stories and will give that list to the implementation teams to estimate.

Once the product managers have this information, they can decide on how to prioritize the backlog for Sprint 1 with the goal of optimizing the return on investment.

Theory meets Practice

How did the method I suggest hold up in reality? We didn’t actually play poker. With two people who communicate well, it wasn’t necessary. We did discuss the value of each story as described previously. Each P-M gave his assessment; these were added together and that became the consensus value. Given that two partners are investing in a project together, in retrospect, it seems obvious that the value of a story is (value to partner #1) + (value to partner #2).

The discussion process served to build a shared understanding of how we came to the numbers. Each P-M was able to accept the importance of a feature to the other, even if a certain feature had no value to his company.


Footnote: I discoved that a variation of Business Value Poker has already been proposed: Andrea Tomasini’s Business Value Game. His discussion points for determining value are more closely based on quantitative ROI spreadsheets than the questions I proposed last week. He also suggested trying to arrive at a consensus for the value of each story, as in planning poker (and as I suggested last week).

My suggestion: the goal is consensus among the stakeholders. Use whichever questions work best for you and your project. And co-development is a cooperative game. Value = Value(1) + Value(2)+…+Value(n), where n is the number of partners.

Goodbye, And Hope to See You Soon!

This is my last post on AgileSoftwareDevelopment.com. I let Artem know that I need to concentrate on my own blog for a while. The success of my site is a welcome surprise for me, but it also means that it’s demanding all of my attention.

On AgileSoftwareDevelopment.com I published 46 articles this year, including some timeless classics such as 10 Principles of Agile Project Time Management, The 12 Best Questions for Team Members, and Oh My God, They Fixed the Bug!. I also published my share of useless and controversial drivel, such as Professionalism = Knowledge First, Experience Last, and Specialization is Good. But I had fun writing it, and I’m glad that most of the people throwing bricks at me missed me.

Thank you all for reading, adding comments, and providing me with your feedback. Writing is no fun at all when there’s nobody writing back at you! Those of you who enjoyed my writing might want to check out my own blog at Noop.nl. (Artem generously allowed me to promote it in this last post, so I’m gonna squeeze this while I can…) Besides visiting the blog, you can also follow me on Twitter, or subscribe to my feed. And even if you couldn’t care less about me or my writings, then you could at least have a look at the Top 100 Blogs for Developers. There are lots of other great blogs out there. (And both ASD and Noop.nl are performing well in it!)

Of course, I also trust you will keep reading this site. I am happy and proud to have been able to support Artem and the others in making this blog a great place to read everything about agile software development. I’m sure they can keep growing the site, even if it has to be without me.

Goodbye everyone, and hope to see you some place soon!

Scrum in under 10 minutes video

Hamid Shojaee from Axosoft published an excellent and funny video on the basics of Scrum. In under 8 minutes of animation Hamid describes most of the basic concepts. I don’t agree with everything (in particular I I would like to see the release burndown chart described), but you can only explain so much in under 10 minutes and every Scrum installation is different anyway. Have a look and enjoy! High definition version is available here.

Stories From The Battlefield: #2 – My God, It’s Full Of Bugs!

Photo (c) Janusz Gorycki

The Bet

Let’s bet: I will buy you one pint of beer for every minute it takes me to find an embarrassing bug in your code.

Admit it, you have no chance of winning this bet. Ever. Finding bugs in somebody else’s code is dead easy. Preventing them is next to impossible. Well, on second thought, scratch the “next to” part.

There is this user story acceptance criteria of “No known bugs should exist” – yeah, right. If you are a Project Manager (agile or otherwise) and your developers tell you they produce bug-less code, and that they do enough testing to be sure their code is healthy, they are either delusional, or are liars – I don’t know which is worse. If you have a consultant who claims that they have a cure for bugs and will make your projects clean and shapey, do yourself a favor and fire him. Or better yet, do everybody else a favor and shoot him on the spot. The world will be a better place.

The Rant

Which brings me to the subject of this post – bugs. The most fundamental, yet easily forgotten fact of life is that all software sucks. All software has bugs. If yours does not, then it means only one thing – nobody uses it. Some of the best software I have ever seen has so many bugs that they overflow their bug trackers’ bug counters. And you know what? It is actually a good thing! The existence of bug reports means somebody is using the software and actually cares to report back to you that he is having a problem with it, instead of just deleting it from their hard disk.

We had been working on this user story lately, that has been with us for quite a few iterations and refused to be “done”. The story involves a dialog box, that is a bit, well, “legacy” (code word for “crap”). We were supposed to refactor it to stop being broken and that was pretty much the whole story’s definition – don’t you just love to work on stuff like this? Every time we thought we had finished the story, on the last day of the iteration, somebody managed to find yet another bug in this dialog. And then our ScrumMaster, who loves the agile process to be “pure”, would move the story from “done” to “not done” – and we would all be pissed off. Eventually, using my Product Owner Proxy superpowers, I have decided to stop this silliness. I said to the guy – “look mate, this story, in its current shape, is good enough for me, good enough for the Product Owner, and definitely good enough for the general public. I know it still has bugs, but I want it to be released, as not releasing it hurts us more than having to deal with its remaining bugs. We will deal with remaining bugs by filing them in the bug tracker and dispositioning in due time”.

So now what?

Ok, so now that we have acknowledged the existence of bugs, what can we do about them?

Quite a few strategies exist. “Pure” Scrum says that you should estimate and prioritize bugs in the same way you size and estimate stories. Bug there is a significant problem with this approach – most non-trivial bugs (and these are the interesting ones) are very hard to size. Once you scratch the surface of some problem, you seem to be opening a can of worms: “oh my God, this thing is broken beyond repair”! Admit it – you feel like this sometimes, don’t you? This is not surprising – bug resolution requires a “discovery” phase, which pretty much does not have any upper time bounds.

So what we do about bugs in our team is we do not estimate their size. We simply assign a fixed part of each iteration (say – 1 “man-week”) to fixing as many bugs as possible. The story-to-bug proportion is not fixed – we adjust it as we go, based on our gut feeling about the current health of the project.

This is by no means the only valid approach – it is just the one that seems to be working for us. I am interested to hear what other teams do about bugs. Why don’t you share your experiences? But please, don’t tell us that you don’t have the “bug problem” in your project – because nobody will believe you.

Seven Principles of Lean Software Development – Create Knowledge

Picture courtesy of J.C.Rojas@flickr

“There is no fool like an old fool” says popular international proverb. One of the meanings of this proverb is that people can make mistakes but they should learn from them. You are not a fool if you make mistake but you become one if you make the same mistake again. It simply means that you’re not learning.

The same rules apply to the software development teams – it’s much easier to work in an environment that encourages you to learn and to create knowledge. Why should you create knowledge? Well, the best way to learn something is to make mistakes by yourself but it wouldn’t be wise to let all the engineers invent the wheel all over again. It’s much better to teach them about what we already know, what works and what doesn’t. It’s much better and safer (yet a bit less effective) to learn from someone else’s mistakes.

In this post I will try to explain “Create Knowledge” principle from “Implementing Lean Software Development – from Concept to Cash” book.

Create design-build teams

It is essential that the architecture of the software you’re building is easily “splittable” into logical modules that can be implemented by cross-functional teams. These teams should be provided with appropriate leadership and be encouraged to engage themselves in the project and provide intensive feedback. My translation of this is that leader of the development team has to listen to his/her members and ask smart questions encouraging them to look for the answers and to get back with encountered problems or invented solutions as soon as possible. These teams should be encouraged by the leaders to share early and often, to fail fast, and to learn constantly.

It is pretty easy to imagine the contrary i.e. team members just waiting for others to fail noting every mistake and using it during 360 degree yearly evaluation. It must not happen! Team members have to teach each and help other. They should install some Wiki and put there whatever they think will be needed in the future. They should encourage each other to experiment and not to be afraid of failures – failures are great as long as you learn something from them. The last thing, though, you can learn from your failures is not to try again. Failures should be accepted by applaud – the team would know then which way they cannot go and invest in – it can save some money.

Maintain a culture of constant improvement

As a leader you must create such environment in which people will not be blaming each other for writing crappy code or designing crappy class or package structures. You must create environment in which people will be constantly improving what they are working on. People should also know that they are not and should not be perfect – they always have a field to improve and they should do it.

You as a leader must know that even if everything works fine there is always places that could be improved – encourage your team to identify such places and fix them. Such “place” can be a policy or practice, not necessarily source code, that makes development cumbersome or is basically not necessary and doesn’t improve the overall results.

Teach problem-solving methods

Your team should not only learn and teach each other – they should be able to solve all kinds of problems in a structured way e.g. Plan Do Check Act. Development team should often behave like small research institute, they should establish hypotheses and conduct many rapid experiments in order to verify them. Your team should also produce concise and valuable documentation keeping up to date knowledge base of what works and what doesn’t.

Create Knowledge

I hope pieces of advice given above will make it easy to understand how to put “Create Knowledge” principle in practice. If you need more detailed description with more examples and more sophisticated explanation you should definitely go to “Implementing Lean Software Development – from Concept to Cash” book.

PS. Other articles in this series can be found here:

  1. Respect People
  2. Deliver Fast
  3. Optimize the Whole
  4. Defer Commitment
  5. Build Quality In
  6. Eliminate Waste