Is There Really a Problem or Are You Creating One?
I’ve had this post sitting in draft for about half a year now. Figured it’s time to publish it now that it’s new and improved with 80% more insights!
Original Post:
A couple of years ago I was talking to Don Gray about “seeing the train wreck” in advance of it happening. By this, I mean it can be hard for managers to take an objective look at what’s really going on in their organization. We were talking about observations we made while at client sites that seem to be completely oblivious to the people working there.
Why is that?
Are organizations blind? Am I imagining things? Read more
What Does Lean, Agile or Scrum Really Mean?
A couple of years ago I posted about “process labels” and why I don’t think they matter. I suppose you could interpret “labels” as “brand” and you can call those brands Scrum, Kanban, Lean or what-have-you. I had a light-bulb moment (re-affirming moment?) tonight when Benjamin Mitchell articulated this statement when describing his interpretation of “Lean”:
“I have learned to think in my own context” Of course he admitted that the marketing of that term isn’t so great when you’re a consultant, however, the heart of that statement is what really matters over trying to put a label on what process discipline you’re using.
What I’ve seemed to notice more is that people inside the “community” (whether that be agile, lean, scrum or whatever) spend a great deal of time trying to refine their brands and labels and I am wondering if people outside these communities really care about (or even understand) the brand or label. We in the community make assumptions about how our customers feel about our brand and worry about language, marketing and other stuff that sounds an aweful lot like making product decisions from an ivory tower without getting fast feedback from our customers to me.
Let me explain that a bit more.
Organizations may look to “Agile” to help them with a problem. They might not understand the problem, but they know enough to know that they want or need something to change. So people in the organization will talk to colleagues or friends or other industry people they know. These people they talk to may say things like “hey, we started Agile-ing a couple of years ago and wow, the magic I tells ya! We started Scrumming our products and holy cow is it awesome!” Ok, maybe that was not exactly how the conversation would go, but I think you get the idea. The organization looking for help sees that a certain process worked in another company from a trusted source of information so naturally, it’ll work for them.
So this organization will start doing Scrum. Then they’ll realize it didn’t work, or at least it didn’t get them the outcomes they thought it would. Then they’ll wonder if they’re doing Scrum right. Then they’ll find out they are doing Scrum-but. Then they’ll be confused. All the while the focus has shifted from trying to figure out why they needed to change something and the focus will be put on how to execute the process (in this case Scrum) the right way so it’ll work.
They may try Kanban and see how that goes or they may try Lean or Crystal or <insert process here> or they may chose to just give up and go back to the status quo or do nothing.
I am going to tell you the only guaranteed, sure-fire way to get better results within your business.
- Start trolling the Yahoo or Google message boards of various process disciplines. Linked In is a good place to start too. Post thoughts about your problems and get some free advice.
- Filter that information and decide on which process discipline makes the most sense to start with
- Get involved in that process discipline’s community. That means find local user groups, go to conferences and spend some time and effort to make a well-informed choice. Of course balance how long it takes to make the choice. Chances are you’ll get analysis paralysis if you spend too much time.
- Hire a consultant (and I’m not one anymore so I’m not plugging myself!)
- Give’er! Get started while understanding that the focus is NOT on the process but instead the outcomes you expect to get. Use what you learned in the first 3 steps to teach yourself and your organization how to learn within your context.
While I did use numbering for these steps, they’re not really linear. My point is, educate yourself through the massive amounts of information and channels before you decide to make a change. Understand what problems you think you’re trying to solve, understand there’s probably more problems than you originally imagined and gather information and feedback from various sources to help you make a more informed decision.
So for the amount of time and effort people within the community spend on defining brands and putting labels on processes, are our customers finding any value in that or are we just confusing them with a bunch of BS that doesn’t matter to them? Are we the reason that focus seems to shift from solving business problems to following a process?
Seems simple to me, the organizations and people who are content with mediocrity will pursue quick fixes and focus on doing a <insert process discipline here> right.
The organizations and people that want to improve will actively seek out solutions and labels won’t matter to them. They ‘ll look at multiple process disciplines and they’ll get actively involved in one or many communities and they’ll learn how to think in their own context for how best to apply the right practice(s).
“Learn how to think in your own context” – It doesn’t get much simpler than that.
Why Agile is So Hard
The building we work in has shared bathrooms that are locked. We used to have 2 keys to the men’s washroom hanging on push-pins next to the door so we don’t have to cut a key for every person in the office or for guests. Recently some ladies joined our company so naturally we had a copy of the women’s washroom created. 3 keys, 2 hooks. Sounds like a problem.
Well, one key has a really big-ass keychain and people would put 2 keys on one push-pin and more often than not while putting the key back or taking it off, they other key on the same pushpin would fall off. Being the nerd I am, I watched this behaviour for a few days. Sometimes a key would fall on the floor, sometimes not however status quo was very much apparent. It’s just a key after all, no big deal just bending down to pick it up if it falls.
I decided to introduce a system change. I added another push-pin. 3 keys, 3 hooks. A funny thing happened. Most people still put 2 keys on one hook and didn’t use the new hook that is pretty obvious to spot. I decided to experiment further. I’d always put the 3rd key on the 3rd hook and check and see how often the keys ended up being doubled-up on one hook. Most people still doubled-up keys.
What’s the point of this nonsense? People are generally happy with the status quo. As I’m typing this, someone came back and doubled-up the keys. He fumbled with it, but it didn’t fall on the floor. Going back to the premise of why Agile is so hard, if this simple of a system change doesn’t change behaviour, can you really expect your organization is going to leap at the opportunity and embrace the disruption to the status quo?
This leads me to another test. What’ll happen if I remove 2 hooks leaving only 1? What happens if I remove all hooks and leave the keys on the floor? Perhaps my sensitivity is getting the best of me, however it’s little cues and behaviour that can speak volumes about your organizations culture. What’s going to happen when you introduce a new process that makes employees feel less safe? What’s going to happen when Agile processes expose problems in your organization? What’s going to happen when you attempt to adopt a particular Agile practice that requires more complex behaviour change?
