Could Daniel Pink have it wrong? PART 1

Provocative title, eh?  If you’ve read Daniel Pink’s book “Drive” you’ve been introduced to one of the many theories of motivation.  If you haven’t read it, buy the book for goodness sakes.  It’s great! If you need more convincing, see the youtube video it’s wonderful.

There are a lot of motivational theories.  You can look at them in Wikipedia.  Daniel Pink seems to base his work on the self-determination theory of motivation applied to knowledge workers.  To sum “Drive” up he says that motivation in knowledge work is driven by autonomy, meaning, and mastery. 

Of course there’s a lot of supporting information in the book and video, but he refutes the idea that the carrot and the stick technique of motivation works for knowledge workers. I think he’s right.   The problem comes when people don’t pay close attention to what these motivational factors really mean or the prerequisites for these motivational factors to kick in.

Let’s look at very first assumption that Mr. Pink makes in the beginning of the book:  once money is taken off the table as a motivator then autonomy, meaning, and mastery come into play.  I’ve seen companies ignore the pay issue completely and jump right into the trilogy of motivators, we don’t have to pay as much as the next company.  It doesn’t work that way, just read about Motivation Crowd Theory.  If an organization does anything less than removing money as a motivator, the self-determination theory of motivation doesn’t work: other motivational theories will explain a person’s behavior. Lack of adequate pay or even small raises leads to a loss in the feeling of meaning and can directly lead to employee moral issues.

Even if you’ve got the foundation set, there are glaring ways to misinterpret the application of autonomy, meaning, and mastery.  In part two of this blog, I’ll be pointing out where the three factors can be used in such a way as to have the opposite of positive motivation.

Think Backwards to Split Stories

Splitting stories through vertical slicing is something you’ve probably heard and are practicing.  Now you’re probably thinking “I’ve done that before, this is simple.”  If that were the case, many of the agile consultants would be out of the job.  It’s harder than you think to have the discipline to slice features up.  It’s also tough to be disciplined and make sure that ever iteration has multiple features in the iteration. 

Often times iterations become boxes of features – when planning the sprint the question asked is “what can you deliver in 2 weeks” as opposed to “what can you grow in 2 weeks”.  Creating two week feature boxes is encouraged by a lot of authors that talk about release themes – people misunderstand that to mean that sprints should be themed.  When push comes to shove the sprint is extended to meet the completion of the theme.  Sound familiar? 

Thinking in terms of a pull system rather than ‘pushing’ work into a sprint will go a long way.  I’ve had students that said their software is extremely complex and nothing can be produced for weeks on end.  Consider this – do you compile and check out what the code is doing only after the end of weeks – I hope not.

A 2 week sprint is 2 weeks of time, not an estimate of what the team thinks can be completed in 2 weeks which is then extended to accommodate the estimated features.  You’ve got to think backwards, that will help quite a bit.

End of the line for a coach

I’ve been a consultant for quite a number of years, in both technical and managerial roles.  One thing I’ve noticed about being a business coach – the end of the engagement is very different technical engagements. 

When you’re a developer and the end of the engagement comes, it’s usually because some huge project is finishing up.  There’s a celebration and a sense of finality.  There’s usually a concrete deliverable and the project is moving into a new phase of routine operational maintenance.  It’s over and, hurray, you’ve done it.

When you’re a coach the end of the engagement is quite different.  The client no longer relies on you for understanding or your expertise.  It’s down right sad.  You begin to be less and less important until they come to you and say that they don’t need you any more.  Hopefully they end with a retainer for a certain period.  You don’t go out in a blaze of glory but tend to trickle out.  So sad.

I must say though, knowing that the client doesn’t need me any more is actually satisfying, despite knowing that I won’t be working with the teams any more.  Human nature makes it difficult to look at the positive in such a situation – the end of an era – but if you’re even in this situation, just consider where they were when you started.  They’re probably better off.

Interview with Ken Schwaber Part 5

Part 5: 

Evidence Based Managment

Coming this spring, Better Software magazine will publish an interview with Ken Schwaber that I conducted.  As part of my blog, I will publish a number of excerpts.  Here is part 5 of 5, the last in the series.  Enjoy.

KS - I think some managers are not going to welcome this approach because they are only responsible for explaining why projects didn’t deliver on time and being able to blame someone else. This is going to be really, really scary to a good number of managers who aren’t very confident in what they do. 

I think that when they all start looking at the metrics and start seeing what is really happening, it is going to be pretty interesting. One of the sneaky things in EBM and the agility path is the agility index (a rollup of the metrics).  This is the easiest metric to compare (between organizations) as a trend within your organization and that’s pretty scary right there.  We also gather more data for comparisons between like organizations in the same industry sector.  All you need to do is put out a report out with inter-corporate metrics and have it show up in Forester and Gartner and other newspapers and you’ll start seeing a lot of interesting discussions.

The idea is appealing however once you start using it and it starts coming back on you that you have to do something to improve the organization.  And for EBM that’s the hook; that’s the trick that’s in it. 

Interview with Ken Schwaber Part 4

Part 4: 

Next big evolution of Scrum

Coming this spring, Better Software magazine will publish an interview with Ken Schwaber that I conducted.  As part of my blog, I will publish a number of excerpts.  Here is part 4 of 5.  Enjoy.

KS - For us I think the next big evolution is evidence based management (EBM) - to show the value of doing work one way or another.  Not only for businesses to see the value but if they don’t act on the value it should be clear that they are doing things that are not beneficial to their corporation.

Evidence based management just says "here’s some metrics we can use to see how we are doing" and these are things which I could take right into my management and show them.  It is appealing because is doesn’t even start with the idea of change.  It simply starts with the thought that it’s really a good idea to try to measure what is going on. Its been a problem that management only sees IT as an expense that doesn’t provide much value.  If we measure business value, we suddenly change the way we interact with upper management.  They think "this interesting, why don’t we measure IT in terms of value and see how much value is actually being provided".  Now of course you can’t do that in the absolute sense, you can’t say "oh this is 17.4 oz of value", but you can start setting baselines so you can compare trends and predict based on our actions what will happening over time. 

Another problem is that agility has not been measured. Jeff and I seen over and over again a company getting really, really, good at agile and their management believing it is not doing any good.  The idea in EBM is that if you have measurements, just like scales have measurements and manufacturing has measurements, you can see the effects of change and agile.  You bring to management a new way to tell if they are continuing to get better or worse. 

I’m hoping that between two thrusts this will work.  One thrust is that management hasn’t measured IT or product development - ever. They have been under pressure to have a way of measuring so they can report to their CEO and EBM gives them an answer. The second thrust is that the measurements can spotlight their actions and hold management accountable to some degree of performance in the same way the rest of the organization is.  This raises transparency at the management level just like we have at the development level.