Kanban vs Scrum, the ultimate fight? Don't think so, here's why:...

Wow, what a week! A BIG post on Kanban by Scrum evangelist @jcoplien litterally put the blogosphere (and twittersphere on fire!).

It is good to have these family fights in the Agile family once in a while. As a life-philosopher once said: "These things gotta happen every five years or so, ten years. Helps to get rid of the bad blood".

But what are the differences between Kanban and Scrum, really? What are they?

Here's my take on the differences:

Kanban innovation

Kanban is, from it's origin a more systematic approach to measuring, visualizing and following up work in a "system" (one team, many teams, a company you name it). Thanks to the work by the Poppendiecks, David Andersson and Don Reinertsen (and others I'm sure) a pretty interesting and innovative economic framework as been put into the software process development lingo. Cost of Delay, Queues, optimize the whole, etc.
This economic framework is, in my view, the major innovation that Kanban proponents bring to the table. This was to be expected as many of the early adopters of Kanban were using Scrum before and felt the need to quantify and analyze some aspects of software development that Scrum did not tackle.

Scrum innovation

Scrum brought to the fore-front of process discussions issues that had never made it to our attention before: Self-organization, people/team dynamics, problem solving within a short cycle with feedback loops in place (Sprint), etc.
The major innovation of Scrum in my view was the introduction of the Socio-technical system of software development as Liker describes it in the Toyota way. Other similar software development processes took some of the ideas that Scrum also took, but shied away from the self-organization at the team level and blocker-removal focus of roles such as the scrum master. Those methods did not last long because the teams felt like puppets instead of adults with the possibility (and responsibility) to produce the best product they could.

Wrap-up

Both Kanban and Scrum brought significant innovations to the software development world. Those are just two types of innovations. There is more coming from the community and instead of focusing only on these two methods (which all of you should experiment with!) we should also look at what else is missing in the software development ecosystem.
My next interest area is "Complex Systems" (Complexity + Systems Thinking) and Management as a profession. I'll be exploring those subjects more and more in the future as a way to complement my use of Kanban *AND* Scrum. I suggest you do the same and find what else is missing in your environment and look for what else is around that could help you complement what you are already using. Here's a suggestion: start with @jurgenappelo's book on Management!

Happy reading, happy learning!

LESS goes Stockholm for LESS2011, join us there in October

Last year I was involved in the organization of a unique conference. LESS2010 was a unique conference because it brought together different communities. We wanted to make sure that people with different points of view would discuss those points of view. The aim was to create a space for sharing ideas from different communities in the hope that new ideas would emerge. And emerge they did!

When the conference was done we had brought together the academic community which is involved in researching Agile adoption in the real world; the Agile community that is day-in-day-out applying Agile ideas in their own places of work; the Lean community and finally the Beyond Budgeting community that is sharing novel ways to manage and lead companies. This year we are doing the same, only better!

LESS goes Stockholm for LESS2011

You can check the details of the conference in the web-site, but here's a hint. We are working again on bringing different communities together!

The tracks that we have chosen are around the topics of Agile, Lean, Beyond Budgeting, Complexity Sciences, Systems Thinking and one topic that we deal with every day: Organization Transformation.

This year the trend is even more clear that LESS2011 is a conference for leaders in R&D organizations. Perhaps the only leadership focused conference in Europe at this point.

I do hope that more of these start happening because that's the next frontier for Agile and Lean adoption in our places of work.

So, I encourage you to submit a paper/session to the conference. Being there and talking to the the people with the experience and ideas is very important for us to continue our day-to-day work with new ideas and fresh energy!

See you in Stockholm!

What would a European Agile comunity look like? #ALEnetwork

Many of us have been involved in many different communities. Agile Finland for a start. But also other communities: our local kindergarten or school parent's group, the school or kindergarten itself; the local neighbors; the apartment building executive board ("hallitus" in Finnish), etc.

In fact, if we look back in history all of our history has advanced due to the association of different people, sometimes with similar goals, but much more often with different and sometimes only slightly related goals. The greatest example of all is our very own society which exists and evolves because of the myriad of small communities that interact with each other to achieve a quasi-infinite number of goals.

Why do we need an European Agile community then? Aren't we already in so many different communities? Why one more?

There are many answers to these questions, but perhaps one that is interesting because it is a true story is the story of Peter the Great (or Pyotr Alexeyevich Romanov for his friends). Peter went around Europe as a young man collecting knowledge, although his initial intentions were to gather support for war (who didn't, in those times?) he finally ended up touring Europe to learn. He worked in Shipyards, visited Greenwich, learned how to build cities by visiting Manchester (no kidding!). Peter's journey was one of learning by sharing. He learned by interacting with others, collecting knowledge from many sources and ultimately creating his own view of the world which he implemented back home. Some of it was cargo-cult, but some of it led to lasting changes that we can still see today.

The core of Peter's story, however, is that he understood that the world was larger than his own Empire, he understood that he had a lot to learn and took a step (literally) towards the communities that were surrounding him. Learned from them and became a better person for it.

How about you? Do you want to become a better Agilist? Join us in the ALE network Vision Helsinki event where we will explore the questions above and more! Check out the details and register here. NOTE: registration is mandatory and seats are limited.

Photo credit: ibnhusin @ flickr

The Kanban vs Scrum argument stinks! But, can we learn anything from it?

There were some interesting conversations on twitter last evening, so interesting that they are worth some comment.

There was an interesting back-and-forth between @jurgenappelo and @agilemanager about whether it is possible to do Scrum in a "pull" mode or not as well as other issues. But this was just the tip of the iceberg of the Kanban vs Scrum discussion. Here's one comment that caught my eye:



Here @agilemanager is trying to prove that Scrum cannot be done "right" because of inherent problems, specifically that velocity is so unstable that it cannot be used for planning. That argument, however, is easily proven wrong.
Here is a graph of a team implementing scrum, using velocity to plan for success and with a rather stable velocity. (Technically the velocity is "under control" as defined in statistical process control).



This tells us that it is possible (unlike @agilemanager states) that using Scrum planning based on velocity is possible. And in fact that's the main long term planning metric that I've used in the past with success.
The fact that we have a (statistically) controlled velocity allows us also to do other things like identify common causes and special causes that will require different action/intervention with the team in order to improve their overall result.

Then @jgoodsen pitched in with this comment:



Here @jgoodsen is disagreeing with @jurgenappelo's statement that as Kanban gets wider adoption it too will be mis-applied and lead to failure. This type of extreme position taking is an example of why the discussion between Scrum-mendalists and Kanban-istas is quite useless for the rest of us that are interested in learning more.

The point is: Kanban, just like Scrum, initially is being practiced by early adopters. People that tend to read and study things more and earlier. These are also typically people that are given a license to experiment, to try out new things.
In the end the effect is that, typically, early adopters are better at adopting new methods because they have done that more often (they are early adopters after all). Kanban is just another method/framework/whatever, it will succeed and fail as much as Scrum does. @jurgenappelo is right, any method fails when applied by a population large enough.

The takeaway from this discussion for us should be that methods, ultimately, are irrelevant. It is the learning achieved by experimenting that matters.

We should be sharing our learning, not our method allegiance!

We need proof! For a better understanding of our business, without religious arguments

Whenever you hear someone talk about Agile being better than X or X being better than Y don't assume they are right. Ask for proof.

For many years our knowledge and society at large have advanced through the tried and often questioned, but always upheld view that it is not sufficient to merely claim something convincingly to have it accepted. Sure, in politics that happens all the time, but would you trust a politician to pilot the next aircraft you fly on? I thought so... It is not enough to be convincing or to tell good stories, you actually have to know what you are doing!

The point is that our knowledge, human society's knowledge, evolves by having many people look at the same issue, over and over again, doing experiments to prove an hypothesis and then learning from it.

An important point in this context is that success in the experiment is not needed to learn and advance knowledge. Failure in the experiment often yields as much learning as success would. Take the most famous failed experiment in history:

The Michelson–Morley experiment was performed in 1887 by Albert Michelson and Edward Morley at what is now Case Western Reserve University. Its results are generally considered to be the first strong evidence against the theory of a luminiferous aether. The experiment has also been referred to as "the kicking-off point for the theoretical aspects of the Second Scientific Revolution".
-- wikipedia

It was, in part, thanks to this experiment (a failed experiment) that we got the theory of relativity, arguably one of the most important advances in science in recent times.

But there are more examples of how science delivered progress. How it created knowledge that helped create the world we live in today.

What does this have to do with Agile SW development? You ask. After all, that's why you are here, right? Well, it just so happens that Agile SW development and our SW development industry have a lot to learn from science and the scientific process. We have to start taking the responsibility for the development of our craft/art/science.

Despite all of the buzz about agile, we don't have much in the form of evidence for us to say, yes agile is the way to go. Don't get me wrong, after having worked in this industry for 12 years and with Agile software development for 6 years. I would not want to go back. But as an industry we are making transitions to agile SW development that cost us millions of Euros every year. Most of those transitions will have been the result of a successful visit by a high-flying, expensive consultant that told us some stories we already knew we wanted to hear.

Are we betting our industry on a bunch of stories? Do we want to fly in that plane piloted by a politician?

I refuse to believe that's what we want to do. I refuse to believe that we want to go and bet our entire industry on a bunch of unsupported ideas that some good story tellers have come up with! I want facts, I want the evidence. I refuse to believe without seeing the evidence.

So, if we chose to be coherent with the growth of knowledge as opposed to the beauty contest that the Agile consulting world has become, we must start questioning the received knowledge that Agile "just works". The statement "it works for me" is utterly useless if what we want is to learn and to improve! The fact that it worked once for someone and that led to a successful consulting career has no statistical significance! Or do you believe that the waterfall consultants don't say the same? Of course they do.

So this brings us back to the key question I want to raise in this post: "How can we improve the state of our industry in a consistent, long term and sustainable way"?

The answer, which should be clear by now, is in the numbers. Or as a famous person once said: "show me the money!"

Show the numbers as they are so that we can have a conversation about the real results and can learn, ultimately improve.

Feel free to add your data to this blog post. I hope this can be the beginning of the real advancement of our industry. Show us what you learned, we will show you what we learn, and from this a conversation can emerge that will hopefully take us forward, make us more professional, deliver more value to our customers.

Share the data. "Show me the money"!

Photo credit: mr.beaver @ flickr

Why learning is *still* so important (or why you should attend Scan-Agile '09)

Last year I wrote a very personal story about how learning made a huge difference in the life of two people of similar age and in a similar context.

Check out my story about Grandpa Tony and Grandpa Frank (BTW: it's a real story!).

So, this year I thought of finding a different way to talk about how important it is to learn continuously to ensure our best options to survive in our jobs.

I'll pick a few sessions from the Scan-Agile '09 conference to explain how you can actually use what you will learn in those sessions to improve your skills and your career.

Let's take the example of the workshop "Executable Requirements in Practice" hosted by Pekka, Juha and Janne. In this session you can learn about one of the most important practices in SW development today.

Making sure that you continuously develop software that meets needs that are identified throughout the life of a project is a basic success criteria. How do you do it practice? And how do you do it in a way that does not transform the test specialists into click-robots?

Executable Requirements is a simple term to describe what tests should cover in practice: Requirements. Executable because we need to be able to run those tests 100's of times in a typical project and people are not very good at doing the same thing 100's of times, therefore we need to have those in a executable form to be able to run them over and over again.

In this session Pekka, Janne and Juha will explain how they've actually done it! Not theory, but experience.

In many aspects their work is quite unique world-wide and we are very lucky to have them present this in Scan-Agile. Look-out for this "Executable Requirements" to become a trending topic in Agile circles and come to Scan-Agile '09 to learn all about it!

Check out the complete schedule here and register here.

Photo Credit: David Den @ Flickr

The next step, Agile hungover

So, it is starting to happen. All around us we see people like James Shore or Rob Bowley proclaiming the end of Scrum, that we don't really get it and that many teams do cycles, but forget about the rest.

If you have been following the different waves of software process adoption this should be no news for you.

However, there's a twist. If you have read about the Auto industry and it's woes and have read about Lean (as in manufacturing, not as in software development) you know by now that no process can save you, except one: PDCA (Plan-Do-Check-Act). The learning process.

In the software industry we are starting to see now the same signs that Lean consultants and commentators saw in the 90's in the car industry. A couple of people wrote a few books (like The Machine that Changed the World) and the Auto industry management started blindly copying the practices that were described in the book. They forgot to read and learn from the masters like Deming or Taiichi Ohno, and -- most importantly -- they forgot to use their brains. And then boom! 25 Billion USD bail out plan because the stupid management in the three big ones did not take the trouble to learn!

The same is happening in the software industry if Jim and Rob are to be believed, and there's no reason to doubt them. After all, it is human nature. People want a fast, short and painless way out, so they'll got for the cargo cult every time.

That leaves us, Agilists, with a big responsibility -- develop our practice. Understand how to make people use the most important principle of all: Learning! Practice the PDCA cycle -- the only cycle that really, really, really matters.

I said it before and will say it again: Let's not fall in love with Agile, let's fall in love with improving our industry!

Learn or else...

Through Elisabeth Hendrickson I got to Brett Pettichord's post about the role of feedback in Agile.

Read it if you haven't yet.

Here are the pearls that made me post this:

“If you don’t have meaningful feedback then you’re not agile. You’re just in a new form of chaos.”

and

“Agile practices build a technical and organizational infrastructure to facilitate getting and acting on feedback. If you aren’t going to adapt to feedback, then this infrastructure is waste that will only slow you down.”

This is very much in line (or even the same) with one of the tenants of the TPS (Toyota/Thinking Production System), the PDCA cycle. In order to improve you need to learn, feedback is the fuel for the process of learning. No feedback no learning.

If you are not learning, you are not Agile. No matter what you are doing!

Why learning is important (or why you should attend Scan-Agile '08). The story of grandpa Tony and grandpa Francis

I've come to realize lately that today's ability to learn is similar to last centuries ability to read. Confused?

Let me tell you a story.
One of my grandfathers (let's call him grandpa Francis) knew how to read, he was able to keep up with the latest developments in agriculture and even read the weather forecast in the newspaper -- a serious advantage in his time (early 20th century) over most people that depended on agriculture. My other grandfather (let's call him grandpa Tony) did not know how to read. Grandpa Tony could not keep up with latest advances except by word of mouth or (very much later on) by listening to the radio (and TV, even later).

Both grandpa Tony and grandpa Francis worked the land. They planted so they could collect and feed their families. What they could produce more (surplus) they could sell and buy other items such as  lighting oil, clothes and other ingredients they did not cultivate.

For them, yield and surplus were the name of the game. If they could collect more than they would consume they would become (so to speak) richer. Hence the importance of selecting the best plant breeds (such as potatoes, wheat, carrots, apples, etc. -- whatever grew in their climate).

Grandpa Francis was able to rent a farm and have therefore have access to better land, which in turn lead him to be able to have even more surplus. Grandpa Tony was not able to do so. They were both strong and hard-working men, both of them religious, both of them "good men" as they would say in those times. Both of them had a female first child and a male in the second birth -- an important economical factor in those times when work demanded hands and bodies. The only real difference was that grandpa Tony could not read, and grandpa Francis could.

Grandpa Francis would consult the farmers almanac for tips and hints of the latest developments. He was then able to choose the right plants to plant based on the most resistant and yielding seeds and was able to treat for certain diseases by learning about it from reading. Grandpa Tony had to rely on word of mouth and self-experimentation (not easy when you need to feed the family).

Grandpa Francis was able to rent a farm, to have a large(r) house and a larger family (more children = more wealth as families stuck together for long in those days).
Grandpa Tony did pretty well with his hard work and wild adventures (which should perhaps be a subject for another story), but -- critically -- grandpa Tony did not do as well as he could have done, had he known how to read.

What does this have to do with software? Good question, but there is a link. Today's factor in differentiating people's success in life is not reading, but something related: "wanting to read" or being able to learn.

Many people today go through their lives without reading so much as one book per year. That in effect prevents them from accessing knowledge that could transform their lives.

In Agile Finland ry, we are trying to combat that lack of learning by creating opportunities for learning, this year we are putting together the Scandinavian-Agile '08 conference. In this conference you will have the opportunity, not only to learn from the top-notch speakers, but also to network with like minded people and learn from their experiences also.

I'd say that this is an opportunity you should not miss!

Check out our web-site, and register ASAP. We expect a full house and seats are already flying!

Come and learn!

Admitting mistakes is the first step to learning, not just for you, but also for your team and company

Here is an excellent piece from the blog Evolving excellence about how a worker at Toyota battled his fear of admitting a mistake and was rewarded by his pears and supervisor for not hiding, but rather disclosing the mistake he had done.

Admitting you committed a mistake is a very important part of continuous improvement. The andon cord (a sort of error alarm) should be pulled as soon as an mistake/error/defect is created or found.

Finding mistakes is not a blame game in Lean thinking, it is a key part of finding ways to avoid mistakes altogether through poka-yoke or mistake proofing our work methods!

Behind this willingness to show and learn from mistakes we make are some concepts in the Toyota Product System (TPS):

1. If the student has not learned the professor has not taught.
2. Most mistakes are caused by the situation or the system and not by people's incompetence or willingness to do their best.
3. Respect for people (one of the key pillars of the TPS)
   

These concepts together with other key concepts in TPS allow people to concentrate and focus on continuous improvement and not play the very ineficient and unproductive blame game that mostly impedes learning.


Updated: with a link to the Respect for people principle in Toyota's website.

Blogged with the Flock Browser