Roots of Lean 2010 is taking place next week. This week we are in Tokyo to prepare the trip, get over the jetlag and inhale a little japanese culture. Yesterday we went to a Sumo Stable to see the wrestlers train in the morning. My respect for Sumo Wrestling is now in a completely different place than it was before. To see the combination of strength, speed, tactics and flexibility in these big guys was impressive.





The serious stuff:

Every year we spend plenty of time to create a tour where we will se many different companies and get new angles to what lean really is about. The two last years, it was part of the program to meet with managers from Toyota, besides seeing the plant,  in order to  ask questions and dive deeper into what we had seen. Last year we were  lucky to meet Mr. Ishii - General Project Manager for Toyotas Software Division.  We had two very intense hours with him, where he openly shared how Toyota develops software, and what challenges they have. Recently Henrik Kniberg, from Crisp wrote this interesting account of that meeting.

This year we are not going to talk to managers from Toyota. They are too busy with other stuff - Instead we are going to meet a truckload of other fascinating companies and people. Starting Monday wíth a visit to the Leading manufacturer of Industrial Robots - Fanuc at the foot of Mount Fujii.

Stay tuned on this channel next week to read more.

By Bent Jensen

If results are not the point - then what is?



March 10. we've arranged a talk by Lean Software pioneer Mary Poppendieck at IT-Universitetet in Copenhagen. Check your calendar and sign up - It's free! Check details here (in danish)

As you may now Mary and Tom Poppendieck has recently published their third book 'Leading Lean Software Development: Results are not the point'. Check it out at Amazon.



Mary and Tom is also doing a 2-day workshop i Copenhagen March 11 and 12. Check details here.

We hope to meet you there.
By Sune Gynthersen

Here is a nice blog-entry about what you can learn when you actually engage with your endusers.

Gemba in the virtual world



By Bent Jensen

Currently I am attending a BestBrains course with Mary and Tom Poppendieck on Lean Software Development (see more here).

On the course there are people from companies in UK, Germany and Denmark, it is an interesting combination of different views and experience.
Even though I read the two books from Poppendeick many years ago, it has been an inspiring day with many stories and cases from companies around the world.

We did two Value Stream Maps based on some real life cases from the participants, and the people presenting the results had a hard time when Mary started to ask a lot of “why”-questions. I am sure they got a lot of valuable things to work with at home.

Some of the take-away I got from the first day:

• Focus on bad news first: That makes the organization focus on constant improvements (Toyota does it).
• Copying Toyota is also copying someone else solutions to their problems and that is not solutions to your own problems. Lean from Toyota and improve it.
• To make real user value, you have to see and understand it from eyes of the customer/users.

Especially the last bullet is so important, and if you want to learn more in this area, I can recommend a BestBrains workshop at Øresund Agile on May 14th: “Capturing Requirements and Agile Planning“ http://oresundagile.org/workshop-7. It might change how you define your systems to be built in the future...

By Mads Troels Hansen

Yesterday was a really long day, and I have to admit I was to tired to write a blog entry. So here is the field report from day 2 of our Lean study tour. To be completely honest with you - I felt incredibly privileged about what I experienced in Nagoya yesterday. First we visted Toyota Commemorative Museum of Industry and Technology and the Motomachi plant like Jesper mentioned in his earlier blog entry - I would definitely recommend both to anyone visiting Japan.

After the plant tour we met Mr. Satoshi Ishii who is a project general manager at the BR Automotive Software Engineering Dept. within Toyota. In short, these guys are doing all sorts of software that is embedded in modern Toyota/Lexus cars. Satoshi Ishii explained to us that a modern Lexus (Toyota's luxury brand) contains 70 or more ECUs (electronic control units) which all needs software (brakes, engine, fuel injection, navigation, adaptive cruise control, etc.) along with the ability to communicate with each other.

Before the meeting I was a little skeptical - Were the Toyota culture so strong that it had found its way into the relatively new field of software development? What might surprise some, was that they were using a waterfall model (in Ishii-san's own words - in reality I think it was more like the spiral model). In spite of that, I had a feeling afterwards that I had just talked to perhaps the most skilled software development managers I have ever met! Does that sound like a paradox? I do not think so.

Let me explain it this way. I once said to myself that I did not want to waste my time as a developer on non-agile projects. In the Toyota case, I would certainly make an exception. Why? Because I believe that the principles that this company is built upon is of far greater importance than any of the agile pratices that we spent so much time on in the Western world.

After meeting Mr. Ishii, I had a talk with Mary Poppendieck (who is also with us on this study tour) and she believed that this was actually the first time a Toyota manager in software development has ever spoken publicly about how they apply their (Lean) philosophy in this field - I almost had the goose bumps

Trust me... I will write more about the all the learnings of this meeting - but now it is time for preparing a presentation for the Agile Japan group tomorrow.

By Sune Gynthersen

Today was the first official day of our Lean study tour "Roots of Lean 2009" in Japan. We started out this day by visiting Fujitsu Applications Ltd. in Tokyo. President and CEO Jun Watanabe gave us an introduction to how Fujitsu Applications had implemented Toyota Production System/Lean in their software development business.

Two things stuck me in particular.
1) Their use of standardized work (well-defined processes for how, when, and what to do). In the Fujitsu case I believe this was one of the major contributors to the productivity improvement they had experienced. Throughput had gone up by a factor of 7 - over a period of 6 years - without hiring more people!!
    
2) Changing the method of software developmet to a very manufacturing-like way had certainly improved productivity, compared to what they did before their TPS transformation. However I asked myself: They are paying salary to 300 employees - are they really utilizing the talent that they are paying for? I got the impression that maybe they were focusing a bit too much on Point Kaizen rather than System Kaizen.

Also we met Tomoya Saito who gave a talk on how Fujitsu Applications were crunching data from employee timesheets and measurements of progress in a way I have never seen before. What they were trying, was to do really fast estimation on a large scale. They were doing this using statistical theory and a high volume of historical data. I did initially feel slightly skeptical about it, but it has surely given me something to think about!

By Sune Gynthersen

The other day Danish newspaper Politiken had an article about how Toyota is renting a ship to store unsold 1200 cars in the harbour of Malmö, the Swedish town just across Øresund from Copenhagen. My guess would be that there's some hansei - reflection in Japanese - going on at the world's best manufacturer and the inventor of Lean. Obviously, Toyota has been producing to forecast and not to actual custumer pull. Some of the questions the people at Toyota probably could be asking themselves are these: Why didn't we sense the actual market conditions during the fall of 2008 and changed our production schedules? Why did we resolve to wishful thinking about customer demand? Why did we end up with overproduction? - the worst of Toyota Production System genius Taichi Ohno's seven types of waste in manufacturing.

When I saw the picture of unsold cars accompanying the article in Politiken I once again had the thought: Wouldn't it be nice if overproduction could be much more visible in software development? In much software development people are also producing to very uncertain forecasts without being in contact with the actual customer pull. And in software development the forecasts come in the form of big specifications of features that in many instances end up being delayed. And even worse, features not being used by the users when finally implemented.

If we had to rent ships to store all the implemented, but unused features, there might be some more hansei going on to avoid implementing those features in the first place?

By Thomas Blomseth

A task board has been used by many teams when doing Agile development to have a shared place to manage tasks in the iteration.  I have used it myself in a lot of different formats when working with R&D development, customer projects and also working together with offshore teams.

It can be a great tool for the team and creates more collaboration, feedback and risk mitigation when having a visible task board.

But, you might also have more frequent requests from other teams or customers and maybe you also work with maintenance tasks of existing products in production. It can be challenging to combine focus in the iteration with different ongoing requests.

One alternative approach to the traditional task board and iteration planning can be a Kanban system. Kanban is the Japanese word for visible card and originates from the Toyota Production System. It is used to minimize inventory, enforce Just-In-Time and eliminate waste.

I have used the Kanban approach to extend the traditional task board with limits on the number of concurrent tasks in different states to reduce work in progress and apply a more pull oriented process. When working with many different specialists in one team, I have also seen high value by extending the board with more states to manage the work of the different specialists. It makes it much more visible and easier to follow the flow and find wastes in the process.

In one team we combined the Kanban approach with a two week release rhythm and that enabled the team to both have a rhythm of planed activities and also do more frequent business requests depending on their capacity and the business prioritization.

The combination of the more traditional iterative processes together with a Kanban approach is very interesting, and I think many teams and organizations will find a lot of value and increased productivity looking into this area.

By Mads Troels Hansen

There is a lot of good stuff about lean on the Internet. Some of my favourites are:

Gemba Panta Rei: This is hosted by Gemba Research, a Washington DC based consulting company. Jon Miller, the main contributor, has a lot of insightful and interesting posts. For example the latest blog post is about how Dwight D Eisenhower could be seen as a lean thinker

Lean blog is written mainly by Mark Graban. It has a lot of good stuff, much of it related to Lean Healthcare, which is Mr. Grabans main interest. It also hosts a podcast service: lean blog podcast with interviews with leading lean thinkers to put on your MP3 player. For instance in episode #43 you can hear a wonderful impersonation of Dr. Deming, telling why Six Sigma is not in line with his philosphy.

The Elegant Solution, by the author of the book of the same name is a well-written blog about lean and Toyota. See for instance this post about A3 -thinking

By Bent Jensen

In a "Traditional"  approach to estimation a set of detailed requirements are analyzed, and from that analysis a solution is designed that will fullfill these requiments. We then estimate the time it will take for us to build that design.

If we do Agile development, we instead measure the relative size of each of a set of high-level requirements (e.g. in the form of User Stories). We then assign a conversion factor to the relative sizes of the User Stories, to be able to predict, when we can have what done. If we do not know how long time it takes, we can do a small iteration, and see how much we are able to complete in e.g. a week. We then use that knowledge to extrapolate from the whole set of requirements, to arrive at a delivery date.

If I am to choose from those two methods, I will greatly recommend the latter. simply because the detailed analysis and design, always misses something, and because it has an underlying assumption that nothing, or very little will be changed over the course of the project - thus the investment in the detailed analysis and design is justified. Anyone who has created software in the real world know that is never the case.

But both approaches treat estimation, as if the size of a piece of functionality or time it will take to complete it, is a real characteristic of the feature, and what we do in estimation is trying to find that hidden, true number.

I will call both these approaches Reactive estimation.


And off course there is something I will call  Proactive estimation. In this kind of estimation, the estimators acknowledge that creating a piece of software, is a creative process, where problems are solved on a daily basis, and that the level of teamwork, dedication, creativity and problem-solving skills are the factors that really determine the lenght of a software schedule. In this kind of thinking, a team will commit to deliver a product to a certain date, but they know, that what will be delivered, will depend on their ability to learn and solve problems along the way. The development process is then organized to accelerate learning, and plan  in a way that keeps decisions  open as long as possible. In that way the team will arrive at the best possible result at the given date.  Much the same way a play normally always will have premiere at the date that was planned months of even years earlier.

Does this sound to crazy to you? Maybe - but that is the way Toyota creates new cars, on time and with fewer resources than their competitors, and I am convinced that some kind of proactive estimation was used when the iPod and the iPhone was created.

By Bent Jensen

In April 2008 we went on an eye- and mind-opening study tour to Japan.  We visited a number of software companies, saw Toyotas Tsutumi plant and met the Agile Software Development Community in Tokyo.

We are planning to do a similar tour the week of April 20'th 2009.  This time the two leading thinkers in the area of Lean Software Development; Mary and Tom Poppendieck will join us.

The trip will allow a first hand experience of the japanese society and business life, as well as visits to a number of lean companies.

There will be a limited number of seats available to customers and friends

If you would like to participate, please write to bent.jensen@bestbrains.dk

By Bent Jensen

Back about a month ago we arranged a free lecture at the Copenhagen-based IT-University, with Lean Software pioneer Mary Poppendieck. Though a little late, we now have a copy of her slides available to all the participants. We very much hope you enjoyed the evening and got a chance to mingle with other agilists.

Download the slides here.





Some of the participants wrote blog entries about the experience. Check them out here: 100% Scrum is not 100% Agile and  Agile theses and mistakes


By Sune Gynthersen

Last weekend I took a minor holiday to the german capital, Berlin. On sunday morning I went out to find a place that served breakfast and I came by a nice litte bistro. I was with a small group of friends, so we ordered breakfast based on personal preferences. I had scrambled eggs, some had coffee, bread and croissants, and so on. After taking our orders the waitress went inside (we were sitting outside) for a few minutes. Then she came back -- or so I thought. She went by us, turned left, and entered the bakery that was located pretty much right next to the bistro. A few moments later she came out with a plastic bag that seemed to hold exactly what we ordered. She got back inside the bistro again, and a couple of minutes later our breakfast was served.

Reflecting on what I just saw, I concluded the following. Right after taking our orders she went inside and started on the scrambled eggs. At that time she probably notified the bakery on exactly what items to prepare for here. Afterwards she went out and got the bread that we had ordered, but no more.

Lesson learned. Keeping trusted key suppliers close, allows you to have very low inventory of the most "problematic" items. For instance freshly baked bread, which decays very fast, and is not suited for selling after a matter of hours. Even if you pay a higher price for picking up bread in smaller batches, the bakery -- not you -- will end up with the bread that can no longer be sold, and thus you will rarely have to throw out food. The strategy also allows you to spend the scarce space you might have in your bistro, on more value adding abilities, like setting up a table with a blender and serve smoothies!

The bakery is probably happy with the setup, as their incomming orders are now levelled out on the entire day, instead of having to prepare big batches in the morning. Furthermore the customers are probably more happy as the average time from bread leaving the oven until it is served, is now shortened, resulting in bread that is still slightly warm, and tastes better.

 

By Sune Gynthersen

Some thoughts that popped up on my first day of attending our Poppendieck course on 23th of June.

Knowledge inventory

The concept of “Zero Inventory” is not desirable and in fact does not hold in Toyota (go to the production plant and notice the trucks on the park yard outside the factory with inventory waiting to load it into the factory – the drivers are sleeping some times), its all about having the correct amount of inventory.
So! Mary keeps a log book containing what programs she installed on her laptop and what problems she experienced (hope she doesn't mind me telling this in public). When there is a problem on the laptop, she goes to look into the log book instead of googling it again spending time on finding the same site as 6 months ago, wasting time on finding already acquired knowledge – relearning, which is waste.  
Well. This log book is knowledge inventory. Knowledge that we keep close to us, ready to use, but it takes up space and the more we have, the more difficult it is to find the knowledge we need. In software we do not have physical inventory, like wheels ready put on a car in a car factory plant, but we have knowledge inventory. So how do we produce the correct amount of knowledge inventory?

Knowledge briefs

Lets go to the source. When we make knowledge and put it into our repository (perhaps a wiki), we should make the knowledge condense, then it is easier to find - and use. But it is difficult to make knowledge brief! If I make a four page documentation of a feature, and come back six months later, I will spend time  

Because knowledge in wikis are knowledge inventory, and tend to grow and grow. Too much get a burden, you cannot find things and when you find a document, its four pages long and the valuable knowledge is hidden in a lot of irrelevant noise. (Can search engines solve the problem of finding useful knowledge in a split second on the internet? I don't think so.)

So what about a wiki that have limited space? You can only put 2400 characters on a page, because if you put on more, you build up too much knowledge inventory. “If you cannot fit your knowledge into an A3, use an A4”. Constrain yourself to condense it even more – extract the important parts e.g. the exceptions in the business case that you only found out about later, and spent time on trying to grasp.  

I want to make an exercise on our next workshop to practice the art of making knowledge brief, to avoid building up knowledge inventory.
And last thoughts: Are knowledge always written? Can you build condensed knowledge in pictures and graphs?

By Jesper Thaning

Will Agile Software Development end on the dumping grounds of History? This June Mary Poppendieck will present her view on how the move to agile software development, needs to be done cautiously to avoid repeating the mistakes the IT industry has previously encountered while adopting new methodologies and paradigms.

June 23th and 24th, BestBrains is arranging a 2-day Lean Software Development course in Copenhagen with lean software pioneers Mary and Tom Poppendieck. In connection with this course we have also arranged a free lecture June 24th, at danish IT-Universitetet. Mary and Tom are well-acclaimed authors of the popular books "Lean Software Development" and "Implementing Lean Software Development", which describes how to use Lean principles to improve software development organizations.

See more about the comprehensive 2-day course here (or in danish here), and the free lecture at ITU here.

We are looking forward to seeing you there!

By Sune Gynthersen

Wednesday night I had the opportunity to visit Valtech's premises in Paris. They are located just besides the Triumphal Arch and Champs Elysses, so this time I got a real Paris expericence (last time I stayed one night at a hotel near the airport - not exactly exciting). I did a presentation on Lean Software Development, to a group of Valtech Consultants and Greg Hutchings who was my original contact with Valtech. We had a good evening and a interesting discussion afterwards, while drinking french wine and eating pizza. Gilles, one of the pariticipants wrote about the evening in his blog.

By Bent Jensen

Wednesday we visited NEC and Change Vision, both located in Tokyo. At those visits we got the chance to see one of the major Japanese corporations in the IT industry, as well a small software company.



We started out the day by visiting Change Vision, a company founded by Japanese author Kenji Hiranabe. We got a presentation of the two products of the company, JUDE and TRICHORD. Both seemed to be built on the idea of "mieruka" (making visible), which is a concept used by Japanese organizations for sharing information by making it visible in an easily understandable form.

While noticing the extensive use of simple visuals for tasks, metrics, ideas, releases and retrospectives, I have to admit what personally struck me the most was the bug-tracking system of Change Vision. It was visualized using LEGO bricks in a constrained physical space. This provides kanban-like control of the "bugs in process", by showing not only the variation in complexity of bugs, but also making it easy for everyone to see when you are running out of "slots" for new bugs, and thus have to start fixing some. Personally I just can't wait to try this visualization idea back home.

Judging by the discussions that took place after the visit, I think we all got a lot of inspiration from visiting a truly agile environment.

Later the same day we visited NEC for a techical presentation as well as a presentation focused on their development process. During the visit we learned that NEC had experimented with using Toyota Production System (TPS) a.k.a. Lean in the development process, for instance with the use of a kanban system to control the workload between different parts of the organisaion. Most surprisingly the system was put into place for controlling hand-offs between design, code, and test-phases. I think that as a group of agile thinkers, we were a bit stunned by this implementation.

NEC had also experimented with the TPS "stop-the-line" practice, in their development process, but had abandoned it due to inefficiency. Unfortunately we did not get a chance to hear the reasons that led to this conclusion.

(BestBrains getting a demonstration of Japanese innovation. This is an NEC electronic whiteboard with a built-in printer!)

By Sune Gynthersen

Tuesday was Toyota day. Destination: Toyotas Tsutsumi plant in Toyota City just outside of Nagoya.

To get there we had to take the Shinkansen from Tokyo Station. Seeing  the  Shinkansen 700 series silverarrow slide into the station, be seated in the comfortable compartment and drive silently towards Nagoya with a speed of more than 300 km/t was an adventure in itself.

In the factory, we were guided through one of the assembly lines, and the automated welding process.  At the plant Toyota produces Camry,  Premio,  Allion, Prius, Wish and Scion tC.

These models are produced on two lines, in a mixed production each car on the line is a  different model and color from the previous one. Only that way Toyota can remove the waste of overproduction by not  producing cars, that has not yet been ordered.

The first operation we saw was the door assembly. Toyota uses door-less assembly where doors after painting the doors are removed from the body and they each follow their own route to later be united again in final assembly. The advantage of this is easier access to the inner parts of the car, and less damage to the doors.

The best analogy to what we saw is a ballet. Workers did their work with a choreographed set of movements, designed to be the minimal effort to do the work and ensure good ergonomic.  Nobody was running and nobody worked ahead of the line.  The spirit of Taiichi Ohno was strong and alive.

Surely the work of producing a lot of completely similar things can never be as varied as other kinds of work in the modern world. However our whole standard of living is based on the society’s ability to produce low-cost, high quality items. And Toyota is able to transform this into a system that protects the individual and gives everybody challenges,  by having everybody involved in improvement efforts – Kaizen.

We also saw several examples of Andon pulls and stop the line philosophy.  Here it was clear that while the Stop The Line philosophy is what creates quality and is making sure systemic problems is eliminated quickly; it is also the lubrication that keeps the line running smooth.  Most of the Andon pulls was just small problems, that was solved immediately by having the supervisor help getting things back on track.

Further into the factory we saw the supply lines to the door assembly. A clever worked out system allowed a worker to create “kits” for each set of doors coming along the line.  By having models be mixed on the individual level (I do not know if any other manufacturer does this?), a need for standardizing is also created.  Assembly will be easier, when the parts are the same in more models.

Finally in the end of the line new cars flowed into to final verification:  a Blue Prius followed by a Green Camry, Followed by a Scion. Impressive.

 

 

 

 

(we were not allowed to take photos - the picture about is a official photo from the plant)

We sometimes hear Lean be accused of being just a new cost savings philosophy.  Yet another clever trick from management! But Toyota shows it is possible to create a challenging, respectful workplace in what is normally considered the most de-humanized kind of work (think of Chaplins “Modern Times”) . So why shouldn’t we be able to do that to in other areas, It should be easier,  not more difficult to apply lean to healthcare, service,  and Software Development by the way.

(Some of the participants in the Toyota Museum)

By Bent Jensen

We are all busy preparing for our Japan-tour. Some are out buying business suits, so we can have the right look. Others are busy buying typical danish small things as presents for our hosts.  And I was practicing a typical Japanese thing: To have my photograph taken with my hero.

In the picture you see me with Jeffrey "Toyota Way" Liker. Jeffrey Liker is the person outside of Toyota that knows most about the company. He has written several books about Toyota, including the world famous: The Toyota Way, where he observes Toyota, and construct it's innner working in 14 principles.
Jeff gave a lean master-class today in Copenhagen. It was a highly interesting and inspiring day. Especially I learned interesting things about Lean Product Development
and the function of Toyotas Obeya, which I look forward to use.
 
By Bent Jensen

In April we will go on a pilot trip to study lean in Japan. We will visit Toyota, see a plant and learn about TPS from the masters. Also we plan to visit several IT companies that are using lean in their development process. We hope to be able to offer these trips to our customers once of twice a year in the future.

Maybe we will even be able to see this homage to XP performed live http://www.youtube.com/watch?v=zpw8h4OGNxg

By Bent Jensen

In his classic book about Toyota, The Toyota Way, Jeffrey liker describe the 14 management principles that are guiding the way Toyota operates.  These principles explain why Toyota is different from other companies and so much more successful.

Principle #13 is about nemawashi: The way Toyota makes and implements decisions.

Liker describes the principle this way:

Do not pick a single direction and go down that one path until you have thoroughly considered alternatives.  When you have picked, move quickly but cautiously down the path.

And about the  process:

Nemawashi is the process of discussing problems and potential solutions with all of those affected, to collect their ideas and get agreement on a path forward. This consensus process, though time-consuming, helps broaden the search for solutions, and once a decision is made, the stage is set for rapid implementation.

How can we apply and use Nemawashi in our organizations and how does it fit a agile approach to software development?

There are two aspects of Nemawashi.  First of all it is a thinking process. By deliberately not deciding before all alternatives and risks has been considered, we avoid a kind of habitual thinking, where we just take the first solution that comes to mind, and start implementation immediately.  If we are always are guided by our habits, there will be very little innovation and new thinking. Second, it is a way to create support and engagement from everybody involved. By consulting people involved, carefully listening to their opinion and incorporating it in the proposal, the chances for successful implementation are much better, than if implementation and decisions are forced through.

A common understanding of agile development is that it is more about “doing” than “thinking” and most Agilists are sworn enemies of Waterfall processes with detailed planning up front planning.

So how is nemawashi different from waterfall planning?

Toyota has the concept of The Gemba – the real place, where actual work is done. Any planning activity is done close to or at The Gemba, and not in an ivory tower far from reality. Second  The process of considering alternatives and risks will be a process that is driven by experiments and trying out things – what in product development is called Concurrent Set Based Design.

The ability to do lightweight planning and quickly decisions, as we do it in agile development,  is based on having a software development system, that allows us to have low cost of change, and rapid feedback.  If we think that all processes in a company or in a development group will work the same way as we implement new features in our software, we may make a dangerous mistake.

There is a number of decisions that are not easily reverted, and  does require input and adjustments from many involved people to be successfully implemented. Examples are hiring of new staff, architectural decisions, and changes in organization.

If you hire new people, and have not assured they fit well into the team, or you have not carefully accessed, that they have the skills and competencies you are looking for, it can be very costly to correct. If you decide to start using a tool to manage your development process, because a vendor recommends it, or you know somebody else using it, you are likely to pay a high price, for a too hasty decision later.

A final quote from the Toyota Way:

If you’ve got a project that is supposed to be fully implemented in a year, it seems to me that the typical American company will spend about three months on planning, then they’ll begin to implement. But they’ll encounter all sorts of problems after implementation, and they’ll spend the rest of the year correcting them.

However, given the same year-long project, Toyota will spend nine to 10 months planning, then implement in a small way such as with pilot production and be fully implemented at the end of the year, with virtually no remaining problems.

Alex Warren, former senior vice president,

Toyota Motor Manufacturing, Kentucky

By Bent Jensen

Three important principles of agile development are:

1. End to end development of small batches of work
2. Make problems visible
3. Limit work to capacity

Unfortunately it is not uncommon for teams, adopting agile methods like e.g. Scrum to somehow miss these principles.

I have a number of times watched teams plan and estimate work, they believe they can do in one sprint. After a few days, it is clear that the team lag behind. The immediate reaction is then to start to try to work faster, either by putting in longer hours or by sacrificing quality. In that way a Scrum sprints really live up it's name – a headless rush towards the goal. The result of having sacrificed all three principles mentioned above is a demotivated team and a growing pile of technical debt.

It is important to realize that the great benefits of agile development, will take some time to manifest themselves, and the best way to make them manifest themselves, is to avoid focusing too much on getting a lot dot done when starting to do agile development. Instead you should look carefully on how things are done.

For instance it is a common problem that developers lack information about features they need to work on, which will either slow them down or in order to not be slowed down, make them start guessing what it is they are supposed to do. This is a problem that should be made visible and dealt with at its root cause.

Another common problem is that features are not completely done when the iteration ends. Either they are not doing what they should, or is has not been verified that they actually work.

These two problems are just examples of problems a team starting to do agile development can and will encounter. It is important to embrace problems as opportunities for improving processes in a way that will create a more lean and flexible development environment.

So in your agile adoption:

admit we are all tortoises and we will not become hares just because we do agile development!

 

By Bent Jensen

Creating quality software on a continuous basis is a complicated business.

I think it is a sign of maturity if your team can admit that there are daily problems which are ultimately obstructing flow. While not everyone will appreciate that your team does a complete halt until the obstruction has been removed I think it is a necessity for a team to stay in good shape and continue to deliver frequently.

Just the other day I came to think about what were the most common obstructions of flow we see in software development environments. So here is my preliminary list -- I bet you have seen them all.

1. Build breaks
If you don't have a build, you don't have anything. Nobody is able to do any progress progress as the state of the product is unknown. Developers cannot check-in, as they will not get any response from the continuous integration environment. Testers cannot try out the latest build. Users cannot see the product in action, and the list goes on. A build break is like a blindfold, and you should treat it as such. Don't try to go anywhere until you have your vision back.

2. Test failures
If you have a failing test, you have dysfunctional software. Imaging somebody fitting some cool new styling parts on to a car with a busted engine. Now, who would ever do that? It really is the same with software. Why do any feature work on a software product which has a failing test? I know this can be hard to respect, especially when a deadline is closing in on the team. Deadlines however, does not justify continuing without stopping the line upon test failures.

3. Bug reports
If you have bug reports, you have dysfunctional software. There is no need to do any feature work, until the product is stabilized. Bug reports are even worse than failing automated tests as those bugs can only be reproduced by a human. You should not spend work hours on anything but writing tests for these bugs, and fixing them.

4. Any other blocks keeping the team from a steady flow
If you are experiencing an obstruction which is keeping from moving forward as fast as you could, suggest to the team that you stop doing anymore feature work, until you are able to eliminate the obstruction. One obstacle which I think is quite common is builds that take way to long time. "Yeah, but how can you build 2 million lines of code in less than two hours?" -- Well, I suppose you could start by reorganizing your code and build only the module related to a particular source control check-in. Hopefully you don't have modules consisting of 2 million lines of code!

I'd like to hear about any other obstructions you may have experienced in a software development environment.

By Sune Gynthersen

There seems to be some confusion regarding what is lean and what is agile software development. Sometimes they are treated as essentially the same and at other times some (agile people) think that lean is just another management fad, while agile is the real stuff. In my definition Lean is a management system, that under a set of principles has as its ultimate purpose to eliminate waste in all processes. For each different business a lean system will look different. For a large number (maybe the majority) of software developing organizations, agile methods, are examples of processes with inherently little waste. So they form a good starting point for a lean organisation. Below that is a set of engineering principles (test early, continuous integration etc), of which many came together in eXtreme Programming, but has been used by good developers and organizations for many years. These are the sound groundwork any lean organization should build upon.
Computerweekly had this interesting article on the topic yesterday.

By Bent Jensen