Lean principles is being adopted across all business areas. It is, indeed, an exciting time to see so much acceptance. In today’s interview, we speak with Cecil Dijoux, a very influential voice in the world of Lean IT, or Lean for Information Technology. In this interview, you’ll learn the following:
- How Lean for Software, Lean Startup, Kanban for Software Development and Lean for IT are different in some ways and similar in other.
- As an IT leader, how you can partner with those on the shop floor to broaden your reach in your lean transformation.
- How Cecil recommends shop floor leaders partner with their IT colleagues in reaching an even broader employee base in a lean transformation.
- What Respect for People actually looks like in an IT context.
We’re very grateful to Cecil for taking the time to speak with us. Enjoy the interview and read more about Cecil after the interview and be sure to read out other interviews with thought leaders in lean.
Hello Cecil, and thanks for taking the time to speak with me. Could you please introduce yourself and your work to the readers?
My name is Cecil Dijoux and I am a french IT professional with more than 25 years experience. I have been working in different countries, industries and types of organizations. This has raised my interest in organizations culture in the 21st century. It also had developed a passion for management (yeah, I know how sad it sounds) with a special focus on Lean, Agile and Enterprise 2.0. I have been blogging about these topics for a bout 7 years now on #hypertextual. Life being full of surprises I managed to have one of my articles being discussed on the New York Times online.
You are a recognized expert in Lean IT. Can you explain exactly what Lean IT is for our audience?
Hmm, being identified as a Lean IT expert by someone who has worked for Toyota is a bit embarassing. In all fairness, I would not rate myself as an expert: I see me more as an seasoned IT professional with a stong interest in Lean.Click to TweetFrom a general perspective Lean IT is just applying Lean principles to the whole world of IT : both the Build (innovation and development of new features) and the Run (deployment, operations, maintenance and support).
From an IT perspective I see Lean IT as an extension of Agile Methodologies along 5 axis : continous improvement, problem solving, value stream, customer and management.Click to TweetAgile has brought introspection to software development with debriefs on regular monthly interval. Thanks to daily problem solving, Lean brings continuous improvement and hansei on a daily basis. Learning loop becomes much shorter and people learn much faster. In Agile there is no structured way to handle problem and once you have harvested the low hanging fruit thanks to short iteration, visual management and enhanced collaboration, you hit a plateau. With Lean IT comes PDCA a structured practice for problem solving which helps in taking off from the plateau, indefinitely.
Lean IT also puts the customer right in the middle of the process while it seems to me that most of the time, Agile is centered around the team. Besides, Lean helps us focussing on the full value stream from Marketing to deployment and support, the last two being quite often ignored by Agile teams from my experience. Last but not least, Lean puts management back into the game : Agile tends to forget managers and put them aside. Lean brings what Mike Rother calls the teaching kata as a daily practice for managers.
Related question: If you were explaining what you do to someone on the manufacturing floor very familiar with Lean, how would you do it? On which areas would you build a common bond?
Hum .. a tough challenge ¦ I would be very humble trying to explain to this guy that IT is not only here to make his life miserable : it also can brings value to the company. The problem I see with most IT organization is they have given a bad reputation to IT. Their role has been to rationalize and set enterprise processes into the marble of complicated IT systems. Quite the opposite of Lean approach, really.
There’s been much talk about Lean for Software and Kanban Software Development. And, more recently, the Lean Startup. Can you draw some distinctions between Lean IT and them?
Lean Software Development appeared about 10 years ago with the work (and the books) of Tom and Mary Poppendieck. Kanban software development method appeared about 5 years ago with the book of David Anderson. Lean Start-up in 2011 with the work of Eric Ries.
LSD is more of a set of best practices. What I find fascinating with this work by the Poppendieck is that they naturally bridged Agile with Lean principles.
Kanban IT method (as opposed to Kanban as a production system, the initial one by Toyota) is merely an extension of the Scrum board while introducing the notion of reducing the Work In Progress and somehow pulling the flow. The main difference I see between Kanban IT method and Lean is that the former uses Kanban as an end (the tool to manage production in IT) while in Lean Kanban is used as a mean to feed the teams with PDCA and implement continuous improvement (actually, Kanban aim is to make itself obsolete). As we reduce the WiP, new problems appear and the team improve while solving them and removing waste. It is a slightly different perspective.
Lean Start-up is a Product Development approach. It helps in developing the right product very fast. Lean is an Organization Development approach : it helps in developing people so that they can develop the best product or services. We have an example with our customers. They’ve been developing great services thanks to Lean Start-Up approach. But then their growth spawned organizational problems they could not deal with. Lean has helped them in that regard with some quite spectacular results (tripled the business in 12 months).
One of the pillars of the Toyota Production System is Respect for People. Within the context of Lean IT, how is Respect for People put into practice? Is there a specific example you wouldn’t mind sharing?
This is a great question. Freddy and Michael Ballé have just published a great book on that very topic (Lead With Respect). What is really interesting is that book tells the story of an IT company CEO discovering Lean as she tries to deliver better quality service and software to her customer, an automotive industry supplier.Click to TweetRespect for People is a principle whereby if you put the teams in the right context they will succeed. My colleagues and inspiration Regis Medina and Antoine Contal always come back to the same three things:
- Clarify the challenge and make it measurable
- Create visual management to foster enhanced collaboration
- Coach the team on the shop floor and solve problems as they appear
In IT, the shop floor is the code, the continuous deployment environment, the server, the logs, the specifications, the support request etc ¦ That’s the reason why it helps in thoroughly knowing this industry to coach teams in Lean IT.
Sometimes people understands Respect for People as let them figuring out by themselves what the best course of action is and I don’t buy into that. There needs to be a challenge and problem solving for people to improve and be proud of what they achieve, every day. This great idea comes from Gemba Walks the book by Jim Womack.
A great example I have in the software development world is, while we were implementing Lean Software Development, how the work of the testers completely changed as they were involved from the very early stages of feature design. They were no longer the sad chaps that come and find problem at the end of the development changes. They were considered as experts helping the team all the way in building quality in.
More generally, can you share how some of the better known aspects of Lean looks like in the context of IT? For example, Poka-Yoke in IT? Kanban in IT? Andon in IT?
Poka Yoke in IT can be seen from the product perspective: structured data in forms not being able to enter text in a date field for instance. The example I love is when you mentioned an attached document in a mail in Gmail and you forget to put it, there is a message asking you if you haven’t forget to attach it. Another Poka Yoke in IT is in continuous deployment when the the application and the modules are built (compiled, and tested) and unit tests fail: then the system just stop and the module is not built : why would you build a module where you have introduced a regression and a test don’t succeed ?
Andon would be when a developer hit a problem she can not solve and then call her team leader to help her in fixing it on the spot. Scrum meeting in the morning is a great way to make such problem visible. Lean would not wait for one day to solve such issue but Scrum helps in making sure people don’t get stuck on issue for weeks (as I’ve witnessed a few times in my career).
For Kanban in IT, it can be used in development but I think for Support and / or maintenance teams it really is appropriate. The problem would be to make an organization wide Kanban to take into account the whole value stream. I am not sure how feasible that is in today’s organizations.
If we were to identify the 7 wastes in IT, what would they be? Do you have specific examples Transportation, Inventory, Motion, Waiting, Overproduction, Overprocessing, and Defects in IT?
From my experience¦ Transportation would be to manually copy data or system (servers installations and configuration etc ¦ ) around. I have this telling story of two great guys (both excellent developers) who are best friends always taking coffee break together : one was working in continuous deployment team and the other was a scrum master. It took 4 months and a working session I organised for them to figure out that the scrum master spent 90 minutes everyday to install a version of the software that the second one has automated. You tell me what a waste !
Most common Inventory I’ve seen are specifications that take time not only from product development but also development, UX and test teams, and these specifications are never developed because we run short on time.
Waiting is when you have developers waiting for some software from another team : cross-functional teams are a great way to remove those.
Overproduction can be related to over-engineering (developing a generic system for one use case what Agile mischievously prevents with YAGNI !) or overproduction of features : there was this study by the CHAOS group showing that more than two thirds of enterprise software features are hardly or never used !
Overprocessing can be related to, again, over-engineered software, that would, because of genericity and complexity, harm the performance in some significant way making life miserable for system users. Enterprise Software perfectly embodies this and anyone would has tried to trace Enterprise Java Beans code knows what I mean.
Defects are the easiest: bugs. Application should do Y it does X, it should do Z and you get an error 500 or 404 or the « blue screen of death »/ Or it should do X in 2 seconds and it takes 20.
Suppose a company was engaged in a bottoms-up lean transformation in an area outside of IT. How can the person on the shop floor, in a call center, in a nurses station partner with IT to have a broader effect on the organization?
I would bring people to the Gemba to show them the value stream and how easy it is for the user of the service or the product. Showing a streamlined process does wonder in having people to think about theirs. Like many Lean enthusiast I thought that people will be engaged when we talk about Ohno, Shingo or Kanban theory. Actually they don’t really care. When they see it in practice, it usually is some kind of revelation. And I would show it backwards, from the end, i.e from the customer perspective.
Now the opposite question: If someone was involved in transforming IT by implementing Lean principles, how might the IT leader reach out to other persons in the company that may be implementing Lean in their own world?
Again, I would show the value stream. I have this customer need expressed as a User Story (i.e from the Customer perspective). We have discussed this story with the full cross-functional team making sure we all are on par with what has to be done. We split it in small tasks, development of which we follow on our Kanban board with our pull flow. Then we make sure the support team is aware of the new feature, the code is implemented on production and the customer can test it. Showing how streamlined the process is and how value is created at every step is, in my opinion, the best way to have people think about what it would take in their own context.
Thanks Cecil. Is there anything else you’d like to share with my audience?
I strongly believe that Lean is the most appropriate way to manage enterprises in today business world. The world is changing fast with some changes being very brutal as not only companies, but whole industries, live under the threat of the advent of some radical innovation. Within that context, the ability for the organization to become resilient and to learn is key : this is what Lean brings to the company.Click to TweetTo be more specific, I believe that digitization is one of the main challenges of the organizations today and a Digital Kaizen approach is the best way to go.
My point of view is that Lean suffers from a low tech image and this does not gives justice to the lean ability to navigate this complex world : this is one pf the challenges of the lean community to change this perception.
Many thanks Pete for this great opportunity to discussing this with you. Keep up the good work!
About Cecil Dijoux
After 25 years in the world of IT I have decided to move to coaching. This experience allows me to help teams to create the context fostering continuous improvement and operational performance. I have practiced many of the different jobs of the industry (development, support, operations, architecture, management, methods) in all sorts of institutions (start-up, global companies, public organisations) in different european countries. This experience feeds my thoughts regarding cultures and organisations in an interconnected world, thoughts contributing to the blog thehypertextual.com. Enthusiast practitionner of Agile methodologies (since 2004) and Lean management (2011), passionnate about Enterprise 2.0, my role consist in helping IT teams and managers engage in a win-win-win formula with executives and the customers.
Other Interviews in our Lean Series:
Related Posts:
Become a Lean Six Sigma professional today!
Start your learning journey with Lean Six Sigma White Belt at NO COST
Leave a Reply