In 2010, while it was an IT manager in the insurance industry, I have been asked to significantly improve the efficiency of my development teams. Having accepted the challenge, I familiarized myself with Agile practices. At the same time, the organization was taking a Lean turn that was strongly supported by the president. Let’s look back and I’ll tell you how both Lean and Agile approaches can cohabit and why I can now no longer dissociate them.
Back then, I called upon Pyxis to guide us on our journey to improve our IT development process. We started with a pilot team composed almost entirely of volunteers.
This initiative was done with the support of the business and IT people. The Operations Vice-President for the business line as much as the IT Vice-President were involved. It’s important for this type of initiative to be supported by upper management.
Organizing the teams
We were able to ask the business line to give us the project of its choice, we certainly had a team able to carry it out successfully.
On the other hand, with our capacity back then, we would not undertake more than three projects at the same time. A fourth team would be in charge of making sure that the three other teams were focusing on their respective projects. This team was therefore in charge of making minor improvements prioritized monthly by a group of users representative of the business line, and of ensuring the second level support.
In the context of the governance that was in place, everything was managed by two processes :
- Strategic projects
There was no more ongoing projects than the number of teams.
- Evolution requests
A committee had been created, composed of representatives of the different points of view found in the organization. With a one-hour monthly meeting, they were establishing the priority order of the requests. This prioritization was guided by criteria established by consensus based on the organization’s values. The prioritized list was constituting the evolution backlog that the team in charge of improvement was achieving with a Scrumban approach.
The production of the projects was rather Agile, but let’s take a look at what more the Lean approach was bringing…
Agile practices (Scrum and Scrumban) are essentially based on business value. They consist of creating the greatest value first and adding the second and so on as prioritized by the person managing the product , the Product Owner (PO).
On his part, the PO tries to prioritize the opportunities to improve the different steps of the process in place. Although we are always looking to question the needs, the prioritized features are likely to be related to processes and/or steps of processes that are not optimized or even unnecessary for the client in the end.
So, even though we deliver the greatest business value according to the PO, if we work on optimizing a part of the process that would not even exist if it was refined, we kind of work for nothing. You think it’s obvious? The problem is that we are rarely conscious that this portion of the process doesn’t need to be there.
With the Lean approach, business value is taken seriously!
The Lean approach is based on 14 principles of the Toyota model (according to Jeffrey Liker) :
- Base your management decisions on a long-term philosophy, even at the expense of short-term financial goals.
- Create a continuous process flow to bring problems to the surface.
- Use ‘pull’ systems to avoid overproduction.
- Level out the workload (heijunka).
- Build a culture of stopping to fix problems, to get quality right the first time.
- Standardized tasks and processes are the foundation for continuous improvement and employee empowerment.
- Use visual controls so no problems are hidden.
- Use only reliable, thoroughly tested technology that serves your people and process.
- Grow leaders who thoroughly understand the work, live the philosophy, and teach it to others.
- Develop exceptional people and teams who follow your company’s philosophy.
- Respect your extended network of partners and suppliers by challenging them and helping them improve.
- Go and see for yourself to thoroughly understand the situation (genchi genbutsu)
- Make decisions slowly by consensus, thoroughly considering all options; implement decisions rapidly.
- Become a learning organization through relentless reflection (hansei) and continuous improvement (kaizen).
Here is roughly how these principles were applied concretely :
First, each business line was doing an analysis of its value stream (VSM, Value Stream Mapping) while making sure to have all the stakeholders around the table. The designated people were isolated in a group for the exercise that could last from one to two weeks.
Then, thanks to the information gathered during the previous exercise, the business people were selecting the most significant part in the value stream and setting an ambitious objective to improve it. For example, that a transaction be treated within three days, 80% of the time (According to the VSM, it was taking an average of 15 days). A simple and well-thought-out Lean canvas was then created and it was becoming the first mandate to be conducted.
A team was formed to carry out this Kaizen of a duration of one to two weeks. This time again, people from all points of view were brought together on a same site to contribute. To achieve their mandate, team members first needed to share a common understanding of the process in place by making it visible on the wall.
During this exercise, we take care of making the steps that create added value for the client visible, as well as the different wastes, like time delays, unnecessary movements, etc. Then, the team starts with an empty wall and creates a new process, inspired from the 14 principles mentioned above, that will answer the client’s needs and obtain the sought-after benefits. The gap between the old and new processes translates into a list of activities and deliverables to produce. Imagine that this list of projects/activities is very different from the list of needs of the original process.
To deliver the deliverables, a team of users and IT people was created in order to complete the mission (the project) arising from the Kaizen. The backlogs were therefore fed with thoroughly defined needs to answer the necessities of a clean process. Thus, we were only conducting really profitable projects. And the contribution of the final users was implicit. The end clients (the paying clients) sometimes took part in this work with targeted attendance during demos in order to gather their feedback as early as possible in the process.
All the IT teams were working together with the internal clients (that we called partners) as early as possible in the process. Thus, they were aiming at creating an architecture, infrastructure and emerging applications adapted to the “just enough” need to attain the Kaizen’s objectives. Once this process or portion of the process was clearly improved, the organization prioritized the next item of its value stream.
You think it sounds easy, not at all! Is it really possible? Yes, by establishing a clear objective and putting everyone’s egos aside, to the benefit of this objective inspiring to all that allows the client to be kept at the centre of everybody’s concerns.