Thoughts on motivation
One of the big challenges of being a Scrum Product Owner (or boss, or trainer, or parent) is motivating people to take responsibility for doing things. Telling them what to do, and how to do it, never really works, because there is no identification with the work to be done that inspires people to take responsibility for getting it done.
One of the ways I motivate my team is by clearly defining what I want and why I want it, and leaving out the rest. Geeks love puzzles and riddles, and want to figure out the solution to problems by themselves. By telling them what I want and why I want it, but not telling them how to do it, I’m giving them a problem, which is up to them to solve.
“Never tell people how to do things. Tell them what to do and they will surprise you with their ingenuity.” George S. Patton
By strictly separating the what and the why from the how, an interesting structure appears. Take a look at this.
Imagine that this is your company, existing somewhere in the world.
At the top level, what you want is to earn money (unless you’re a charity). The reasons why you want to earn money are left as an exercise to the reader. How do you earn that money? Maybe you decide to earn it by bringing a product out on the market that’s so good/cool/interesting that people want to buy it, i.e., give you money for it.
Here’s the interesting point. At the next lower level, the how becomes the what! Looking at this level, what do you want to do? You want to bring a product out on the market that’s so good/cool/interesting that people want to buy it, i.e., give you money for it. So, how do you do that? You do it by defining a bunch of features that people like, and then implementing those features.
At the next lower level, what you want to do is define a bunch of features that people like, and then implement those features. How do you go about getting that done? Well, for most of the people reading this article, the solution would be to write stories/requirements, put them in a backlog, and prioritise them, before starting to implement them.
At the next lower level, you have a bunch of prioritised stories that need to be implemented. How do you do that? You do that by breaking them down into tasks, and implementing the individual tasks.
At the next lower level, what you want to do is implement tasks. How do you do that? The smart way would be to start doing some eXtreme Programming, writing test and then code, until the tasks are done.
At the next lower level, you want to write tests and code. How do you do that?
What you see here is that at every level, the how becomes the what for the next lower level. The spiral/helix that evolves is the screw that holds your organisation together.
There are a number of very interesting conclusions and thoughts that pop up once you accept this basic hypothesis, and I’ll get around to writing about them in my next post.