In 2007, when Operae sponsored the 1st “Agile France” conference, developers of that distant era were wondering whether agile was, at bottom, nothing more than lean management applied to the software world.
Let’s not create suspense: the answer is definitely no and many companies can testify to this.
This article aims to explain how the two approaches agile and lean are similar but above all how the second approach secures the success of the first one.
Agility – a radical transformation
The consensus is not total regarding the definition of “agile software development”, companies have various practices, the posts published on Linkedin show different approaches. I appeal to the reader’s indulgence if his definition is different from mine.
For my part, I retain that of Yves Caseau, CIO of the Michelin group at the Lean Digital Summit:
“Agile, in a nutshell:
Small iterative batches (time-boxed sprints)
A focus on delivering value and measuring customer satisfaction
Autonomous, self-organized, cross-functional teams that will develop together the design, code and architecture of the software.
Synchronized teamwork with a preference for face-to-face communication.”
The installation of these 4 practices represents a considerable effort for the CIOs of companies, the R&D of software vendors and the service managers of IT services companies. The entire software industry must review its working methods, tools, interactions, the structure of its premises, contractualisation methods, roles, relationships between individuals, etc… Supporting employees towards an agile organisation represents a massive investment so that they can find their feet in a different working environment: communication, training, coaching, the approach implemented is always important.
Once this transition period has come to an end, it is clear that the end of the V cycle does not always keep its promises which is perfectly normal:
1. Difficulties encountered before the deployment of agility persist after
Example: A web company offers to connect people from the general public with experts to answer technical queries. The site is evaluated as offering a real value to its customers (the answers are very adapted) but unbearable in terms of response time. A gemba  with the developers in the code shows that the “client-expert” linking algorithm collapses the performance of the site. While digging into the subject, the lean coach discovers that the developers have no culture of the “design pattern” (use of libraries of good practices) that would have allowed them to avoid this error in code, and many others.
This is an example of a subject on which the team would do well to improve, whether they work in V cycle or in agile mode.
2. Agile software development requires the acquisition of new skills
Though mastering a new skill requires 10,000 hours of practice (or 1,400 days or 7 years of work).
Example: Among the skills that a Product Owner must acquire and that he discovers when he is entrusted with the role: understand the customer and the expected value, distribute it within increasingly rich Minimum Viable Products, translate it into a set of user stories acceptable to developers.
Lean – The path to success
Lean management offers a rapid and concrete approach to answer the following question: how to get the promises of agility as quickly as possible?
regular and rapid delivery of software that works,
that provides the expected service,
built by autonomous, creative and serenely working collaborators
Indeed, the lean DNA is a pragmatic and efficient thinking system whose field of application is the fast reduction of gaps:
- between known situations and the current situation (“usually the response time is 15 ms and today it is 100 ms),
- between a good repeatable performance and variable practice (“one out of three times we manage to deliver all the user stories in the sprint; the other times it’s longer”),
- between a target situation and the actual situation (“corrections are traditionally delivered in 3 months; how do you accelerate to 2 weeks?”).
As soon as a person or a team will ask themselves the question of reducing a gap, and that they will do it seriously, until they identify a concrete action with a precise result, this person or team will learn a new skill.
A story among others
Here is an example of an agile team taking ownership of lean management:
Olivier’s team develops the software for a new interactive terminal.
These kiosks are positioned at the point of sale and allow customers with simple purchases to avoid queues. The IT team works in 2-week sprints and has already completed 23 sprints with all the points of passage provided for by Scrum: creation of the backlog, daily scrum, demonstration, retrospective, etc…
3 pilot sites have received the new terminals. The cashier staff, who were in favour of installing the kiosks, are threatening to disconnect them. Indeed, customers very rarely manage to complete a transaction on their own. It is therefore necessary for the staff to leave her counter to assist helpless customer, to deal with her possible irritation, return to the checkout and deal with the irritation of waiting customers. Working days become unpleasant.
There are several hundred points of sale to be deployed and the company’s management is afraid that the program will be stopped. They decide to hire Raphaël, a lean and agile coach for the team.
Olivier is doubly anxious. He feels that the delivered terminals are not working as planned but the pilot sites are far away and he doesn’t really understand what the difficulties are. The arrival of Raphaël doesn’t reassure him either; he has the feeling that the team is already in overload: is Raphaël going to make them lose more time?
Raphaël suggests the following schedule:
- 3 weeks of immersion for him, so that his coaching is specific to Olivier’s team,
- 3 days together, with the team, to diagnose the process, find its weaknesses, analyze the causes and propose corrective actions,
- 8 weeks – 4 sprints – to improve the situation.
|Situation Before/ After||Types of topics addressed|
|1.Small iterative batches (time boxed sprints)||Successful sprints||Review the “definition of ready” of user stories to make them more accurate.|
Review the “definition of done” of developments
Male estimates reliable
Adjust the load to the holidays
|2.Focus on delivering value and measuring customer satisfaction||Satisfaction of cashier staff|
Number of incidents per week
|Install the “complaint driven development” : |
– creation of 3 technical sprints to eliminate 135 bugs
– integrate bug fixes into the development workflow
– install a “sanity check” before deployment
– develop automatic tests
– perform more tests on the demo terminals.
|3.Autonomous, self-organized, cross functional teams that will develop the design, code and architecture of the software together.||No significant change, the team was already good on all these items.|
|4.Synchronized teamwork with a preference for face to face||From a simple visual management (To do – WIP – done) that did not generate useful discussions to an improved VM that includes the following :|
– build and run (vs. build only)
– process details (vs. simple WIP)
– representation of the limits and flow of the operations showing the pain points
|Design of a new VM : from a “to do list” to a real support to drive discussions with the business and within the team.|
Creation of success indicators and analysis of their evolution sprint after sprint, to identify and validate best practices.
Honest discussions with the business, in front of the VM to make decisions together.
Agility and lean – key principles
The lean approach led by Olivier’s team, in charge of the interactive terminals, lasted 12 weeks. Raphaël’s approach, the lean and agile coach, is the one recommended by Steven Spear , one of the great thinkers of lean :
1.Build a visual management that dynamically reveals operational problems
2.Solve these problems one by one and immediately until the expected level of performance is achieved using the PDCA method.
In doing so, Raphaël encourages Olivier’s team members to explore the aspects of agility and software creation that they are less familiar with. Mastering the principles of visual management and problem solving gives the development team a great deal of autonomy to move forward, which its members really appreciate.
The 4 aspects of agility cited in summary by Yves Caseau will clearly facilitate the support proposed by Raphaël:
- Small iterative batches (time-boxed sprints):
The PDCA improvement cycle requires that the ideas tested are subject to a validation of their effectiveness (the C for Check of the PDCA). Short sprints make these validations very easy, much more complex in V cycle projects! Improvement is therefore faster.
- A focus on value delivery and measurement of customer satisfaction :
Lean’s 1st ambition is to “completely satisfy the customer”. Agility, by putting value creation at the centre of attention, avoids long negotiations with stakeholders on the legitimacy of choosing improvement topics regarding what can disappoint customers and users.
- Autonomous, self-organized, cross-functional teams that will develop together the design, code and architecture of the software: Lean also advocates teamwork instead of searching for “heroes”, developing trust in the collective earlier than hierarchical validation and improving the value chain instead of improving an isolated silo.
Synchronized teamwork with a preference for face-to-face communication:
Visual management will become the artefact of synchronized work and will favour not face-to-face communication, but side-by-side communication, even more conducive to the installation of a collaborative spirit.
To sum up
The complementary nature of agile and lean approaches can be expressed as follows:
Lean enables agile organizations to deliver faster on the promise of IT that delivers more value to its users.
Agility reveals the difficulties inherent in product creation, previously hidden in processes, infrastructure and distance from the customer, and gives the freedom to move forward.
This appeased synthesis should not hide the thousand difficulties that teams and their coaches will encounter, the most frequent of which are from less than one point of view :
- sterile debates about methods. I have witnessed so many boring and uninteresting spats since 2007!
- a reluctance to commit to improvement because one or the other will fear being questioned whereas, on the contrary, lean is only interested in the weaknesses of processes and organizations so that everyone succeeds in their mission.
- a concern to devote time to the benefit of improvement while the activity is under stress. It is all the more important for the team to define its performance indicators and verify, in the figures, that the improvement is real.
Finally, from my point of view and that of my interlocutors, the benefits to be expected from joint agile and lean approaches justify the efforts devoted to them: pride in having explicit and positive feedback from users, personal satisfaction in acquiring increasingly refined expertise, pleasure in working together.
“Software is eating the world” is a strong idea from Marc Andreessen who recognizes the power of digital companies, starting with the GAFA. One of the necessary conditions would still be to build good software: generating value for its users, fast because we are all impatient, robust to be permanently available, able to evolve as the world changes, etc. With these evaluation criteria, not all software is equal. Some companies are going to be left out.
If they are software publishers, we can lament with them for their difficulties but we can also be surprised to see entrepreneurs embarking on a business in which they know little about the fundamentals.
In the case of CIOs, the link between the difficulty of the job and the quality or lack of quality of information systems is not always obvious to developers. I’m thinking of this distributor who was unable to deliver a much more modern version of its loyalty card:
- the developers didn’t see how that could be a problem for anyone,
- to the proposal: “go to the shop and ask the manager what he thinks about it”, shrug: “I don’t see what I’ll do there! »
What indifference! What a lack of sense of community, not among colleagues on the same stage, but among all the people who go to great lengths to make the company profitable and pay their salaries. This doesn’t do justice to the energy of the IT teams and doesn’t recognize the difficulties they face every day. But it does reflect the reality that IT’s in-betweenness all too often hinders the ability of companies to compete in the digital arena.
The deployment of agility and lean is an opportunity to change this posture. The proposed increase in expertise of IT teams is to be considered by engineers, managers and executives as an opportunity to better support their respective companies. Succeeding in the sprints or otherwise driving improvements to succeed, satisfying customers or otherwise driving improvements to achieve them, delivering without bugs or otherwise rereading your code until you understand where you made a mistake should be part of the collective and personal commitments.
There is no reason to install in an unpleasant way this culture of responsibility and expertise: brutality demotivates a part of us and does not make those who accept it more efficient. On the contrary, learning makes people smile and both agility and leanness embody a good dose of team spirit and caring. Let’s make the most of it.
This post is a traduction from the original French post by Marie-Pia Ignace.
Thanks to Jean-Philippe Douet for his drawings 😉
 The gemba consists of going out into the field to observe client demands and how the process works. What we see feeds the search for causes and actions for improvement.
 His book “the high velocity edge” is a reference in the field.
 S. Dehaene, researcher in neuroscience, professor at the Collège de France