My Dad was a school teacher for 25 years. For several of those years, he had the same thing for lunch: a plain cheese sandwich. My Mom enjoyed getting all of us ready for school in the morning and would make us our lunches, put them in brown paper bags, and label each of them. My sister and I were finicky eaters at best, constantly changing our minds, or feeling jealous of classmates who had “cooler” lunches (usually junk food.) My Dad stuck to what he wanted, and it made my Mom’s job easy. She’d make him a plain cheese sandwich, and he happily took it to work.
Then one fateful day he snapped.
He told my Mom he never wanted to see a cheese sandwich ever again because he was sick of them. She was a bit shocked at first, but we all had a big laugh about it, since it had only taken him years of having the same thing for lunch every working day to get tired of it. Most of us have far less patience and are far more discriminating in our tastes and a need for variety.
I’ve worked for years as a consultant helping software development teams, and I see their versions of the cheese sandwich constantly.
Software development team’s version of the cheese sandwich tends to be process-related. Teams do the same things over and over because that’s what they are used to, because they are dogmatic in their alignment with a process ideal, or because it seems that is what everyone else is doing.
A few years ago, I was helping David Hussman with a book project that eventually became a Pragmatic Press production: Cutting an Agile Groove: The Live Sessions. As I looked over a collection of David’s writings, three key phases of team productivity came to mind:
- Getting Started
- Getting Productive
- Staying Productive
Most teams I have observed are pretty good at getting started and getting productive, but a huge majority have a lot of trouble staying productive. Many teams plateau and even drop off over the life of a project, and especially when they work on projects together year after year. A big part of why they plateau is because they don’t change up their processes and practices, and they get bored.
If the team isn’t willing to change, they won’t. My Mom tried for years to suggest things to mix it up. My Dad stuck with the cheese sandwich. However, once he made up his mind to change, he was ready for it, and he went for it. You can’t force change on people, you can only really support it. It can be frustrating to work with a team that has obvious problems, yet they refuse to look at simple, proven solutions and won’t try anything new.
After slavishly sticking to one thing for so long, Dad got rid of it altogether. Sometimes this is worthwhile, but on software teams this can be overkill. I see this with software development teams all the time – the old way is wrong, throw it all away! This can be unfortunate. There might be good things that are getting thrown aside. What you were doing before wasn’t necessarily all wrong, you are just tired of it and enamoured with something new. Or, it is still a good practice, it just doesn’t work for your team anymore.
Recently, a team I was working with decided to get rid of using a wiki. They had process dysfunction, and saw a fantastic presentation by Ralph Boden “Changing the Laws of Engineering with GitHub Pull Requests” that challenged the usefulness of wikis. The team Ralph was working on got rid of wikis, and had some compelling reasons for doing so. Instead of using this presentation as an example of what worked for one team, the take away was that wikis were bad and now have no place on a software development team. It turned out that for this team, the wiki was a useful tool and throwing it away altogether was premature. We see this a lot in software development communities, often in the form of “___X___ is dead!” pronouncements. No, X isn’t dead, it just doesn’t work for you anymore, so don’t discourage other teams from doing X. Just because your team doesn’t like cheese sandwiches anymore doesn’t give you the right to disparage cheese sandwiches and anyone who enjoys them.
Software development is complex and difficult. It is a huge challenge to get a team together, get productive, stay productive, and sustain this over several product releases. The lesson in the cheese sandwich is to not stick with one process or practice for too long. Just like with food, software processes require variety, serve different needs for different people, have different requirements and restrictions, and will get stale over time.
See Things Change and So Should Processes for more on this theme.
4 thoughts on “Who Moved My Cheese Sandwich?”
Thanks for interesting post.
I like the takeaway “The lesson in the cheese sandwich is to not stick with one process or practice for too long”.
However, I have two concerns:
1) How long is considered as “too long”?
2) How do we know if the team has hit the plateau?
Good question. It is important to understand that there are no hard and fast rules about this. To answer both of your questions, these are signs I look for:
Susan Olsen, who played six year old Cindy on the Brady Bunch hated her character. In one episode, the script called for her to say “Mommy, why do I always get PB&J sandwiches?”
“But I thought you loved them.”
“Oh yeah! That’s right!”
She stormed into the producer’s office as best as a child actress could, and demanded that they stop making her character so stupid.
Was Cindy really that stupid or was she a bit like Kohl’s father?
Interesting story, thanks for sharing. I think amusing food stories are a pretty common family dynamic. Speaking of intelligence, my father is extremely intelligent – I don’t feel like I hold a candle to him in many ways. Sometimes really smart people are also quirky.