Getting Business Into The Agile Mindset

May 7, 2017 — Posted by Al Shalloway

I was recently asked “Any recommendations on a book for how a middle manager can drag a business into an Agile mind set against their will?”  The answer is – “you can’t drag business into an Agile mind set against their will.”  In fact, you really can’t drag anyone into an Agile mindset against their will.  I also find it ironic that I hear Agile coaches ask me a similar question, “Any recommendations on a book for how an Agile coach can drag a middle manager into an Agile mindset against their will?” 

To enroll people in a new concept you must focus on what value they will get from it.  It is best to assume that any lack of motivation is due to a lack of understanding which tends to create fear.  This may not actually be the case but if you assume otherwise you won’t have any power in the conversation.

Another challenge with the question is “what is an Agile mindset?”  And a corresponding question is “what is being or doing Agile even mean?”, and do we want that?  Many people still cling to the idea that Agile is defined by the Agile Manifesto.  I find this incredibly ironic that a movement based on continuous improvement holds onto the ideas that are now 16 years old.  If Agile is about learning surely we’ve learned something over these 16 years.  One can consider the Manifesto to be a statement of what we should be doing, but I like to think of Agile as what is effective and not a mandate for a particular set of actions.

In defense of the manifesto as the definition of Agile, one might say values and principles don’t change.  But what are often referred to as the values are really activities that result in better results.  For example, attending to working software over comprehensive documentation is really a statement that attending to working software will provide better results than attending to comprehensive documentation.  Is it any surprise that many folks talk about “doing Agile”?  But then, what does “being Agile” mean? 

The twelve principles behind the manifesto give us some clues, but leave a lot implied.  This is intentional, of course.  This enables us to manifest the manifesto (pun intended) in our own manner.  But who is “us?”  Management is not mentioned at all in the 12 principles of the manifesto and business is mentioned only twice while the customer is mentioned three times.  However, the development group is mentioned 17 times.  I believe this implies the manifesto is focused on what the teams do. 

Ah, but now back to the question of what is Agile?  Many claim it is not about “doing” Agile but “being Agile.”  Being Agile implies a culture of Agile.  But what is culture?  I think David Mann, in “Creating a Lean Culture,” provides the most concise definition of it:

"Culture is no more likely a target than the air we breathe. It is not something to target for change. Culture is an idea arising from experience. That is, our idea of culture of a place or organization is a result of what we experience there. In this way, a company's culture is a result of its management system. The premise of this book is that culture is critical, and to change it, you have to change your management system."

I would suggest you can’t ”be” Agile unless you are “doing” Agile. 

So let’s get back to our original question – “how do we get business folks being/doing Agile?”  Since we can’t drag them into it, we have to look at what’s in it for them?  What do they want?  Many Agilists talk to business folks about Agile in the same way a car salesman may talk to a person not interested in mechanics about the wonderful engine in the car they are trying to sell.  Most customers don’t care about how the engine works.  They care about performance, fuel economy, environmental considerations, etc.  Even mentioning fuel injection, etc., only has value if fuel injectors give them what they want.  I use the metaphor that Scrum is like the engine in your car, important, but from a driver’s perspective, only because it is necessary to get what their objective is – efficient, safe, comfortable movement from one place to another.

So what are the objectives of the business?  I would suggest “faster realization of business value efficiently, sustainably, predictably and with high quality.”  I rarely hear people talking to the business about this, let alone how to do it.  We talk about how teams have to work and almost all of our focus is on the implementation side of the value stream.  Where does Agile provide us assistance on funding, on sequencing of work across the enterprise, of getting predictability or managing risk? 

The truth is, Agile was defined for how a team should work with the rest of the organization and discusses this from the team’s perspective.  Is it any surprise that business folks are not all that interested?  In fact, I question that they should be interested.  The question isn’t “how do we get business folks interested in Agile,” it’s “how do we get Agile folks interested in the business needs of the organization?”  Sure, we have product owners that define the backlog, but product ownership is fairly far down the value stream already.

I would suggest we need to extend Agile to the entire value stream – starting with the discovery of what is of value.  To get “faster realization” doesn’t mean to go faster, but rather to both don’t build things of lesser value and do it in such a way to eliminate causing rework (e.g., fixing bugs, integration errors, etc.  The first is a focus on effectiveness (doing the right thing) while the later is a focus on efficiency (doing it right).  Business’ role is therefore to fund the right initiatives and management’s role is to create an eco-system in which people can work.  Agile doesn’t discuss the first one but almost spells out the second one in the principle “Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.”

Finally, back to answering the question, there is no book that spells out the entire business to team to DevOps cycle.  Our book “Lean-Agile Software Development: Achieving Enterprise Agility” covered quite a lot, and is still ahead in many places compared to industry practices.  However, I consider it obsolete to what we (Net Objectives) are doing now.  I would suggest a good start would be the article The Business Case for Agility.  The key to remember is “what is the objective of Agile?”  I would suggest that’s business agility.  I would try to enroll people in that. Talk from their perspective.  They don’t care about the how (that’s your job) they care about the what.  That may be just what they should be caring about. 

Al Shalloway
CEO, Net Objectives

If this question interests you and you are looking for assistance, please contact me about a free consult (not a sales pitch).  I love doing these because this is how I learn where people are and what their challenges are.

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 over 40 years of experience, Alan is an industry thought leader in Lean, Kanban, product portfolio management, SAFe, Scrum and agile design.



        

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