Bas, and the world are not ready...

My good friend Bas Vodde just published a review of the panflet Scrumban.

I see that his review is yet another manifestation of what I titled "the world is not ready".

I don't think that his ideas are wrong, on the contrary, just that his ideas show that a lot of ground is still to be covered in software until we understand the nature of software and why certain techniques (like Scrumban) work, despite their counter-intuitive properties.

One example is when Bas states:

Another interesting thought that made me uncomfortable is the idea that there is such a thing as "in-control production" and special/common causes within that. To me, it feels like a manufacturing assumption within product development. Though Corey does cover these assumptions and makes great points about how to control variability, I'm not sure if it is a good thing to do.

Not believing that a team/organization can produce software at a regular pace in terms of number of stories is a common thing. The most common among people that believe strongly that you need to spend a lot of time in estimation of stories.

That is not my experience, I've been working in many projects (in many roles) and one thing that is common to all of the agile projects I've been is that the team's throughput (the number of stories they get DONE in a sprint) is very stable, "in control". This, to me, suggests that the throughput of a team can, indeed be "in control" (actually statistical process control (SPC) is the term).

I recently wrote a post where I detail how you can use the knowledge from SPC in order to help a team improve. The point I make in that post is that you can look at a team's velocity and based on it analyze whether the variation is a special cause (the velocity is all over the place) or if it is a common cause (the variation is predictable i.e. it goes down or up in a predictable fashion).

This distinction is very important. Special causes need to be eliminated one-by-one by instituting error-proofing, for example. Common causes are much harder to eliminate because as Wikipedia states:

Common-cause variation is characterised by:

• Phenomena constantly active within the system;
  
• Variation predictable probabilistically;
  
• Irregular variation within an historical experience base; and
  
• Lack of significance in individual high or low values.
  

In practice this means that a team where special causes are the reason for their velocity variation needs help in doing deep retrospectives with PDCA cycles tackle the root causes of their velocity variation.

However, a team who's velocity varies due to "common causes" will need support from management because they most likely need to change their process or the process of the neighboring teams in order to get any improvement to their throughput.

My experience is that teams of software developers can handle the special causes most of the time on their own, but need support and coaching to be able to overcome the common causes for their lack of constant improvement.

Not recognizing this lesson from manufacturing and applying it to software development is, in my opinion, lose sight of the goal: not falling in love with Agile, but falling in love with the improvement of our industry.

Why failing matters...

In our world we are often pushed to succeed. All of time. But, as counter-intuitive as it may sound, failure is the key to success!

If you are in a position where "they" say "Failure is not an option" or "Make it right the first time" and similar phrases, maybe you should make them watch this movie:



Way to go Honda. No wonder you are kicking ass with your sales numbers!

Acceleration, schmeleration. Scott Ambler misses the point...

Through this post on InfoQ I learned that Scott Ambler is writing about productivity in Agile and how to measure it. He comes up with an interesting concept, that of acceleration.

Anyone familiar with statistical process control knows that a process does not have "acceleration" by itself. A process is either under statistic process control (ie churning out about the same amount of output per unit of time, within an acceptable variation) or it is not (ie the output is not reliable).

If a process's output is changing outside the control limits (ie not in statistical process control that actually means that the process is not under statistic process control. When that happens it is due to either one of two:

• Common cause - This is a cause that is known and happens repeatedly (e.g. accumulated technical debt in a way that can be anticipated).
  
• Special cause - Something totally out of left field that cannot be predicted.

If the velocity of the team is decreasing constantly (to the point that you can measure acceleration as Scott proposes) then you are in the presence of a common cause (ie predictable cause that impacts velocity). If that is the case you know that it's not the team that is to blame, it is the system in which the team is working that is causing the decreased velocity.

Scott misses the point completely, when it comes to processes, if you can "predict" the acceleration in velocity then you can do something about it. However, you do have to work at it, you need to investigate the systemic causes for the velocity to decrease and identify the root cause that, being solved, can change the system's behavior. This is not necessarily easy or quick...

In practice this means that every single team out there can improve their productivity (and should) by looking at their velocity, seeing if it is within the statistic control limits and acting on it. If the velocity is in control (as in statistic control) you can improve it by changing the process (the whole process, not just the team's sprint-process). If your velocity is not in control then you need to eliminate the "special causes".

What does this all mean? It means that instead of selling the idea of
"pricing" velocity increases for an Agile team (or any other team) Scott should be trying to tell people about the consequences of actually knowing whether your velocity is increasing/decreasing or it is stable.


Here's what really matters:

• If your velocity is stable (in control) the only way to improve it is to change the process (do a proper retrospective, identify root causes and then act -- the old PDCA). Remember that the "whole" process influences the team's velocity, not just what you do within a sprint (requirements, production, etc. should be looked at also).
  
• If your velocity is not stable (not in control) then you should start by analyzing the reasons for it's oscillation and start solving those. These tend to be random events that happen in an unpredictable fashion (e.g. a developer forgot to submit one change to the VCS before testing started).
  

Another post in favor of another User Story format

Some time ago I wrote a post supporting the idea of a new template for the User Story. In that post I tried to explain why we should bring the "value" (because) clause to the fore, to make it the most important clause of the User Story template.

Then John Arrowwood commented on that post and made a reasonable argument to stick to the "old" (or traditional) format for User Stories.

This is a second post in defense of the new template, where I try to explain why the "value" clause in the user story should be brought to the fore, to be the most important clause in the User Story. Here's the template I propose:

• In order to "benefit/why/value"
  
• As a "user role"
  
• I want "feature/functionality"
  

Although I don't see any logical flaw in John's argument I don't agree with it. The reason is that in reality I don't see that people understand the ultimate goal of the User Story which is to justify every functionality in terms of what value it brings to the user.

No matter how much we stress the need to have the "value" properly described I don't see anyone (literally) using it. Normally the User Story writer will not understand the real "value" for the user before I do the 5 why analysis on the "feature" so that the person understands the deep reason why that "feature" is valuable to the user.

I also see that people don't spend anytime writing the "value" part of the clause, they tend to use banalities and obvious things. Writing an obvious "value"-clause delivers zero value when communicating the user story. Remember that it is the "unexpected" and "non-obvious" that actually delivers value, because it contains information that was not obvious to the reader.

Here's an example: everybody knows that as a user of Yahoo! e-mail client I want to save emails sent and received because I may want to return to some business-critical information later on, what not everybody knows is that as a Gmail user I prefer not to have a folder structure to archive old e-mails because it's easier to search than to create a folder system for archiving.

If you take as value the "archiving" then you will create a stupid folder structure for people to be able to "store" old e-mails. However if you take the "finding easily a relevant e-mail" as the value people are looking for, you may start to think twice and ask yourself if all users (all over the globe) are really librarians that think in archive-system terms. Guess not.

When you write a User Story start from the value. Always. No Exception. Ever. Start by asking yourself what does the user/customer really want to do. I mean really! (hint: seldom customers are happy with just using your product, they normally want to accomplish something!)

The value part of the User Story should be the non-obvious part of that value, the obvious explanation for a User Story does not deliver any information to the person downstream that will read the story and have to implement it.

I don't expect everybody to understand this, then again I don't expect all companies to create great products.

Learning to be better is not mandatory. Then again, neither is survival...

The world is not ready...

While reading a post and associated Twitter chatter between Karl Scotland and others I got to think that the world is not yet ready. For what? For flow. The idea that if you do one thing (to Done) first and then start working on another thing and get that to Done, you will be faster (maybe even much faster) than if you try to do too many things at the same time.

The same is also true for teams. If a team starts working on the top story of a backlog and does not stop until that story is Done, and only then picks up another story, then I propose that that team will be faster (over the long term) and produce less bugs (over the long term). The idea is simple yet counter-intuitive.

Those that oppose this idea say that if you are "stuck" in some part of a Story you should leave it waiting for input (maybe from another team) and start working on another task coming back to the original task once it has been "unstuck".

Said this way people tend to believe that it becomes therefore more efficient to work on several tasks so that you are never "stopped and waiting" or waiting for a story to be ready before picking up the next, but rather always "producing". Common sense you would say? Well, I propose that, in this case common sense is wrong.

If you work on one task and then interrupt that task at some point you will be faced with the waste of context switching when you finally come back to the original task -- not to mention that you just broke the prioritization because presumably the first task had higher priority.

The world may not be ready, but if you are I encourage you and your team to experiment with "Kanban" or "Scrumban" or (as I like to call it) "Lean".

Whatever you do, always use your brain. There's no substitute for that.

Meetings are money (lost...)

Time is something that we cannot produce more of. If that's so why do we still spend so much time on meetings that are not valuable? Would you give me money if I came to you in the middle of the day or better yet, if I sent you a money request through Outlook and all you had to do was press "Accept"?

So why do you accept meetings all the time?

Great presentation by Merlin Mann on preserving your time.

Turku Agile Day 09

Our friends in Turku are organizing their own Agile day. Check it out here.

The worst decision you could ever make, and will anyway do it...

I'm sure this has happened to you. Probably many times over your long career in software development. You wake up, take a long hard look at yourself in the mirror and courageously make that decision you had been wanting to take for the past few months. You go back to the office, take your manager aside and in a decisive tone deliver the news, the bad, bad, bad news: we need to rearchitect the system. All of it? No, that's the best part! Only this (very critical, absolutely critical) small part. You don't mention the "critical" part of course. You know better.

Your manager looks at you, silently thinks it over for about 0.35 seconds and then solemnly states: that sounds like a plan, make up the Gantt chart and deliver it to me, I'll take it to the boss.

And so it is done. You have taken the first step to re-write (from scratch, obviously) that part of the system. Did you make the right decision? You say only time will tell?

I beg to disagree, and so does Uncle Bob. You just made the most stupid, crazy-ass, fully incompetent, narrow minded, ignorant, and hole-digging decision of your life and soon you will regret it. Hopefully for the rest of your life, so that you don't do it again!

Re-architecting (read re-developing from scratch) a part of your system is the single most waterfall-ish idea that could cross your head -- and it will make you fail...

I've been a developer that made that decision, and still regret it today.

I managed a project where I was the one accepting to re-implement that part of the system, and still regret it today.

And if that was not enough a colleague at work did the same decision and he is already in his 3rd re-implementation of a module that should take 2 weeks to implement (his words) and he has been at it for more than a year... (his boss is still saying "ok" after thinking about it for 0.35 seconds...)

Learn from the Sensei

It is seldom that we have the opportunity to learn from the masters, the Sensei. Here's a good post for those of us that are interested in TPS (Toyota Production System). I especially like this part:

In 1943 Taiichi Ohno was transferred to the automotive side of Toyota from the Loom Works. The architect of the Toyota Production System was not an automotive engineer. He had no prior background in automobile manufacture. This allowed him to look at the automotive manufacturing process with fresh eyes and also apply a perspective from an entirely different industry: spinning thread. When people say "we're not automotive, TPS doesn't work for us" they should remember that what we call lean manufacturing today owes more to thread spinning (jidoka), the Piggly Wiggly supermarket (kanban) and the efforts of Dr. Deming to teach PDCA and the scientific method than anything. These were the seeds, the automobile industry was merely the soil.

Which part did you like the most?

What is a bottleneck? (TOC)

When faced with a problem in a process, the first step you should take is to identify the process map and bottleneck.

This is nothing new, TOC people have been advocating this for a very long time as part of their "5 focusing steps". But if it is why don't we do it?

Well, because it is hard work. To identify the bottleneck you can't just sit around a table and have a meeting with the managers to define what is the bottleneck. You have to go to the Gemba and analyze the process "as is", not as "it should be" and make some actual work on data collection and analysis.

Once you have done that you are then equipped to start searching for the bottleneck, it's location is buried in the data and process map you just collected.

To find the bottleneck you have to work hard, but finding it is just the first step! Much more is to come...