Lean and What do we do next? - Part 1

January 17, 2007 — Posted by Jim Trott

Listen to the podcast Lean and "So, what do we do next?" - Part 1

These Lean-Agile principles all seem reasonable, but abstract. What do we do to put it into practice?

The problem of thrashing

It has been one of those years this last month. Snow, holidays, and hospitals conspired to put me behind. So I have gotten really far behind and am slowly digging myself out. I suppose you could say to me, “Physician, heal thyself!” because I have gotten caught up in the multi-tasking / thrashing trap that we are going to talk about today. Has that ever happened to you? Where you have so much going on, so many tasks clamoring for your attention that you don’t know where to turn next? I think I am a good multi-tasker, so I was amazed at how behind I got. I decided to adopt the Lean-Agile technique of doing more by doing less at one time. My throughput has improved, even if it means I have not gotten some things – such as the blog and podcast – done according to schedule.

Well, last week was spent working on a new content management system, based on Drupal. It is part of our knowledge management efforts here at Net Objectives. My prototype is done (and I’d be happy to share with you what I learned). We should get back to a weekly schedule on the podcasts soon.

OK. So, what do we do now?

I held this interview just after a challenging Lean-Agile Overview class that Alan had had. Midway through, the students seemed restless or frustrated. One of those times where you know you are just not getting through to them, that something is blocking the students’ ability to hear what you have to say. That happens sometimes and when it is a crowd of managers in the room, you know that no amount of pushing through the material is going to help. Taking a cue from the lean thinking principle to “stop the line” when something is going wrong, Alan Shalloway decided that the best thing was to stop the class and see what was going on.

The feeling of relief was tangible. They were only too happy to vent. “We understand these lean concepts: eliminate waste, decrease cycle time, doing just enough, voice of the customer. The concepts make sense. So, tell us, what are we supposed to do?

What sort of practical advice does lean offer me to start improving our processes? That is the question that every manager has. The principles of lean thinking seem obvious, general, and abstract. Putting them into practice is not so obvious. Help me make the connection.

There are a couple of ways to answer this question. The easy answer would be to hire me as a consultant and do whatever I tell you. But the better answer is to use this as an opportunity to learn lean thinking, to take on the eyes of lean. I wanted the students to learn to think honestly about the root causes that create limits to productivity. To learn to look for delays. And then to start using some simple tools that can help you remove bottlenecks in as smart a way as you can. And finally, to learn not to be afraid of starting where you can to make small improvements every day.

Think about root causes

Alan’s first answer to the question, “so, what do we do now” is to make the connection between the problems of delay you are seeing and the root causes for those problems. Organizational silos and thrashing are two primary types of root causes for delay. Thrashing is caused by multi-tasking, often brought on by having too many projects going on at once or having projects that are too large and complex.

A “Bold Claim”: Do more by doing less at one time

We see organizational silos and thrashing in one form or another in so many software development groups we talk to. Alan echoes a bold claim made by Mary and Tom Poppendieck that the best way to get out of thrashing, to improve your throughput when your pipeline is overfull is to stop trying to do so much at one time. As an organization and as an individual, you are better off focusing on one (or two) things at once, get them done, and then move on to the next thing. Having fewer projects and smaller projects is the way to avoid thrashing due to multi-tasking. This is an important – if scary – place to start.

Start eliminating delays, wherever you can and all the time

So, where do we start to to eliminate delays?

Alan has two answers for that.

  • At the team level, begin to introduce Agile development techniques.
  • At the business level, look at the entire value stream: everything that is done from initially getting customer requirements through to final delivery of finished product and getting feedback and providing support

Where you start probably depends more on what you think you can do at the moment, where your position of influence is. Both can deliver good results. Too often, people start with agile for a development team because that is where the coaches are, rather than thinking about where their bottlenecks are and starting there.

The important thing is that no matter where you start, you have to push on to get Lean-Agile thinking into the entire organization, from the local team level to the value stream management.

That is the third answer: a relentless pursuit of incremental improvements, small and large. Don’t feel like you have to solve everything all at once. Big initiatives rarely work and usually cannot be sustained. It is better to get 1% improvement every day than one 20% improvement that never happens again.

Look at the Value Stream

If you can do it, it is better to start looking at the value stream than to simply implement Agile. Why? Because the development team might not be your main bottleneck. Sure, you might make that team more efficient, but if the process is jugged up elsewhere, the customer won’t really benefit. They will still get the finished result as slowly as ever.

Here is an example:

One of our clients had a great development team. They could turn around requirements fairly rapidly. But not matter how fast they were, how responsive they were, customers were still dissatisfied because of delays in delivery. It seems that installations never went quite as well as planned. It turns out that the marketing department had over-promised on the product configuration. Invariably, the sales engineer was faced with days of work to install the product on yet another non-standard configuration. The delay was not being caused by the developers but by marketing. Looking at the entire process from customer requirement to product installation, they discovered the major queues were no in development but in installation. Doing a root cause analysis led to an understanding that marketing was not evaluating the customer’s infrastructure sufficiently. They changed the marketing process, which led to quicker installs, further up-sell opportunities, and more satisfied customers.

All with no change to the development process.

Talk to us

I want this to be very useful to you and want to dive into the issues you care most about. So, I would appreciate it if you would drop me a note to jim.trott@netobjectives.com with the topics you want us to cover. This blog and podcast series is really about how we can provide value to you.

Recommendations - Training by Net Objectives

Recommendations - Reading

Music used in this podcast:

For more information, contact info@netobjectives.com or visit us at https://www.netobjectives.com

Blog Type: 
Subscribe to our blog Net Objectives Thoughts Blog

Share this:

About the author | Jim Trott

Jim Trott is a senior consultant for Net Objectives. He has used object-oriented and pattern-based analysis techniques throughout his 20 year career in knowledge management and knowledge engineering. He is the co-author of Design Patterns Explained: A New Perspective on Object-Oriented Design, Lean-Agile Software Development: Achieving Enterprise Agility, and the Lean-Agile Pocket Guide for Scrum Teams.


Blog Authors

Al Shalloway
Business, Operations, Process, Sales, Agile Design and Patterns, Personal Development, Agile, Lean, SAFe, Kanban, Kanban Method, Scrum, Scrumban, XP
Cory Foy
Change Management, Innovation Games, Team Agility, Transitioning to Agile
Guy Beaver
Business and Strategy Development, Executive Management, Management, Operations, DevOps, Planning/Estimation, Change Management, Lean Implementation, Transitioning to Agile, Lean-Agile, Lean, SAFe, Kanban, Scrum
Israel Gat
Business and Strategy Development, DevOps, Lean Implementation, Agile, Lean, Kanban, Scrum
Jim Trott
Business and Strategy Development, Analysis and Design Methods, Change Management, Knowledge Management, Lean Implementation, Team Agility, Transitioning to Agile, Workflow, Technical Writing, Certifications, Coaching, Mentoring, Online Training, Professional Development, Agile, Lean-Agile, SAFe, Kanban
Ken Pugh
Agile Design and Patterns, Software Design, Design Patterns, C++, C#, Java, Technical Writing, TDD, ATDD, Certifications, Coaching, Mentoring, Professional Development, Agile, Lean-Agile, Lean, SAFe, Kanban, Kanban Method, Scrum, Scrumban, XP
Marc Danziger
Business and Strategy Development, Change Management, Team Agility, Online Communities, Promotional Initiatives, Sales and Marketing Collateral
Max Guernsey
Analysis and Design Methods, Planning/Estimation, Database Agility, Design Patterns, TDD, TDD Databases, ATDD, Lean-Agile, Scrum
Scott Bain
Analysis and Design Methods, Agile Design and Patterns, Software Design, Design Patterns, Technical Writing, TDD, Coaching, Mentoring, Online Training, Professional Development, Agile
Steve Thomas
Business and Strategy Development, Change Management, Lean Implementation, Team Agility, Transitioning to Agile
Tom Grant
Business and Strategy Development, Executive Management, Management, DevOps, Analyst, Analysis and Design Methods, Planning/Estimation, Innovation Games, Lean Implementation, Agile, Lean-Agile, Lean, Kanban