Insanity

April 17, 2018 — Posted by Al Shalloway

Part 1: Frameworks

Part 2: Blame the People

Part 3: Focus on Technology

Part 4: Ignore Management

Part 5: Ignore the System

Part 6: Trust your Assumptions

Part 7: Provide certification after certification with no support system

Part 8: Kill the Messenger

Part 9: Stop the insanity

Part 1: Frameworks

Einstein would say we’re insane – “Insanity, doing the same thing over and over and expecting a different result.”

For 20 years we’ve been trying to use frameworks to help solve our problems. We remark that a framework is flexible because we can put anything we want into it. That’s like saying a glass bowl is flexible because you can put anything into it. The glass is not flexible, trying to change it breaks it.

While frameworks allow most anything to be put in them, the framework itself has immutable aspects. These are designed to push the organization to change to adopt the framework. But the change the framework needs is not always a change the organization can do- given its culture, working model or current state.

The challenge is when people can’t figure out how to get the framework to work they change it. Then the proponents of the framework then blame the people, claiming they are not motivated. Frameworks can be great starts. But continuing to follow them verbatim to achieve Agility is kind of oxymoronic.

Part 2: Blame the People

We have the same challenges now we had back at the turn of the century, only we are even more locked into them with our current certification insanity. The great irony is that we pull out books that talk about how we need to trust and respect people. The certifying frameworks espouse this.  We take excerpts from Dan Pink’s and Stephen Dennings’ work and point to Google where people are given time to do what they want. We talk about self-organizing teams. We talk about Holocracy and servant leadership. It all seems great, people are great. Trust and respect them.

But what happens when things don’t work. When a framework fails. We hear things like “Scrum can’t fail, it’s the people.” Or “Scrum is simple, follow it as is” (implying that it fails because people aren’t following it. For 10 years I’ve been trying to get even one CST to admit Scrum does not work everywhere. Every now and then they admit it only to come back and say “Scrum only doesn’t work when people aren’t willing to do it.”

This is not only insane but it is contradictory, you either trust people or you don’t. If you do, stop blaming them.

Part 3: Focus On Technology

All of the Agile methods started from technology. Scrum, XP, FDD. I suppose the rationale is that where there’s fire try to put it out. But just because the developers had it last doesn’t mean that they’re to blame. Developers are in the situation they are in because of poor product management. True, bad development is common. But a lot of the reason it is present is because of overloading teams.

Agile has focused on the team since its beginning. The Agile Manifesto mentions developers 15 times. It doesn’t even mention management. It mentions business twice and the customer three times, but all regarding how developers work.

XP sprung from a single team of brilliant developers – the likes of which we’ve probably not seen in a team since (Ward Cunningham, Kent Beck, Ron Jeffries, …). Scrum sprung up as a solution for a single, isolated team to build a product. And it was led by the CTO. These are not where we are using them now. Let’s broaden our view.

Part 4: Ignore Management

Management has not just been ignored by the Agile community, it has often been vilified by it. I agree that almost all the time that managers should not be at the daily Scrum (there are exceptions). The problem isn’t we called them ‘chickens.’ Hell, we called the developers ‘pigs.’ It’s that we said they weren’t committed to the sprint result. That is appalling. There is a difference between not being committed and not working on.

The industry points to great examples of self-organizing companies but ignore how they got there. It wasn’t just a person with great leadership, such as Richard Sheridan of Menlo Innovations. The same person was or had great management to set it up and create the structure for people to thrive. We hate management so much that when it’s done well we call it “servant leadership.” What do you think great management is?

Then we blame managers for being “the permafrost.” What do you expect? Telling people not only they are not needed but they are the impediment creates a natural reaction.

We need to embrace Agile Management. It is essential.

Part 5: Ignore the System

A common phrase is “culture eats companies for breakfast.” True. But what do we do to change the culture? What is the culture? From David Mann:

Culture is important, but changing it directly is not possible. 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 or a place or organization is a result of what we experience there. In this way a company’s culture is a result of how people collaborate with each other. Culture is critical and to change it you have to change your method of collaboration.

Focus on agreements, behaviors, specific expectations, tools and routines practices. Lean systems make this easier because they emphasize explicitly defined agreements and use tools to make the work and agreements visible.

We have to attend to the system we have in our organizations. People behave the way they do because of the eco-system they are in. Overwork people, separate product owners from teams, coders from testers, bad things will happen – not because of the people, but because of the eco-system

Part 6: Trust Your Assumptions

We talk a lot about “inspect and adapt.” But always within the context of the framework we are following. This is single-loop learning. Trying to do what we are doing better. But maybe what we have to do is something different. Maybe our assumptions on what we should be doing are wrong. This requires double-loop learning.

Here are his definitions to start with:

Single-loop learning: learning that changes strategies of action (i.e. the how) …in ways that leave the values of a theory of action unchanged (i.e. the why)

Double-loop learning: learning that results in a change in the values of theory-in-use (i.e. the why), as well as in its strategies and assumptions (i.e. the how).

Our popular frameworks not only have assumptions built into them, they are “immutable” (check the Scrum Guide if you don’t believe me. But the framework is based on certain assumptions (a simple to define framework is the best solution for solving complex problems- changing a complex adaptive system)

This is often justified (as all insanity is) by saying people need a simple start. They do. But after the simple start something else must be provided. A support system.

Part 7: Provide certification after certification with no support system

Like the horror films of the 60s certifications are like “I don’t know what it is but it’s increasing at a fantastic rate.” But the problem is that’s all we have. Certifications. You can go from certifications that are about training to certifications that are about real ability in 2-3 years. What do you do in between the certifications. Where are the support systems for people? They are virtually non-existent. There are collections of information scattered around here and there. Lots of good stuff, but not organized and much of it is contradictory to other parts.

If we’re supposed to be respecting people we need to provide them with a support system for learning beyond a course here and there with certification as the end goal.

Part 8: Kill the Messenger

When someone says there's a better way, attribute evil motivations to him/her. When they provide these better ways, attribute marketing things that aren’t needed to them. When they claim to be able to do something inconsistent with "common knowledge", don’t ask how they did it, tell them that’s impossible.

I am reminded of Upton Sinclair’s-It's difficult to get a man to understand something, when his salary depends upon his not understanding it!

Schopenhauer-All truth passes through three stages. First, it is ridiculed. Second, it is violently opposed. Third, it is accepted as being self-evident. “So the problem is not so much to see what nobody has yet seen, as to think what nobody has yet thought concerning that which everybody sees.”

Bucky Fuller

I am enthusiastic over humanity’s extraordinary &sometimes very timely ingenuity. If you are in a shipwreck and all the boats are gone, a piano top buoyant enough to keep you afloat that comes along makes a fortuitous life preserver. But this is not to say that the best way to design a life preserver is in the form of a piano top. I think that we are clinging to a great many piano tops in accepting yesterday's fortuitous contrivings as constituting the only means for solving a given problem.

Part 9: Stop the insanity

I am not trying to offend anyone. I am not trying to ascribe motivations for behavior. I wrote this mostly for practitioners and those looking for better ways. If you are in this group and this has made you feel defensive, I would appreciate your letting me know by sending me a message.

I admit to not being sure when to express my passion and when to be more subtle. Passion won this morning. :)

  1. Frameworks Use operating models to wrap your framework or just use them on your own.
  2. Blame the People.
  3. Focus on Technology.
  4. Ignore Management.
  5. Ignore the System. Have management build great systems for people to thrive in. Their role is to look up to the vision of the business and then support the people who report to them by creating an eco-system in which they can self-organize and get their job done. Insanity
  6. Trust your assumptions Another definition of insanity: Dogma - persistently work towards a goal without ever questioning your methods. Persistence - dogmatically work towards a goal without ever being committed to which method you use.
  7. Provide Certification after Certification with no Support System Provide support system between certs.
  8. Kill the Messenger

Let's have an open discussion.

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