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):
Define your 'True North': what for? How?
- Define your 'True North', the long-term direction you will commit to pursue for years,
- Visualize everyday your actual Performance and its evolution over time,
- Identify clearly what problem(s) you need to work on now,
- Progress by applying the Scientific Method for Problem Solving.
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:
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 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
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:
Although we found many reasons to object to this bicephalous mode of organisation, we had no choice but to adapt.
- 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)
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!