A Lean journey in Software Development: first, be clear about the direction

This article is the second of a short series on the definition of Lean and its application to the Software Development field.

The next 3 or 4 posts will follow the same structure: I first explain my current understanding of the concept, and then present what we did in the last project I was involved in.

Short disclaimer: I may be making a huge mistake trying to catch the Lean Approach with bullet-points, but I can't resist the temptation of such a convenient way for me to articulate what I learned in distinct articles.

As far as I understand Lean Thinking today, if you (individual, team, organization) want to consistently outperform the competition in the long term for any complex field, you should address 4 key aspects as rigorously as you can (if possible with the support of a coach):

1. Define your 'True North', the long-term direction you will commit to pursue for years,
2. Visualize everyday your actual Performance and its evolution over time,
3. Identify clearly what problem(s) you need to work on now,
4. Progress by applying the Scientific Method for Problem Solving.

Define your 'True North': what for? How?

I attended last week to the 1st European Lean IT Summit in Paris. Gee! My little brain really enjoyed those 2 days!

Dan Jones (co-author of 'The Machine that changed the World' with James Womack, and top-notch thought Leader of the Lean community) shared with us his definition of 'Lean':

"Lean is the Practice of using the Scientific Method to solve Business Problems in order to create Value"

Wow! There is absolutely no waste in this sentence. Almost every word deserves a careful attention.

In particular, Dan emphasized that the 'Value' had to be considered along 3 axis:

• for the customers: help them solve problems in their lives,
• for the people experimenting the process: they become experts in their fields and grow everyday their problem solving skills,
• for the organization to grow and prosper.

This may at first look obvious, but have you met any business organization truly value-oriented, considering this entire definition? I have not.

Anyway, we certainly need to find words more tangible than "Value Creation" for making a good Vision statement for a project, a product or a company.

What about following these guidelines?

• The 'True North' must state in very few words the ideal success of your project in the middle or long term, as you see it today,
• It will serve as the direction for ALL your efforts,
• As a direction it does NOT have to be precise, so avoid delving into much details, or spending months to tailor it,
• Your activity ultimately must bring value to someone : start by identifying your client(s), and (if possible) ask him to articulate your conditions of success,
• The statement needs to combine two qualities : it has to be CLEAR to everyone, and SHARED by everyone involved in the value chain.

Aha! Interesting, isn't it? Let's now examine how we attempted to apply these guidelines to a concrete case in the Software Development field.

Real World Experiment : defining a True North for a Software product

For you to understand certain of our choices, get a look to this quick overview of our context when I joined the company 2 years ago:

• The product: public video portal (live and on-demand) for mobile devices,
• 1 unique customer: the historical and largest french Telecom Company (our customer is not the end user of the product),
• over 1 million unique visitors each month, growing, with peaks of traffic during sport events,
• heavy-weight project generating revenue, and critical for the short and middle-term cashflow of the company,
• 6-year old project, with loads of features dumped on top of a 3-month prototype,
• ecosystem of 15 applications (front apps, Web interfaces and batches, taking care of provisioning, content management, customer support, statistics...),
• 450 thousands lines of code, mostly in Java,
• many layers of technical debt (unused features, complicated code, different technologies for the same needs),
• 70 production servers,
• about 15 people directly involved: 4 system engineers, 1 functional expert, 8 developers, a network expert and the project manager,
• several critical incidents in the past months, resulting in Low Quality of Service (slow response time) and potential loss of statistics

This of course depicts a very incomplete presentation of the situation. I could add more to it, but prefer to stop here to focus on the core of our current subject.

The development team created a first version of our True North, and asked a feedback from 2 client representatives, that led to a few minor changes.

We identified our client to be the 2 distinct departments we were dealing with on a regular basis:

• one was affiliated to the Marketing department, and expressed the needs for the next-generation capabilities of the product,
• the other focused exclusively at the quality of the overall system running in production (our part formed a portion of a more global solution)

Although we found many reasons to object to this bicephalous mode of organisation, we had no choice but to adapt.

We then attempted to state what problem we had to solve, from the client perspective: "Do what I want, when and where I want it, be reliable and do not make me waste my time".

We published the result on the wall, for everyone to see and remember:

The team forged a few key performance metrics out of it, and accepted it for a while.

After about 8 months, we noticed however the low level of energy this vision statement created in the organisation. We formulated the hypothesis this was due to the poor clarity of the message (post-its scattered all over the place), and the fact that it was not formulated by the client himself.

We want our client to be totally satisfied. We thus directly questioned the client:

"What are our conditions of success? What will make you say, one year from now, 'I am happy at what you have accomplished'?"

We then tried to capture the core vision in very few key points to make them stick in our memories (we published underneath goals more specific to each client division).

We found this last version more satisfying (even though less pretty):

We could proudly say to anyone getting into our room:

"Here is our direction, the Graal we are after"

I remember situations where this post-it directly helped deciding between several choices for action:

"This idea may cost a little more than this other one... but is it the right question, really? Look at our direction (pointing at the wall): which option do you think will provide the best user experience?"

More pratically, we used this clear vision statement to determine how to measure our performance in a less ambiguous manner... but this story is for the next post!

A Lean mindset for software development: why does it matter?

This article is the first in a short series on the definition of Lean and its application to the Software Development field.

I often hear people say: "Software Development is a craft"... well sure, I agree with that.

Each good developer requires many years of experience to develop his/her craftsmanship in forging and maintaining high-quality, long-lasting code. She/he needs to learn from training, books, seminars, conferences, but mostly by doing day after day, advised by more experienced mentors... (and of course making mistakes)

Yet, projects in Software Development share common characteristics with other types of projects:

1- structurally, they are defined by the presence of stakeholders, a team, limited financial means and goals to be attained in a finite amount of time,

2- dynamically, they all follow (consciously or not) some kind of working process, and encounter unforeseen obstacles along their way.

The Software field is still very young compared to other businesses.

This is I think why any serious software organisation looking for more-than-average results must look at what top performers in other fields do to stay well ahead of all their competitors.

Some recent studies demonstrate that there concretely exists a common mindset and type of behaviour in the face of difficulties encountered by all those organisations: read "The High Velocity Edge" (Steve Spear) for thorough examples applying to several, very different domains.

Let's review a few common false assumptions before moving on.

Lean IS NOT :

• one more trick or control tool invented by managers to exploit workers,
• about cost reduction and layoffs (as some want to make believe),
• the rigid application of standards defined by some Quality Department,
• Kanban (but, Kanban may sometimes be used as a tool, following Lean Thinking under a certain set of circumstances)

Where does the term "Lean" come from?

The expression "Lean Manufacturing" was first used in 1990 by James Womack, in a book called "The machine that changed the world", that describes the history of the automobile industry and in particular the very successful Toyota TPS (Toyota Production System). According to Wikipedia, Lean Production is "a practice that considers the expenditure of resources for any goal other than the creation of value for the end customer to be wasteful, and thus a target for elimination".

How do I define Lean today?

I've been thinking about this for the 2 past years, reading and experimenting in the context of a heavy project, with a mix of both very interesting and poor results.

In the meantime, I applied last year (2010) to a 6 day training course called "Lean IT Project Management", broken down into 3 chunks of 2 days for 3 consecutive months. The trainer was my former XP mentor, Régis Médina. This course offered me great insight on the core of "Lean Thinking", and ways to apply it to the IT world.

I'm definitely not a Lean expert, but actively want to undestand its nature. I personally prefer to talk about "Lean Thinking", or the "Lean Mindset".

First, let's be clear about one thing: true Lean Thinking is about developing the true asset of the organisation: its people. If you can't feel this quality in a company, then it is definitely NOT a Lean organisation (in spite of anything they claim or say).

From that assumption, I would define "Lean Thinking" as a rigorous, generic, adaptable and repeatable thinking process for targeting operational excellence and maximizing the value (thus, the satisfaction) of the end customer in any complex organisation.

What does it mean for a software development project?

From the former section, I hope you understand why the "Lean mindset" does matter.

In the next article, I'll be more specific about what it meant for my past experience in a large development and maintenance project for the Telecom industry, starting by what should be the very first step : defining the "True North" of the project team.

--------------

References :

I recommend you the reading of those books on the subject, as they have profoundly affected the way I think and work, all for the better :

• The Gold Mine, by Mickael Ballé
• The Lean Manager, by Mickael Ballé
• Toyota Kata, by Mike Rothers
• The High Velocity Edge, by Steve Spears

You can also find many interesting information online. I'll just mention 2 resources I find just great:

• the Lean Edge
• the Gemba Coach