Ative at Work : lean

Reboot Your Management

Martin Jul — Fri, 26 Jun 2009 13:05:00 GMT

How would you rebuild a country after a world war? How would you reboot your management?

This was the topic for my presentation at the Reboot conference.

It concerned Deming's 14 principles for management, the humanistic, long-term thinking, keep learning, use the scientific method, and build from quality philosophy, that helped shape companies such as Toyota and Honda..

Researching the background of his work, it was interesting to see how the World-War 2 Training Within Industry principles played a big role in shaping his ideas and how its focus on operating from a basis of scarcity - such as saving material, time and labour to win the war faster, plays so well in an entrepreneurial setting and in cutting through the big-company trap of just throwing more money at problems.

The slides from the presentation are in English and I have posted them for download and comments here:

http://www.ative.dk/om-ative/downloads.aspx

Read more Reboot stuff:

Web: http://www.reboot.dk
Twitter: #reboot11

What is a Truly Lean Company? - Deming Distilled

Martin Jul — Thu, 07 May 2009 13:12:00 GMT

Deming's work is the foundation of the Toyota Production System and modern-day lean. I recently conducted a workshop his 14 points for management. One exercise was to group them to get to their essence. Here is the the result:

“Practise engaged leadership” - hands-on and collaborative (points 7 and 2 – institute leadership and lead the transformation)
“Improve constantly” (points 1, 5 and 3 – provide jobs by building quality in and constantly improving the system)
“Look at the organisation as a whole” (points 9, 4 – end silos and look at total cost)
“Develop you competencies” (6, 13 – institute learning while working)
“Measure the system, not the individuals” (11, 10 – remove slogans, quotas, substitute leadership)
“Engage the people” (14, 8 – include everyone in improving the organisation and remove fear)
“Develop intrinsic motivation” (12 – remove the barriers to doing great work)

As you see, the lean principle of Respect for People is right at the core: leadership is participatory and collaborative, and the aim is to create jobs that people are happy to do.

A more elaborate description of a company based on these principles would be something like this:

A “Deming 14” company aims to sustainably provide great jobs by being highly competitive.

It is based on respecting the people and driven by their intrinsic motivation and the passion for doing a good job.

It leverages this passion to constantly improve the quality of the work by removing obstacles in the production system as they are identified. The focus is always on the end-to-end process rather than the individual steps.

It constantly takes the time to make experiments to learn how to do things better and uses the best new knowledge to improve.

To enable free, objective experimentation the company removes fear and focuses on the system rather than the individuals.

As a basis for the improvements, the company actively takes the time to learn on all levels, all the time in the context of the actual work.

The success of the company is built on engaging everyone in the work, and leadership is hands-on with an understanding of how everyone’s knowledge and contribution is needed to succeed.

Think about that for a second. How does your company compare?

PS: If you are interested in learning more about the 14 points and their application in IT there is a new edition of my handbook "Ud af krisen" available on our website as a free PDF-book in Danish. Get it here: http://www.ative.dk/om-ative/downloads.aspx

New Lean Reading List: Shingo Prize Winners Announced

Martin Jul — Tue, 31 Mar 2009 12:46:00 GMT

The recipient's of this year's Shingo Prize have been announced.

The Research and Professional Publication Prize category is a great reading list for new lean books:

Steven Spear - Chasing the Rabbit. A book on how to catch up with your lean competiors. HBR review here.
Mark Graban - Lean Hospitals. The book by the productive author of leanblog.org.
John Shook - Managing to Learn. Focuses on Toyota's visual A3 management tool.
Professor Peter Hines; Dr. Pauline Found; Gary Griffiths; and Richard Harrison - Staying Lean: Thriving, Not Just Surviving.
Jeffrey K. Liker, Michael Hoseus and the Center for Quality People and Organizations - Toyota Culture. Great author, new book. What's not to like?
Durward K. Sobek II and Art Smalley - Understanding A3 Thinking. Another winning book on Toyota's A3 tool from Productivity Press.

Off to the bookstore!

Improve your IT-organisation with Deming's 14 points

Martin Jul — Fri, 12 Dec 2008 10:20:00 GMT

I have written an introduction to Deming's 14 points and how they can help you improve your IT-organisation. It is a 15-page PDF in Danish. You can download it here:

Ud af krisen - http://www.ative.dk/media/989/ud%20af%20krisen%20-%20ative%20-%20a4.pdf

Enjoy - and please send me feedback on how to improve it. :-)

All the best,

Martin

Out of the Crisis - Deming's 14 Points

Martin Jul — Wed, 05 Nov 2008 13:57:00 GMT

In a time where so many are excusing their failure with externalities and saying "it's the crisis" we need leadership and entrepreneurship more than ever. We are in a time of creative destruction and it is precisely these moments that offer great opportunities to those who seek out the new ways of success.

In the early 1980es, the West faced a similar situation. We were blaming our failure on the Japanese manufacturers "dumping" products - selling below cost, because "no-one could create products so cheaply". Inefficient companies were threatened. Unproductive jobs were lost. The dinosaurs who would not or could not adapt lost their positions. And those who found news ways to improve productivity prospered.

At that time Dr. Deming came to the fore. His book, "Out of the Crisis" provided a comprehensive overview of the profound system of production that he had taught the Japanese to help them recover from the Second World War. The time had come to apply it in the West.

It has much wisdom and it is as relevant today as it was then.

Here are his 14 points, the essence of his teachings:

1. Create constancy of purpose toward improvement of product and service, with the aim to become competitive and stay in business, and to provide jobs.

2. Adopt the new philosophy. We are in a new economic age. Western management must awaken to the challenge, must learn their responsibilities, and take on leadership for change.

3. Cease dependence on inspection to achieve quality. Eliminate the need for inspection on a mass basis by building quality into the product in the first place.

4. End the practice of awarding business on the basis of price tag. Instead, minimize total cost. Move towards a single supplier for any one item, on a long-term relationship of loyalty and trust.

5. Improve constantly and forever the system of production and service, to improve quality and productivity, and thus constantly decrease cost.

6. Institute training on the job.

7. Institute leadership. The aim of supervision should be to help people and machines and gadgets to do a better job. Supervision of management is in need of overhaul, as well as supervision of production workers.

8. Drive out fear, so that everyone may work effectively for the company.

9. Break down barriers between departments. People in research, design, sales, and production must work as a team, to foresee problems of production and in use that may be encountered with the product or service.

10. Eliminate slogans, exhortations, and targets for the work force asking for zero defects and new levels of productivity. Such exhortations only create adversarial relationships, as the bulk of the causes of low quality and low productivity belong to the system and thus lie beyond the power of the work force.

11. (A). Eliminate work standards (quotas) on the factory floor. Substitute leadership. (B). Eliminate management by objective. Eliminate management by numbers, numerical goals. Substitute workmanship.

12. (A). Remove barriers that rob the hourly worker of his right to pride of workmanship. The responsibility of supervisors must be changed from sheer numbers to quality. (B). Remove barriers that rob people in management and in engineering of their right to pride of workmanship. This means, inter alia, abolishment of the annual or merit rating and of management by objective.

13. Institute a vigorous program of education and self-improvement.

14. Put everyone in the company to work to accomplish the transformation. The transformation is everyone's work.

Reading assignment:

Read (re-read!) Deming's "Out of the Crisis" to get the basics.

Read Peter Scholtes' "The Leader's Handbook" for a comprehensive guide on to how to use it.

Then get back to work.

Stop blaming the crisis. Now is the time to lead.

How to Improve Your Development Process Using Factory Physics

Martin Jul — Mon, 21 Jul 2008 15:35:00 GMT

There are only three types of buffers: extra capacity, extra inventory and extra time. This is one of the great take-aways from Factory Physics that I have frequently quoted since Thomas Blomseth introduced me to it on our lean study-tour to Japan earlier this year.

It is an essential piece in approaching process optimization.

Most processes have (and this is not a bad thing) critical steps that govern the throughput of the whole process.

For example, consider a development organisation that wants to improve its output. Assuming that the development process consists of the definition of work (the work of the Product Owner), the implementation of this (the work of the development team), the acceptance of the work (the PO again) and the user testing (the test team).

In our case, let's assume that we have an overburdened product owner who does not have enough time to specify the work properly and is hard pressed to check the work done by the development team, finding many misunderstandings after the work has been done, leading to much rework. We also assume that the PO is actually involved in doing a lot of testing - something that is often the case, but many times also a sign of poor acceptance criteria in the requirements.

In our case, the work is governed by the PO - in the work definition role and in the acceptance role. Until this bottleneck is removed, we can quickly conclude that there is no point in hiring extra developers since they would just be sitting idle. The PO capacity is the bottleneck.

Let's try the exploring the issue from the perspective of the three buffers.

First, we consider adding extra capacity for the PO role.

There are several approaches to think of - the first being "eliminate waste". We look at the PO's work and see if he is spending time on non-critical or non-value-adding work. This can either be eliminated or delegated - in fact, it is often a good idea to delegate to someone who are not so good at it if they have spare capacity. This includes training others to help extend the capacity of the PO-role.

The next thing is to look for extra inventory. To use this approach we would build up inventory of PO work in front of the development team, for example by giving the PO a head start on the project to build up a huge backlog so the team cannot catch up. Call this an analysis phase and we get to waterfall development. The downside here is that by doing this we practically eliminate the learning about the project that occurs in the feedback loop between work definition and implementation so it is probably not a good idea either.

This also applies to having the PO focus on the definition only and building up inventory before the "to be acceptance tested by the PO" stage, effectively building a huge inventory of work-in-progress of an unknown quality - something that is generally regarded as a very risky endeavour.

An alternative approach could be to eliminate the queue in front of PO acceptance could be to keep the work flowing and the cycle-time in check could explored by testing the hypothesis that we could off-load the queue by timeboxing on the PO testing and automatically promoting features to system testing after, say, one week in the "Waiting for PO acceptance" state, or by having the PO do prioritised testing of the key features inside this timebox or even uniting the PO and user testing into a single team. The hypothesis we should test here is that if there is extra capacity in the user testing stage it can be used to substitute for PO capacity even if it mean more rework or more work for the testers, using some of their spare capacity. By applying an end-to-end process this could turn out to be an improvement of the total system.

The last approach is to look for the extra time angle. The approach here is to lower the capacity of subsequent steps to near that of the PO throughput (usually with enough extra capacity to absorb the variation in the PO step so the system is kept stable). In our case this could be moving people from the development team do useful work on other projects or let them use their spare capacity to improve their development process - cleaning up legacy code, improving the build process, learning new skills etc. By trading for the buffer of extra time we slow down the delivery of the project to the gating factor (PO capacity), but waste less developer time in the meanwhile. In some cases this is a very good approach as a smaller team has less overhead for communication etc.

Turning back to the upstream steps we must also examine the PO role with respect to constraining the definition of work. We can address this in many ways, but the best way is to ask the team and the people involved to see what is really going on in the "Gemba" where the value-creating work is being done.

In some cases it could be that the PO is so stressed by the amount of work that badly defined work is being accepted by the team which in turn increases the burden on the PO to check and suggest changes to the work produced in the "PO acceptance" stage - something that impairs the POs total capacity by a vicious cycle on the constrained resource.

In this case we can explore approaches such as involving the team or the downstream testers more in the work definition stages to improve the requirements and make PO acceptance a lesser burden by delivering the right product.

By starting with Factory Physics, systematically exploring the problem from the angles of extra capacity, extra inventory and extra time gives us a simple, yet powerful tool to ask good questions and analyze the process. As such it is a great starting point for the team to generate ideas to try out to improve the process - and that's the way to creating better software faster.

What's Your Favourite Lean Books?

Martin Jul — Mon, 11 Feb 2008 12:39:00 GMT

People often ask me about recommendations for the must-read books for lean and agile software development.

Here is a list of some of my favourite lean books:

W. Edwards Deming - the grand old man of the field, building on a strict statistical discipline. His book Out of the Crisis is a wonderful treatise on his thinking including his famous "14 Points for Management". This is definitely a must read that will change the way you think about management and quality!
Taiichi Ohno - one of the greatest industrial innovators of the 20th century, the father of the Toyota Production System. After spending his career relentlessly optimizing manufacturing at Toyota he wrote the book Toyota Production System: Beyond Large-scale Production that describes his work.
Womack & Jones - Their books are great and it is well worth to read them all to see a lot of the principles and case studies for lean thinking. Also, it is quite interesting to see that software development is now rediscovering some of the things that manufacturing learned much earlier - in the case of Toyota as early as in the 1950s and 1960s. Begin your studies with The Machine That Changed the World, a five-year study of the global auto industry from MIT and go on with the Lean Thinking and Lean Solutions. They give a fascinating perspective on manufacturing and plenty of examples of the lean principles and they applications. These are the books that brought lean to the mainstream.
Mary and Tom Poppendieck - with a background in manufacturing and software they have translated the concepts of lean to software development. They have written two great books and Implementing Lean Software Development and Lean Software Development - an Agile Toolkit. Both books are well worth reading a present a both the principles and lot of cases in a friendly, colloquial manner. Highly recommended!
Matthew May - I really like his approach to elegance and simplicity. May has worked with Toyota and their corporate university and his book The Elegant Solution offers insight into their innovation process - the principles it is built on and the practices that make it work.
Jeffrey Liker - his The Toyota Way is a very good introduction to the application of lean methods at Toyota. This is one of the best lean books I have read. Definitely a favourite!

What is missing? What are your favourites? Don't hesitate - post a comment now :-)

Variation And Waste - The Case for Frequent Delivery

Martin Jul — Wed, 24 Oct 2007 07:23:00 GMT

Imagine you are in an organisation with a one-year release cycle and you miss your annual deadline by one minute. The cost? A one-year delay.

Now, try to invent a control system to ensure that we avoid this kind of delay.

You would probably add some middle management to manage the dependencies between the various parts that need to be integrated for the release. You would need more management capacity for expediting work when interdependencies juggle the plans and you would need to spend time on replanning.

You would do detailed analysis to identify risks and try to mitigate the risk, no matter how little the probability that the event would occur. You need more people to sit and worry about possible future events.

Then, you would probably also make sure that leading up to the deadline nobody was on vacation, and you might order a code-freeze for the last months to avoid adding risk late in the project.

You see where we are headed. Step by step, we are building the standard, enterprise IT-organisation.

Since the cost of missing the deadline is so high, we have created a big bureaucracy and complicated our everyday work to deliver on time. Productivity is sacrificed to reduce the variation.

The elegant solution is different. What if we tried to make missing the deadline a no-stress event, where a little variation in the development process would not cause a full-year delay? What if we designed our system to be robust with limited variation so that small things have small impact?

This is the lean approach. We try to drive down the variation and create a simple management system rather than accepting it and building a complex system on top to tame it.

Imagine we reduced the release-cycle to one week, shipping roughly two percent of our annual work at a time. The variation is smaller. Miss a deadline by a minute and you release the following week. The cost of slipping is much smaller. There are no more critical weeks or month-long code freezes. You need less bureacracy. There is less replanning. People can go on vacation when they want.

Releasing becomes a no-stress event, something we do every week. It becomes just another day at the office.

On top we get some business benefits. Since we ship every week we can deliver incremental value faster. The cash-flow position is better since we get an earlier return. We become more responsive. If the market suddenly fancies red buttons rather than grey buttons we can ship that next week. Our annual-release competitors will have to wait until their next release - or even more if we make the change during their code-freeze.

The net result is an organisation that is sound from a business perspective, flexible, simple to control, less stressful and more fun to work for.

That's why we call reducing variation an elegant solution.

Jaoo 2007

Kim Horn — Mon, 24 Sep 2007 05:17:00 GMT

We're off to Jaoo 2007 next week.
We are bringing some poker planning cards and some "I O Scrum" t-shirts, please give us a hint if you are interested.

Every day we will post a summery from the sessions of the day.

Bye, bye, "Done, but" - The Flat Organisation and Enterprise Scrum

Martin Jul — Mon, 17 Sep 2007 18:24:01 GMT

Lean organisations tend to be very flat with few layers of management. They rely on self-organisation and leadership. In this context, then, what is the role of the middle layers in the organisation? This is one of the points Ken Schwaber addresses in "The Enterprise and Scrum". The answer is amazingly simple.

The middle layers are Scrum teams that prioritize the work for the subteams and integrate the results.

In other words they prepare the product backlog for the subordinate teams and provide leadership, coordination, infrastructure and support for the teams below. This means that the integration teams are complete, cross-functional Scrum teams with full delivery capability. Compared to many traditional organisations this means that release engineering activities, QA, etc. move up in the organisational hierarchy, making the downstream steps in the value stream the integrators and bosses of the earlier steps. We are, in effect, a creating kanban system for the whole development process. Through this we create flow and remedy the common failure of deferring integration work to the end only to learn too late that the parts do not fit well together.

This organisation of Scrum teams builds on lean principles such as frequent integration and "jidoka" - stop-the-line bug fixing. Every team is responsible for integrating its own work and that of its subordinates. If a subteam delivers something that is not good enough, the work is pushed back down and not accepted. This way, we make sure the details are always correct and shippable. As a result, the whole product remains integrated and shippable.

The ScrumMaster on the integration team is facilitates the removal of impediments that cannot be removed by the front-line teams themselves. This creates a system for multi-layered kaizen where the change is always initiated by the people who experience the problems and escalated to the proper level of authority. Through this the integration teams switch from command-and-control to serving the teams below.

One of the benefits from this structure is that the Product Owner on the integration team defines the product backlog for the subteams based on the coarser-grained backlog and priorities from the next level up. In this way the integration team and its subteams is treated as a virtual, cross-functional team. Since we are not allowed to produce loose ends, it forces us to actually start only activities that can be completed in a sprint with the necessary coordination between subteams. We have to begin with the end in mind.

For example, if a backlog item for adding a new report for to a reporting application is selected, we have to make sure to request the whole feature - both the new GUI (a pretty diagram, maybe), and the necessary updates to the back-end server application to provide the data. If there are separate teams working on this the feature is split across different team backlogs. In many cases this requires coordination between multiple teams when planning. The key point is to never commit anything to the integration sprint backlog unless all aspects of it are committed to the sprint backlogs of the subordinate teams.

If this is not possible we have to break it down into smaller pieces or leave it in the product backlog. We never accept work that cannot be completed and demonstrated at the end of the iteration.

When we implement Scrum in organisations this is something that it usually perceived as quite frustrating in the beginning. Many people have a strong habit of doing for partial work. However by only committing completable work we reduce one the great time-consuming activities in project management, namely managing dependencies between projects, trying to get features done in isolated, non-integrated layers and the coordination and "expediting" work to lobby different teams to change their plans to get it all correct and integrated on time.

The end result is a system where business goals and priorities flow from the top down and demonstrable business results flow from the bottom up. Every iterations ends with completely integrated realisations of the top level backlog items. It means goodbye to, "we're done with the new report, but we have to wait three months for the database team to expose the data for us", and hello to, "here's your new report, ready for use". That's a pretty good return on eliminating bureaucracy.

“Implementing Lean Software Development: Practitioners Course”, by Mary and Tom Poppendieck

Kim Horn — Thu, 10 May 2007 18:10:00 GMT

Having attended the two day “Implementing Lean Software Development: Practitioners Course”, I encourage you to join Mary and Toms classes or speeches if you get the chance, they are very inspiring and their knowledge about lean and agile are amazing.

Mary and Tom have done a great job in transforming Lean principles from the manufacturing environment to software development. The course take you trough the Lean history, give you a brush up on the theory behind Lean and give you a lot of god techniques, tools and ideas on how to improve your existing projects and use the power of Lean.

A few “lessons learned”:

Success factor for implementing Lean: look at the whole supply chain, not only development or test. Think products (end to end) and not only projects.
Use pull rather than push. Be aware of utilization: an operations manager will react when a servers cpu utilization is getting close to 100% - but what about people utilization …
When implementing Lean it isn’t enough just to use Just-in-time and stop-the-line. It is the people doing the actual work that have the potential to make it a success. They have the good answers and ideas.
All queues and stacks of work is WASTE. Remove the cues, improve the cycle time and get better overall performance and quality. Value stream maps are a powerful tool to identify queues and their size.
Without automatic tests you are asking for trouble. Don’t buy the “we don’t have time to implement automatic tests” excuse, if you wait your problems will grow…
And NO it is not ok to have a backlog that contains work for more than 3 iterations, including ideas for the future – get rid of the WASTE and focus on the important stuff that adds value to the customer.

Impressions From Our Lean/Agile Dinner with Mary and Tom Poppendieck

Martin Jul — Thu, 26 Apr 2007 20:24:00 GMT

This Tuesday we hosted a dinner for the Danish Agile User Group with Mary and Tom Poppendieck in the great Restaurant Grønnegade. The charming old house from 1689 with its modern European slow-food set the stage for an evening of great conversation about the state and future of lean and agile software development.

Around 20 Danish agilists attended and following a question/answer session with Mary and Tom we had an excellent five-course dinner. The room was buzzing with lively conversation - people trading war stories and experiences with implementing agile and lean software development in their organisations. It was a great night with plenty of inspiration for the daily work.

This post is a collaborative montage of impressions from the participants - from the Q/A with Mary and Tom and the conversation in the group. Please add your impressions below.

Just to get the ball rolling one of the things I discussed with Henrik Thomsen, Lone Møller Klitgaard and Mary Poppendieck was Scrum and its shortcomings.

Henrik got the ball rolling by noting that Scrum is too limited for his taste since it only addresses a small part of the total picture, excluding, for example, many people issues. Henrik talked about how he has used the Soft System methodology to visualise the stakeholders and predicting conflicts in the development process - clearly something that is not addresses by Scrum.

The Ative experience with introducing Scrum is that it is a very simple yet powerful set of rules. This makes it a great starting point for agile practices. However, we are not dogmatic about Scrum: we keep looking at the overall picture and fixing the impediments through a classic lean inspect-and-adapt cycle. For example, we usually spend quite a lot on time with the technical team to ensure a minimum level of professional craftmanship (configuration management, automated build and deployment, automated unit and acceptance testing etc. - we have blogged about this earlier). We have also experienced the need for a lot of training for the Product Owner - in fact, this is usually much harder than getting the development team to adopt the Scrum practises.

The big thing was that the discussion framed the things we work with every day: from the perspective of lean - which is essentialy a framework for thinking about processes - agile is a lean implementation. This also means that it is context specific and constantly evolving. Therefore it makes no sense to talk about The Only Way to agility but rather to treat all the agile practises as a toolbox and mix-and-match the things we need in a particular context.

Just as the doctor does not order you to take all the pills in the pharmacy or prescribe only aspirin for any ailment, agilist should use skillfull means, too. We need to know and have experience with a broad range of agile practises, but we only advice the specific medication that the patient needs and in just the right amount. And to tie it back to the discussion about Scrum, Scrum is not the cure for every problem.

Please add your impressions from the evening in the comments below

what was your highlights? (things you talked about, people you met, ...)
what did you learn?
what inspired you the most?
how are you going to use it in your work?
about the evening - "keep this"/"try this"/"don't do that again" feedback for arranging something like this in the future.

Thank you for making it a great night and for posting your impressions!

Iterative Development Gone Wrong - The Mini-Waterfall Anti-Pattern

Martin Jul — Sun, 18 Mar 2007 16:46:00 GMT

One of the frequent mistakes in transitioning to agile development is to implement iterative development by doing consecutive "mini-waterfalls".

No matter how iterative it might be, if you are relying on the "W"-word, you are still doing something wrong.

When we postpone testing and completion to the end of the iteration we are shooting ourselves in the foot. Once testing begins we start to uncover all the mistakes and defects and with the clock running out there is no room left to maneouver - no time to descope or rescope or maybe even to complete some of it. Most often the result is to end the iteration with a number of unresolved defects and incomplete features.

From a Lean perspective the problem is that everything becomes work-in-progress - we produce lose ends everywhere at the same time rather than completing features one by one to proper production-ready quality.

We have seen this symptom on several projects now and the cause seems to be that testing is not integrated properly in the process. We really need to be test-driven, also on the acceptance/integration testing level to truly transition to agile development.

This means that testing and QA should be moved to the front and be an on-going activity over the course of the iteration - not a frantically compressed activity at the end. In fact it is a first-class development activity that drives the whole project.

Even when we are aware of this it is easy to get caught on the wrong foot.

We often see experienced testers build their test cases around complex use case scenarios. This results in "big bang" testing where steps cannot be tested individually - the test hinges on a big set of deliverables rather than incrementally evolving with the application.

The remedy is to plan the backlog in terms of small, testable slices. Even if you are working from Use Cases, break them into smaller "user stories" that describe a simple feature (usually one or two steps in the use case). Test the user stories individually and incrementally.

The next step is to automate the acceptance tests so we get regression testing "for free". This allows us to sustain the quality at a known, high level.

With this we are on our way to developing better software faster, and even when we get bogged down we have earned the right to not make any excuses. Instead of saying "well, we are sort of 80% done with 100% of the application and no, you we cannot deploy anything to production" we have earned the right to say, "Well, we suffered some setbacks, but we are 100% done with the 80% most valuable features. Let's put it into production and start reaping the benefits."

The Five Whys of Lean

Martin Jul — Tue, 20 Feb 2007 00:06:00 GMT

Root cause problem resolution is one of the core practises in agile. If the engine requires new oil every 500 km we don't just top it up with oil. We fix the engine. Adding oil is just a hack that leaves technical debt in the system and slows down our journey. It reduces our sustainable pace.

Good operations people get this. Many developers, however, do not. We would happily work overtime walking with a stone in our shoe rather than stopping for a moment to remove it.

To increase the awareness of removing the cause rather than treating the symptoms of the problem, Taiichi Ohno of Toyota implemented the simple practise of asking "Why?" five times when something went wrong. As we keep on asking, we get closer to true cause of the problem, not just its symptoms.

It is a simple technique and it works very well.

In my career I have seen many systems that take weeks or months to integrate and deploy after the developers declare them "done". When integration is very expensive people tend to put it off and build up huge batches of work-in-progress - software that the developers have declared to be done but which cannot be deployed to production yet.

From a Lean perspective that is a waste.

Taiichi Ohno's "5 whys" technique proves quite useful in a situation like this.

"Why not release to production at the end of each sprint instead of just once per year?" "Well, yeah, that's a good idea, but we can't do that."

"Why?". "It is very expensive".

"Why?". "We have to test it all and get all the bugs out."

"Why does that take so long?". "It's a manual test, and we have to deploy to a very complex environment and there are a lot of bugs."

"Why don't you do automated testing, then?". "Oh, we tried that - it does not work."

"Why?". "You see, we create tests but when we run them two months later they are all red....".

"Why?". "Time passes and so the monthly batch jobs run and update the data. This breaks the tests... so we can't do automated testing.".

"Why not let the tests create a set a known test data when they start and then test against that?". "No that wouldn't work. You see the test data is a snapshot of the production data."

"Why?" "So that we have examples of all the kind of data we need to test on. Creating the test data is very complex and takes too long."

"Why?" "Well, there is so much data to enter."

"Then why not automate it then?". "We cannot do that - you see, the legacy system does not really have the hooks for that."

"Why? - who wrote it?" "Don't be stubborn. We wrote it... but , you see management doesn't want us to change the legacy system since it costs so much to test."

"But that's the problem we are trying to solve!"

Getting to the root of the problem and fixing that is the core of lean and agile practises. Next time you encounter a problem, try asking the five whys, and ask yourself - "are we treating the symptom, or removing the cause?" This is the way to go faster and improve quality.

Why Going Faster Matters

Martin Jul — Sun, 04 Feb 2007 17:34:00 GMT

I did a talk on Value Stream Mapping from Lean last Thursday at the Danish Agile User Group meeting (slides in Danish are available at http://tech.groups.yahoo.com/group/DanishAgileUserGroup/files/ (registration required)).

One of the many interesting questions that came up was why faster is better - could it be that slower would be more efficient?

The context was that be that faster could be more expensive - ie. adding more people to fix the problem. In that case there is a chance that slower is in a sense better. Dogmatic software development even has it that resources, timeline, quality and feature set are interrelated. If you want to go faster or to increase the quality, it costs more.

The underlying assumption is that the process is perfect and therefore that all the work is essential and valuable.

That, however, is a myth.

From the perspective of the Seven Wastes that I blogged about recently I would like to rephrase the question to "is less waste always better?"

I think the reason that many people connect lean with faster is that the most obvious waste in value stream maps is the waste of waiting. So on first impression lean is all about eliminating that and keeping extra resources available to solve tasks immediately when they arise with with no delay.

That would be wonderful however but if we have a great variation in the workload we will take on a huge overhead to have peak capacity available at all times. Since this would be a waste when demand is slow lean has a practise of balancing work and capacity to keep the variation low.

In case there is extra capacity available we use it for kaizen - process improvement. In software, for example, we could spend it on refactoring a legacy system to a cleaner state so we can work faster in the future. This would enable us to take on extra demand with the same number of resources.

Now there are other wastes than waiting and it is by looking at them that we see that lean is actually not a cause of stress as many seem to belive. The aim is not working faster doing the same thing. The goal is to only do the work that is actually valuable.

This means getting to the goal faster by doing less. It does not mean burnout or overtime.

From this perspective I believe that lean is a more humane approach than the obvious alternative of status quo where speeding up is derived from the project manager pressuring and threatening employees to work overtime, cut quality etc. In that traditional context faster means evil, but in the agile world, where respect for people is the centerpiece faster also means better. It denotes less meaningless work. It means freeing up all the untapped human talent of the team and putting it to bear on doing exciting work - to spend our working hours creating something that will please the customer faster and at a better quality than ever before.

That is the essence of agile - and it's the source of great job satisfaction.