Lean-Agile and the Process-Innovation Pendulum

July 29, 2007 — Posted by Al Shalloway

Listen to the podcastLean-Agile and the Process-Innovation Pendulum

Alan was the keynote speaker at the SQE Better Software Conference in Las Vegas this year. Conferences are great for stirring up ideas and generating insights. For this podcast, I wanted to continue the series on Lean Anti-Patterns, sharing some more from what we are learning as we write this book. But you cannot always control a conversation. One of the hardest things to know as a facilitator is when to re-focus an individual or a group and when to let the ideas flow. You want the ideas to emerge and you want them to create the result. Today, I went with the passion, letting him share because I knew we’d get back to the other topic another day.

Innovation or Process?

Maybe it is a little like the challenge of the software industry: do we want process or do we want innovation? We keep shifting between the two. Software development methodology seems move between being creative and processes to control chaos. In the 70's, we had waterfall methods to structure our work. The 80's saw a burst of creativity with the rise of the PC, thousands of developers coming in and process took a back seat. The 90's saw a tension between the Internet (creative) and CMM (process). And where are we now?

Maybe it is time for a happy medium. Maybe lean can help us achieve it.

Lean sees process is the structure in which creativity can be expressed. Having standard work process frees me from having to think about the routine stuff so that I can spend creative energy on new stuff. The routine stuff always has to be done; standard work organizes it so that I do not have to devote more energy than necessary doing it.
I do not have to decide if I am going to do testing, if I am going to have work-cell teams, if I am going to communicate with customers. That is the routine.

As an example, I have just finished working with an organization where we needed to upgrade our Microsoft Office software. Now, you would think that ordering software would be fairly routine since the funds were already in place. But they had no process! Without process, it became an ordeal, all dependent on one guy to be a hero and figure out what to do next. We could go only as fast as he could work. Three weeks later, we are almost there. How much of his effort – and our time – was wasted because they had no process for the routine stuff.

Scrum and Iterative Analysis

Our biggest challenge is, and continues to be, to build products the customer wants. Thus, the biggest risk is building things the customer does not want. How do you manage this in a more complete way?

Lean-Agile would say to do a little, learn a little, then adjust based on customer feedback. Do not do workarounds and do not build too much. Seen this way, Scrum is perhaps more of an iterative analysis technique than an iterative development technique. It helps to minimize that risk of building what the customer does not want. The rest of the Lean-Agile framework – Analysis, Design Patterns, Test-Driven Development, Scrum, Process, QA – certainly help us to have an environment where this can be done.

Lean-Agile says it is OK to be productive, even without Scrum

That sounds flip, but it is a key point. We have had a number of clients where one of their groups is clearly more productive than the others. Yet none of them are doing Scrum, none of them are using iterative development. What accounts for the better performance? They are using Lean-based principles in their routine process while the others are not. They have co-location, voice of the customer, more up-front testing. And they are being productive.

Here is a story. One friend, a development manager at a software company, told me that he is ready to kick off his teams people who are Scrum evangelists. They do not recognize that he is applying the principles already in ways that fit their situation and they are greatly more productive than others. Other Scrum practices just don’t fit their needs. Rather than rebuking them, Lean-Agile would praise them while encouraging them not to be satisfied. He could live with that.

This is key because the goal is not to do Scrum. The goal is to produce more software that our customers see as valuable and less of what they do not want. Don't be dogmatic.

Recommendations - Training by Net Objectives

Music used in this podcast is by Kevin McLeod: http://www.incompetech.com. I changed to the new tune just because it made me happy. Kevin has some great samples going up there all the time. If you need music - royalty free (Creative Commons) then I’d encourage you to subscribe to his feed.

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

Blog Type: 
Podcast
Subscribe to our blog Net Objectives Thoughts Blog

Share this:

About the author | Al Shalloway

Al Shalloway is the founder and CEO of Net Objectives. With 45 years of experience, Al is an industry thought leader in Lean, Kanban, product portfolio management, Scrum and agile design. He helps companies transition to Lean and Agile methods enterprise-wide as well teaches courses in these areas.



        

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