The revolutionary Think System; Trouble right here in software city.
The revolutionary Think System
Trouble, right here in software city!
That’s trouble with a Capital T. That rhymes with P and that stand for pool! Wait, pool is the “trouble in river city”. In software city the real problem can be what I call the “Think System.” In case you never caught a rendition of “The Music Man” (by Meredith Wilson, opened in 1957 and ran for 1375 shows) the “Think System” is what the con man uses to "teach" music and disguise his ignorance. In software we run into the think system all the time. When we tell our teams to “Think Agile!”, “Think Quality!”, “Think Security!” or “Think Idea of The Moment! ” we can cause Trouble (with a capital T).
In my last post I described some of the reasons that make changing your process hard in organizations. Now that you know how to avoid the pitfals, how do you get past use a "Think System"? Luckily there are good ways to build lasting change in your organization. Here are some experiences I have had that should help guide you.
Don’t fall prey to a Think System
Management and even the worker bees (IC’s in Microsoft Speak) sometimes get really excited about a concept. Sometimes these concepts are just the current fad and don’t amount to much, sometimes they are vital to the next level of software evolution. You usually have to try them on to see. Change isn’t easy, and sometimes group handicap themselves more than they really need to. Usually this is when we tell everyone to “Think Idea X” but don’t do a good job communicating what the idea really means.
Intuition can be flawed
In software construction the obvious path can sometimes lead over the cliff. I see teams get fired up with ideas. This is great, but when there is no substance behind them we get into trouble. We can all take off in ten directions thinking we are pursuing the grand vision. Getting everyone back together can be like herding cats. Worse, we can all nod and smile then run off the cliff like a heard of lemmings.
I have seen software projects go off the rails in both ways. I worked in a company where my boss believed wanted to have a superior lab. His think system was “Think Super Lab”. There was one camp that believed that a neat lab with completely documented processes was the key to “Super Lab.” There was another camp that believed that functionality was paramount and neatness was a nicety best left for later. This was a giant disaster. Everyone was pursuing a different version of the vision. There were pitched battles and end the end, the lab was neither functional nor neat. Each camp had an intuitive approach to having a “Super Lab”, but both approaches were flawed.
I have also worked on products where everyone was heading the same direction. Sadly, like the lemmings, we were headed over a cliff. It was a more pleasant experience in some ways. We all knew we were doomed, but nobody would rock the boat. Our instinct to go along with the herd meant the product launch was a lot like a train wreck. Don’t let this be you.
Ask what success looks like
The acid test for a “think” system is the lack of a visible or knowable finish line. Engineering is a place where we should be able to use facts to drive our actions. All too often we merely think and feel we are doing a good job and don’t have a way to prove it. Some bosses I really respect constantly ask the question “How do we know we are winning?” They draw the finish line on the track and point it out clearly to everyone. Metrics can let you down, but that doesn’t mean you should never use them. There is a place for instinct in business, but software construction that is based purely on instinct is doomed.
Two way communication is key
Knowing what success is will help you make course corrections along the way. Make sure your message is being heard. Make double sure that you are hearing the messages coming up from the guts of the project. Not only do you need status reports, but you need to know the people giving them understand what you are asking of them. It’s easy to drown a team in busywork and generate a boatload of metrics. You get better information from people who understand what the metrics mean and how they drive the business. When you are trying to change your culture with a new idea it’s really important to get timely feedback and make sure the team knows about it. I have seen Technical Support operations where the wrong metrics were being given as feedback to the team. Things like average call time; hold wait times and call abandonment were put up on a big board. The person with the shortest calls and greatest volume got cash rewards every week. The problem was customer satisfaction was in the toilet. Management was very upset and started firing “poor performers” with “bad numbers”. Customer satisfaction went even lower. The problem was with communication. Management was looking at one set of numbers (customer satisfaction) and showing the workers another set of numbers. The communication was very one sided. The more management pushed, the more people who were being nice to customers left or were fired. The only people left were the ones good at keeping calls short.
We make the same mistakes in software all the time. We want high quality software and then we publish a leader board with the highest number of bugs logged. This leads to cherry picking and avoiding diagnosing complex problems. The testers get in a race, and the product quality suffers.
Be clear in both directions with what you are trying to accomplish and how you plan to get there. Don’t assume people will automatically understand. Double check your assumptions. Listen closely to critical feedback. When I worked I help desk I learned that every call had a lesson for the company. A way to do things better was there even if the person on the other end just calls and curses and yells.
Build frameworks to guide you
You can break all the rules you want. You just have to know the rules first, and then have a damn good reason to break them. Make sure your team has a framework to build from. A little guidance goes a long way to keeping everyone on the same page, productive and happy.
Build from a solid foundation
It’s important your framework be on a solid foundation. Time after time I have seen frameworks built on the quicksand of “best case scenario” or be paralyzed by “worst case scenario.” You also need to make sure your house is basically in order before you charge off in a bold new direction. If your team doesn’t have the basics down, make sure you get up to speed before you try to swallow a new idea, practice or work plan.
Be honest about what isn’t nailed down
Sometimes you need to put some stakes in the ground for planning purposes. Make sure your team understands what the hard assumptions are and where you are just sketching. This comes back to communication of course. You need a framework, but you don’t need to have the whole thing nailed down before you start to work.
Use built in flexibility
Make sure your framework isn’t too rigid. There is a military saying “No plan survives contact with the enemy.” It’s the same in software. The very best plans are ones that have built in flexibility. They often take very small bites and then have decision points where you can act on that flexibility. This brings me to my next section.
Iterate on your ideas
People will tend to fall back into old habits. In order to institute something new you have to keep at it. Human beings need fairly constant feedback in order to change a habit.
Do pilot programs
A good way to start a new program is to try it on a small scale. Set aside a small portion of the team and give them the new rules. Give them permission to fail. Let them complete a cycle and report back on what went well and what went poorly. You can learn a lot of valuable lessons on a very small scale. A pilot program gives you a chance to test and fine tune your cool new ideas. Don’t pass up using such a powerful tool if you can help it.
Take small bites
Once you get the feedback from your pilot project find a way to implement it in short phases in your team. If you aren’t getting feedback about how you are doing at least once a month you are in trouble. A week long feedback loop is probably close to ideal. Don’t bite off more than you can chew. Once your team gets used to the new system (it takes six weeks or more to form a new habit) you can ease off on the feedback loop frequency. Make sure everyone still knows what success is and can self measure if you do cut back on the feedback. Taking small bites also means not trying to change too much as once. In sports like golf of tennis players often work on their swing. They will take it apart and fix one aspect at a time. A side effect of perfecting your backswing is usually that your whole game goes downhill while you are learning. This is normal and will happen whenever you change something at work too! Factor in time and resources to “take the hit” for making improvements. You will see a short term decline for long term results.
Be retrospective often
Plan in time to ask and effective answer how you are doing. This should be in your framework. Be critical and ask if the changes you are making are having the desired effect. Remember that things may go downhill for a while until people can “put their game back together.” Make sure you are being focused and you take advantage of the flexibility in your framework. Ask what’s going well, and what’s not. Make small course corrections. If you make a small correction once a week, you will get your team heading the right direction without overshooting. If you overcompensate every week, you will never get on course and you will add a lot of chaos to your work.
Don’t just Think. Do.
The Think System is a sham. Make sure you don’t fall for it. Software teams do it all the time. They say they are going to be “agile” or “quality focused” or “security champions” but they don’t have a solid plan to backup their slogan. When you want to change the way you work, make sure you have a good transition plan.
Don’t fall for the flim-flam man!