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

Recently peterstev reported on, 10 Contracts for your next Agile Software Project.

In BestBrains we now have experience from two commercial projects using a new kind of agile contract.

We want to create contracts where risk is shared fairly between customer and supplier and where likewise benefit is shared fairly. Based on our experiences we have arrived at a contract model that has proven to achieve this result. We call this the collaborative agile contract.

The main mechanism of the contract is to delay some of the payment until a certain criteria has been reached. We do not use a date as this criteria which otherwise seems to be common. Rather we want a criteria that tells when we have a situation where the customer is getting value from the software. There is generally a mutual interest of arriving at this situation as quickly as possible. Effectiveness and creativity from the supplier will be rewarded. And the customer will be careful when deciding what features are needed in order to reach that goal.

The contract defines the following elements:

• Scope described loosely in a few paragraphs, a kind of vision statement
• An hourly price, that is 10-50% below what is normal for pure time-and-material
• A set of milestones, which will lead to payment of a fixed amount. The simple criteria that tells that a given milestone has been reached, is whether the software is deployed in production.
• A development process following agile practices
• A suggested time frame for the overall project and for each milestone

We are going to report on our experiences at Agile 2009, but don't hestitate to comment on this blog entry or contact Lars Thorup to learn more about agile contracting.
agile kontrakter

By Lars Thorup

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

Back when I was studying at the Technical University of Denmark, I took a course named something like "Probability and Statistics for Engineers". Just the other day I came across the book which was used in the course - in my own bookshelf. I never paid much attention to the chapter of statistical quality control when I was reading it back in university. In fact, I'm not even sure I made it to that chapter.

For some reason I can't explain, I felt an urge to take a look in that particular book the other day, and in there I stumbled across quality guru Dr. Deming's 14 points for management. I wonder why this part of the book was totally overlooked in the course - considering how important I have later found them to be.

I've never had such experience with a book I've had for years on my bookshelf Have you?

By Sune Gynthersen

Maybe you have made some great improvements in your software development organization in 2008 and now it might be easier to reach the expected milestones and get value out to customers/users in a faster way. You might even have introduced some Agile or Lean practices (maybe Scrum) and started to work in a more iterative rhythm with increased collaboration and feedback.

Don’t relax and think it is good enough, because it can be so much better!

When your teams and individuals on a regular basis starts to search for new and improved ways of doing their daily work, you are moving in a direction, where more of the sleeping and hidden potential of the organization gets activated. When people get used to the rhythm of continuous improvements with regular retrospectives, instant kaizen events etc., they will start learning to see some of the candidates for removing wastes and be more efficient. 

Continuous improvements with a structured and constant improved process to find the most important candidates to improve, is key to more business success in your organization and it is essential for you to do it better than your competitors.

It is not only about improving development practices in your development team, because you might just sub-optimize areas with lower impact and poor ROI. Off course you can get a lot of value by having an efficient development infrastructure and teams working with automated testing, emergent design etc., but the bottlenecks might be in the value streams involving people outside development. Working on the right prioritizes with enough knowledge of the business problem, so you can make a simple and optimal solution, often requires an efficient collaboration between business the development team and here might be candidates for larger improvements.

Unfortunately I know of many teams and organizations not doing any kind of regular improvement activities in teams, projects or on a department level. That’s a shame, because they could do it much better and be much more competitive with an improved bottom-line in the company.

So start doing continuous improvements as an individual, in your team or organization, and you will over time learn to see what is really blocking you not to do it better. Just keep in mind that it can take some time and there are a lot of different techniques to get into the root cause of the problems, so you can focus on the constant and sustainable small steps with the largest impact.

By Mads Troels Hansen

Today I had a talk with a family member who has considerable knowledge within procurement and service contracts in the public sector. We talked back and forth, for instance about cleaning services. I must do my utmost to remain a man of patience when I hear real-world stories like this:

"Let's force the company responsible for cleaning elderly homes, to reduce their prices with 30%." ... the rationale? "It should give them incentives to do the necessary improvements". Right? Wrong!

Go down that path, and you have apparently never heard the stories of how the American automotive industry tried to reduce costs on spare parts by putting pressure on the suppliers to the extend where they almost went bankrupt. This kind of behavior will be perceived by the supplier as a threat to their existence. And thus, they will react by survival instinct, which means extreme precaution, zero tolerance and distrust. It is impossible to have a prosperous partnership when one party is trying to take advantage of the other. And it is very hard to come up with creative
solutions for lowering prices in an environment of distrust.

A different (and better) approach for improvements could be to ask the supplier to work on increasing quality without increasing costs. That is not a threat to the existence of the supplier, thus they can respond with creativity instead of hostility and distrust. Hmm.. how can we increase quality without increasing prices? .. Maybe you are already bending your mind trying to figure that out.

In the software industry someone once faced a challenge like this, and then came up with the concept of Automated Testing -- Result? Increased quality, lower overall cost. Today we take it for granted. Naturally, this kind of innovative thinking can be applied to any domain.

By Sune Gynthersen

Believe it or not -- I saw this question posted dead serious at LinkedIn the other day. It made me think, we need to spend more efforts on training everyone to see the negative impact of individual performance measurements.

Have you ever been in an organization where testers were praised for no. of defects found? Though it is harder to measure, wouldn't you agree that it would be more useful to praise people for "no. of bugs that were never introduced due to close collaboration and mentoring of developers"? I need to emphasize that the latter is of far greater importance than the number of bugs discovered.

And here's the important part -- Doing individual performance ratings will seriously constrain peoples innovative abilities, and thus their abilities to do real value stream improvements. In addition, individual performance ratings will encourage people to NOT help each other, even when it is clear it will be of greater benefit for the company.

Promise me you won't do it

By Sune Gynthersen

I'm reading Dr. W. Edwards Deming's main work Out of the Crisis for the first time and thought I would share some of Dr. Demings wise words with you. I didn't really expect it but Dr. Deming actually has something to say about software development.

Earlier this year I had the pleasure of reading his other main work The New Economics and was amazed by the insights of Dr. Deming and how little people in general and management in particular have understood what he actually said. Granted, his overall style could easily be termed idiosyncratic and collage-like but stunningly concise formulations are spread all over.

This is what Dr. Deming said about the "supposition that it is only necessary to meet specifications" when it comes to software development:

"A programmer has a similar problem. She learns, after she finishes the job, that she programmed very well the specifications as delivered to her, but that they were deficient. If she had only known the purpose of the program, she could have done it right for the purpose, even though the specifications were deficient."

That's it! Did I mention that Dr. Deming wrote this in 1984, long before anyone talked about Agile software development?

By Thomas Blomseth

Here at BestBrains we like innovative companies, and especially we like those that use innovation to solve on of the big problems of this era - Global Warming.

Tesla Motors are one of those companies. They are producing the Tesla Roadster, a cool, all electric sportscar.

Unfortunately Tesla apparently can not demonstrate mature leadership that matches the coolness and innovation of their products. 

According to this blog post and this they apparently decided to close their Detroit office. That means that 90% of the staff there will be without a job.  Information about this was given in a blog-post and those that did not get the message went to work, just to find out that they were fired when logging on to their computers.

One can only hope that management will be able to restore trust and morale in the remaining staff - or we will may seen just another good company destroyed by poor management.

By Bent Jensen

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