Change is Learning: No Silver Bullets or Quick Fixes

Way back when I was a developer, my professors taught me structured design and design by contract. Those were supposed to be the silver bullets for programming.  You see, if you specified things enough, and structured things enough, everything would all work out.

I thought I was the only idiot that structure and specification didn't work for. Why did I have to iterate and increment?

At my first job, we had design reviews and code reviews. I learned a lot. I worked on a government contract, and the government mandated those reviews. They were useful, and they were supposed to be a silver bullet. Because we implemented features (yes, back in the '70s, we implemented features), the reviews were helpful in the small.

But, I worked on a program. There is just so much design by contract can do for a program. I was in Boston. I had questions for my counterpart in New Mexico. I was not allowed to talk to that person. (To this day, I don't know who that person was. That person was part of another subcontractor.) I had to send my questions up through the project management layers to the program team and down the other side. My questions never did get answered. I left that company before I knew if my code worked with the entire system.

I transitioned into project management, program management and people management. I have seen my share of fads, bullets, and fixes for the software departments.

As a director in the early '90's I got sent to TQM school (Total Quality Management). My company thought it would change the way we managed, and revolutionize our organization. It would be our “silver bullet.” I'm pretty sure those were somebody's words. They weren't mine.

I got a certificate for my five days of intensive training (powerpoint and calculations). I might still have it somewhere.

I became excellent at calculating many costs: the cost of quality, the cost of not doing things right,  the cost of technical debt, even what we might consider the cost of delay. I dutifully explained these costs to my senior management. Was I able to persuade my company of the cost of not doing the right thing, even though I was a middle manager, a program manager, and had been TQM'd?

No. My management was too concerned that doing things “right” would prevent us from making money. I had data—yes, data—that proved them wrong. But their belief systems overcame my data.

Later, after I started my consulting business, many of my clients fell into the ISO 9000 and the CMM/CMMI quick fix/silver bullet traps. The ISO joke made the rounds: “You could specify a cement life jacket with ISO, as long as you define the right process for creating it.” Well, no. But the jokes still persisted. (Many people find value in ISO. Some do not.)

And, with the CMM/CMMI? Oh, my clients had binders full of documentation, but they weren't releasing software. They hired me on the side, because their silver bullet of CMM/CMMI process wasn't working. Somehow, my approaches of timeboxes and increments, and iterations, and thinking about their projects was. (Many people find  value in using CMM/CMMI. Some do not.)

Now we have agile. If you read my work, you know I lean towards agile and lean. At the same time, I say that agile is not for everyone. Agile is not a silver bullet.

We have no silver bullets in software.

We have difficult problems to solve. We must think about our approaches, each and every time. We must consider our context. That why I wrote Manage It! Your Guide to Modern, Pragmatic Project Management. Because every single project is unique. That's why I'm writing Agile and Lean Program Management: Collaborating Across the Organization. That book is a principle-based approach to program management, to scaling agile past one or two teams. Not a one-size fits all approach to program management.

And, because we have no silver bullets in software, and because we have no quick fixes, my management myth this month is We Need a Quick Fix or a Silver Bullet.

It's very tempting to think that transitioning to agile might be a quick fix or a silver bullet. Transitioning to agile or lean might help you. It won't be quick.

Any transition is a change. Change takes time. Change is learning. Developing software is learning. You can help yourself learn faster with some approaches: make value obvious instead of tasks, get feedback often, visualize your work, etc. For many of you starting your agile journey, these are cultural changes.

The more you challenge the culture, the longer the change takes because people need to learn what to do and how to work. Cultural change is not a silver bullet. It is certainly not a quick fix.

Read Management Myth 33: We Need a Quick Fix or a Silver Bullet.

12 Replies to “Change is Learning: No Silver Bullets or Quick Fixes”

  1. Great post Johanna,
    I don’t think any of us are surprised that people and organizations tend to gravitate towards silver bullet answers. Simply load your silver bullet into your golden gun, point and shoot. Problem solved. They are like problem solving crack. They are highly addictive, and will probably eventually lead to your demise.

    1. HI David, if you are lucky, some of the silver bullet thinking works. Well, maybe if you’re unlucky. Because then, as you so nicely said, you get the addictive problem. You might not get the demise problem, but the change is not likely to be successful.

      We need to think through the change that we need, and recognize that we have people in the organization. That people do the work and that people will change. That is the hard part. It’s all about the people.

  2. Do you think organisations are technically skilled enough to actually make software? As you say it is all about the people (I totally agree). But if all those people don’t understand developing software is there any option but to look for a silver bullet?

    1. HI Andrew, yes, I do believe many of the people in organizations are technically skilled enough to make software. Some of those people don’t know what they don’t know (as many of us don’t). If people don’t use the technical practices of XP, they don’t have their safety nets to hold them. If they don’t use design patterns, they don’t know either.

      I find that when it comes to change, and wanting results fast, managers especially look for silver bullets. Maybe your experience is different. It’s so tempting to think, “This is the thing, whatever it is, that will save us.” But I have discovered that almost nothing saves a project except hard work: small increments of hard work with feedback.

      As I said, maybe your experience is different. But I have found that if people, smart people, do small increments, get some feedback, if they are open to learning, they can do amazing things. Yes?

      1. I think you are right, the people are technically skilled enough to make software. But their management practices just get in the way, and that seems to kill their thinking.

        So it’s always going to be tempting to go for that silver bullet, that is what will solve all their problems. I totally agree with you that the only real way to solve these problems is to appoach them logically, work on small pieces, and get feedback on where it is going.

        But do companies get more than they bargain for in the Agile/Lean approach? Agile embraces change and internalises it, inviting it into the organisation. That is a scary prospect for a lot of companies, and most of the ones I have worked for are not ready for the sort of change Agile wants from them.

        1. Andrew, this is why I am writing these management myths. Next year, I will collect them into a book. I’m thinking of calling the book something like “Reclaim Your Leadership.” Something with leadership in the title.

          Because too many managers won’t read management books. But they might read leadership books. What do you think? (Sneaky of me, eh?)

          As to do companies get more than they bargain for in Agile/Lean? Oh, yes. That’s why I wrote Agile is Not for Everyone. Agile brings a transparency that is truly not for everyone.

          And, so many people jump on the Scrum bandwagon, without realizing that Scrum is a total cultural change. Lean says, “Let’s take a look at your value stream, map it, and improve it, bit by bit.” Scrum says, “Change your culture, right now. Jump into this ice cold water.” Wowza!

          My experience is that many organizations are not ready for what they ask for. They want the results—which is great. But the top managers think it’s a project management change, not a cultural change. It’s a problem.

          1. That is a great idea, there are certainly a lot of myths around management and a lot of them are killing companies.

            I think that is the key, people need to stop seeing themselves as managers, they need to be leaders. The key difference (for me) is they actually take on responsibility a do good work. Most managers simply pass the responsibility onto others, then wonder why it isn’t moving forward. I covered a little of that in my podcast this morning, going to go into a lot more depth on it. Do you think actual leadership is lacking in software development?

            Great idea to make it into a book on leadership, they won’t read another management book.

            Great article on “Agile is not for everyone”, you hit the nail on the head.

            Scrum is that silver bullet again isn’t it. They have been told “go do scrum, it is easy and it will make you more productive”. It will, but only by changing how the company works. But that is the thing scrum is simply pointing out everywhere the company is weak and fighting against making their products.

            That is my experience as well. The directors want the performance gains promised from “being agile” but when it points out why they are not productive they instantly fight against it. Is that rational, or is that vanity?

  3. Pingback: What you need to know to get started with agile | Software Rocks

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.