Scrum

Scrum and Kaizen

BFC — Tue, 17 Apr 2007 20:48:13 GMT

One of my favourite interests is to understand the field of software development. Since my degree that I try to understand why software development process is so difficult and why the IT industry is so immature. I, and most of my best college friends, decided to graduate in Engineer, but I was the only guy who decided to degree in Computer Science and Software Engineering (in fact all of us were studying in the "A area", which was the Health Area, however none of us pretended to be a physician). All the other guys decided by Mechanical and Civil Engineering. Thirteen years later we are still seeing each other (true friends are for life). Sometimes our conversations are reflections about our experiences, and we discuss problems about the development process in each area.

One of this guys talked to me a few weeks ago about Kaizen and the adoption of Kaizen in the organization he works. Kaizen is a japanese word and means "continuous improvement". He told me that Toyota is known to have implemented Kaizen. Since these day I began my investigation on Kaizen and looking for implementations in software companies. I've bought from Amazon the book "The Toyota Way". It says:

"The Japanese term for continuous improvement is Kaizen and is the process of making incremental improvements, no matter how small, and achieving the lean goal of eliminating all waste that adds cost without adding to value. Kaizen teaches individual skills to work effectively in small groups, solving problems, documenting and improving processes, collecting and analyzing data and self-managing within a peer group. It pushes the decision making (or proposal making) down to the workers and require open discussions and a group consensus before implementing any decisions."

So, using this definition, do I remember of any software methodology that follows the Kaizen definition? Yes, I remember. I think, in general Agile Methodologies follow Kaizen, but in particular there are two methodologies/frameworks that fit perfectly in Kaizen philosophy: Scrum and LSD (no, it is not the drug, but Lean Software Development).

Let's follow the Kaizen definition

"...is the process of making incremental improvements..."

In Scrum framework, the Sprint finish with the Sprint Retrospective Meeting, in which everybody enumerate what wents well and identify improvements to be made.

"...and achieving the lean goal of eliminating all waste that adds cost without adding values..."

Agile methodologies conducted to the Agile Manifesto. One of the mantras of this agile manifesto is "Working software over comprehensive documentation". In my opinion every Agile mind has the goal of eliminating waste and not include anything that will not be used by our customers (excessive documentation is waste). LSD principles are based on Lean Manufacturing and in LSD, the statement Eliminate Waste is a rule.

"...teaches individual skill to work effectively in small groups..."

Agile Methodologies are only possible with skilled people. Again, Scrum defines small teams (7 elements) and every element in the team must be skilled.

"...collecting and analyzing data..."

In Scrum, we collect and analyze date every single day. With Sprint Backlog and The Sprint Burndown Chart we have a a really sense of the project state

"...self managing within a peer group. It pushes the decision making down to the workers..."

In Scrum, the Team make the decisions and is self-organized and self-managed.

As you can see, there are very similarities with Scrum and Kaizen philosophy. Right now I am studying Kaizen and trying to understand how can we implement it in a software company. I know that the development process of a car is different from software development. The software does not follow the Newton Laws and there is no fixed gravity in software. However, there is an Inertia in software, and this inertia is the Organizational Inertia made by People. Do you think the Portuguese culture follow this Continuous Improvement philosophy: in my opinion only a minority try this approach of Continuous Improvement....NO NO NO...sorry I'm wrong. In fact it is the majority of Portuguese people: better car, better house, better status, etc.

A retrospective of using Scrum in the last 8 months

BFC — Thu, 23 Nov 2006 21:03:52 GMT

In one of our projects we are using Scrum and today we finished the 8th Sprint. The team has 8 elements, 6 of them in full-time. In the beginning, at Sprint 1, we started with 3 developers. No one had experience using Scrum, but we all believed that Scrum could help us manage our project. Our customer also had the receptivity to new ideas and promptly accepted to use Scrum. Since then, it has been a great journey of learning Scrum in the field, where the "battle" happens.

First of all, let me say that this project is quite complex because it consists of developing a platform that must replace an existent one. Due to the dimension of the problem, we couldn't do a Big Bang approach, which means every design decision must coexist with the existent platform. I will make a retrospective in some aspects of Scrum and try to figure out what has been good and bad. Let's begin.

Daily Scrums

In Scrum theory the daily scrum must be the first activity of the day, everyday at the same hour, at the same place. The first change we had to made was to shift the daily scrum to the middle of the day, as opposed to first thing in the morning. Basically, it was impossible to have all the elements of the team at 9:00 AM or 10:00 AM. Currently, the bell rings at 12:00 and we start our stand-up meeting in a small room.

The duration of the meeting must be 15 minutes. We must answer to 3 questions: What did I do yesterday, What I'll do today, and what are my impediments. When the team grew, we had some difficulty not exceeding the 15 minutes. In fact, we exceeded that time in many occasions because there was a great temptation of starting discussions in the daily scrum. We are better now and, if we feel that there is something to discuss, we wait until the end of the meeting and the guys that want to discuss stay in the room.

The daily scrum is something religious for us. We all know the state of the project. We all know what each team member is doing. We all know the problems we are facing. The daily scrum is absolutely essential.

The Sprint Planing Meeting

Every sprint begins with the Sprint Planning Meeting. First, we and the product owner choose the items we want to include in the sprint. Then, we start to plan our sprint identifying the Sprint Backlog Items to be made. In the Scrum theory it's said that the tasks must be estimated to have the granularity of 4-16 hours. We found difficult to do that in some features. To achieve that estimation precision we have to do in-depth analysis, which can't be made in half a day. What we do is estimate the feature in days, and the preliminary tasks in hours. Later, during the sprint, when we have more information, we split the feature in smaller tasks.

Sometimes we wonder the time wasted if in the beginning of the project we elaborate an in-depth planning, with tasks, dependencies, resources, etc. Wow, it certainly seems scary :-)

The Sprint Backlog Items

In my opinion the Sprint Backlog Item is the most important artifact in Scrum. However, this is only true if the Sprint Backlog is up-to-date and reflects the reality. There is some impedance in some guys to update the Sprint Backlog daily. I had to point the finger sometimes, but we are getting better. We're using Visual Studio Team System with the Conchango plugin to manage the work items. My first activity in the day is to watch the Sprint Burndown Chart to evaluate the state of the project. This way is quite simple to spot the guys that aren't updating the sprint Backlog.

By the way, the plug-in from Conchango is certainly useful but it could be better. For instance, I would like to have the global vision per day, and per work item, in one sheet.

Sprint Review

We finish our sprints making a demo to the product owner of the features included in the sprint. In the firsts sprints we didn't use powerpoint. Now, before the demo begins, we present a powerpoint with a few slides to remember all attendees in the room the objectives of the sprint, what we can accomplish and what we can't.

The Retrospective Meeting

We all love this meeting. We are absolutely honest with each other. There are no ceremonies. If I have to say "in this Sprint you were a chicken", I'll say it. Total transparency is our motto.

As a conclusion I must say that I am a big fan of Scrum. However, don't be eluded: there are no perfect methodology. By the way, we are late in the project (which can't be attributed to Scrum use), but I think that there is a big difference in this lateness: everyone knows that we are late, and everyone knows it when the lateness shows, not only when the project is halfway or almost finished. Scrum is transparency!