Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ


Choose your language

InfoQ Homepage News Putting Quality Back in Agile with Lean

Putting Quality Back in Agile with Lean

Leia em Português

This item in japanese

The agile manifesto and lean practices are very complementary; lean can be a useful addition to a very strong agile process to increase quality, argued Renaud Wilsius. Interviewing real clients or client proxies to deeply understand their pain points and visualizing the process by diving into the handovers between departments helped one company to uncover problems faster and fix those problems more efficiently for a lower price.

Renaud Wilsius, R&D director at BISAM, spoke about applying lean practices in an Agile Environment to focus on quality at the Lean IT Summit 2017. InfoQ is covering this conference with Q&As, summaries and articles.

InfoQ interviewed Wilsius after his talk about how they applied lean with agile and the results that they saw.

InfoQ: At the summit you spoke about having quality issues; can you describe the situation?

Renaud Wilsius: As a Software Editor BISAM, a FactSet Company, has always taken product quality very seriously. We adopted eXtreme Programming back in 2006 and since then we use pair-programming 100% of the time. This practice has been completed by a test first approach where developers write tests before writing business logic. To support this test first approach, we built a powerful testing framework which supports today more than 20k tests.

However, quality has not been at the expected level at the genesis of our lean project. Software complexity has been increasing as we onboarded new clients. Many technical combinations lead us to test almost an infinite number of possible cardinalities, moreover more clients with different patterns of product usage also led to an increasing need for client data to reproduce the issues they are experiencing. As data is client property, databases are very large and since our software is mostly deployed on premises it is not possible to request client data.

Clients loved our product, which they found very comprehensive and they love the new features. But none of them wanted to take the early versions; they faced a lot of installation issues and were more and more complaining about a growing number of open tickets without any remediation plan.

InfoQ: What made you decide to go for a lean approach to solve the issues?

Wilsius: Our mandate to solve this situation came from our top management, and the KPI of that project was visible to the private equity who owned most of our company. The nice thing about being in the spotlight is that we were fully supported by our hierarchy to make our choices, and they were ready to invest to show a fast and visible turnaround.

We looked at the option of offloading our quality assurance to an external team and met a couple of highly qualified companies who came with a bunch of recommendations. This approach was very convenient to articulate/explain to our client: "we had a quality issue, we identified the issue and we will put a team on it who will fix it. We are spending $ X on it, and here is a laundry list of what they will do for us to ensure this quality reputation never surfaces ever again".

Nevertheless, our R&D managers and I did not feel right about an approach to "externalize our problems". Assuming those companies managed to build this perfect "quality wall", we would still have to solve the issue and fix the root cause. We had trust in our software editor expertise, and we thought that if someone had to tackle that issue it would be much more harmonious to bring the issue back to the one who created in a timely and efficient manner. We believed that developers in our group are there to do the best they can, and if from time to time they fail then it is either due to a lack of knowledge or more probably a systemic problem.

With this agile mindset, we naturally came to see Operae Partners who helped us frame our problem in a lean way. First, by understanding better what our client wants when it comes to quality, and second, by involving all the teams in redesigning and improving their work environment to achieve quality.

InfoQ: How did you start your lean journey?

Wilsius: We started from the client, interviewing real clients or client proxies (internal account managers who represent clients) to deeply understand their pain points. Then we used the information to make our problem very specific:

  • Too many failed software installations
  • Too many regressions issues
  • Many software releases without updated documentation

We brought all the departments together to review the current process, focusing on the handover between departments and took over one of our rooms to become our Obeya, where we put all visual performance indicators.

Our goal was to deliver one good version first for an identified client.

On the team side, even though initially we on-boarded all the R&D, we promptly realized that the project was losing traction because some people were reluctant to the lean approach. Some people are experts in their domain and prefer to live with their problems rather than solving them. Understanding the root cause of a problem can be very time consuming and many people feel that it is a waste of time that is taken from their production time… Therefore, we decided to focus on the people/team who are ready to adopt the change early on, while keeping the other team in the loop to prepare for a larger transformation.

Those trend setters shortly showed visible progress which attracted respect from others and removed the worries and concerns that other teams may have had.

InfoQ: You managed to get good results with lean in three months. What was it that helped you to get results so quickly?

Wilsius: To introduce a new practice, it is always good to have a disruption; in our cases we had a crisis with an unhappy client who demanded immediate results. Agility is part our DNA and as a company I think we managed to cope with change much faster than other companies.

When you think about it, the agile manifesto and lean practices are very complementary. Like Mr Deming, we always considered that "quality is everyone’s responsibility" therefore any methodology which could help us discover issues as soon as possible was a definite progress for our team. Last but not least, the lean approach has been selected by the managers with the support from their hierarchy which helped tremendously in the adoption process of lean.

At the end I think lean has been a nice addition to a very strong agile process in place to uncover problems faster and fix those problems faster for a lower price.

InfoQ: What did you learn in your lean journey? How has that helped you to continue with lean?

Wilsius: In terms of lesson learnt, I would say that you should trust your people who are on the field to do the job. They are the most knowledgeable about their work and are eager to do their job the best way they can. Teach them lean thinking so they realize they have problems, and start fixing them. Once those practices have been sinking in, Management needs to support lean practice at each level of the hierarchy to make the practice stick to the organization.

Rate this Article