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.

Lightbulb experience

I had a lightbulb experience a few years ago  when I took a careful look at the agile values and tried to compare them to the traditional business values.  There really was no traditional set of values, so I had to construct my own version. 

I came up with: 

1) We develop processes and tools to standardize our interaction and maximize individuals’ productivity.

 2) All of our software has comprehensive documentation so that anyone can understand it quickly and easily.

 3) In order lock down a plan and cost for project, we enter contract negotiation with our customers.

 4) We follow a plan in order to minimize and control change.

 All of these are the exact opposite of the agile manifesto.  I now understood that the traditional techniques of developing software were based on control and came from a domain like construction, where the exact layout of the product under construction could be fully understood before beginning.  Software changes too quickly and it usually is a matter of “I’ll know it when I see it” for the end user.  

I began to see that a lot of what we do these days is a waste:  determining full requirements at the very beginning when they will change after a short time, estimating everything to the lowest level of detail at the beginning when the least amount was known about the project, putting together one-size-fits-all methods and then tailoring them down to the project at hand.  It’s all too much to just develop software.

I now use agile for software, running businesses, writing, creating all sorts of non-software related products.  It’s great.

Agile Contract Models

Using the agile software development process in conjunction with client contracting is challenging due to the emergent nature of the detailed plan and product. Traditional contracts, used to bid or scope an agile development effort can subvert project execution and causes both parties miss the potential benefits of agile development since a full understanding of the client needs is assumed in a contract. 

Fortunately others have come before us who have tried different contracting models.

Some of the typical models of contracts are listed in the following table:

Contract Name	Description
Capped T&M	Use time and material  but cap the cost based on effort or scope.  Sets up a conflict with the customer as this model assumes all scope is known.
Fixed Bid	Price and scope is fixed.  Quality is the only variable – which is not good.  Assumes all scope is known.
Target Cost	Mutually target a cost, if final product cost is less, split the savings.  If final product cost exceeds target, share the extra cost.  Can be a tough sell and setting the target cost is a challenge.
Target ROI	Estimate work for effort and value to determine each piece’s ROI.  When the summation of effort and value for a sprint reaches a certain ROI, enter a ‘work wrap up’ sprint and end the project.
Contract by story point	Work is broken down into small stories and estimated by story points.  Fixed bid work is based on number of story points.  As the project progresses, scope is fixed but stories can be exchanged as long as they are not currently in a sprint.
Money for Nothing Changes For Free	This is a combination of target ROI and contract by story point.  The work is targeted toward a certain ROI and stories of the same size can be exchanged as long as they haven’t started yet.
Contract by Sprint	Each sprint is a mini project.  Could be contract by several sprints. Client can cancel after any given sprint.

* A good blog on agile contracts from another scrum.org coach:

http://scrumology.com/an-overview-of-agile-contracts/

The best contracts for agile use a variable scope and shared risk approach.  Of those, Target ROI, Contract by Story Point, and Money for Nothing Changes for Free are the most popular and effective.  Here’s a description of each.

Target ROI

Target ROI works when customers want fixed price estimates for the entire contract up front but the work has not been fully .  The Agile contract allows termination of the contract when the value of features drops below a certain ROI criteria.  It can be effective for delivering high value to the customer for a reasonable price and building trust.  The ROI value can be based on revenue or using other techniques. 

Contract by Story Point

Contract by story point works can well when the client wants a fixed bid based on work that isn’t very solidly defined or is emergent.  The estimates determined based on high level story points and, as work is broken down, stories of the same size can be substituted as long as they are not within a sprint.  This technique works well when the client doesn’t know what they want or there is a large risk of discovery.  It can be risky though for both parties considering team velocity comes into play when billing the project.  Also story points can become a sticking point in client-provider relationships when the provider re-estimates detailed stories.

Money for nothing, changes for free

“Money for nothing, changes for free” can be though of as combination of Target ROI, Contract by Story Points, and Target Cost.  The following elements of each are combined:

·      Contract by Story Points - the estimates determined based on high level story points and, as work is broken down, stories of the same size can be substituted as long as they are not within a sprint. 

·      Target ROI - Delivery is based on a target ROI, and project payment is based on a mutual price

·      Target Cost - Mutually determine target a cost for a certain ROI, if the ROI is reached and the final product cost is less, split the savings.  If ROI is reached and the final product cost exceeds target, share the extra cost. 

This is a complicated contract but the risk is shared, the delivered product is malleable, and success is based on what really matters – value. If the business value is not realized on a particular cost target, then there should be a fall-back to time & material.

 “Money for nothing, changes for free” contract turns the advantages of the agile development processes into a competitive advantage by prioritizing and delivering business value incrementally and allowing change when something is learned.

Agile Adoption Maturity Levels

I recently had a thought that I'd like to share with others regarding agile thinking.  

I believe that agile maturity can be thought of in three levels:

1) Level 1 is where agile is thought of as a way to allow change through adaption and inspection.

2) Level 2 sees agile as proactive in it's ability to change:  it not only allows change, but proactively positions the organization to expect and anticipate changes, in part by actively deferring constraining commitments.

3) The most mature agile organizations must seek out change, not just passively await it.  The example is organizations that foster change through techniques such as hack-a-thons or innovation days.

I've come to see these levels by watching multiple companies introduce Scrum and the supporting agile mindset without seeing product innovation.  They simply wander to the same general destination as they always have, minimizing risk and reducing waste, the only innovation being in the minor details. That’s a pity, but often the best you can hope for until the organization matures.

These levels are not meant to relate to Shu-Ha-Ri nor the Dreyfus model of skill acquisition.  It’s just way of progressing a company to higher levels of empirical processes based on their attitudes of change.  It works for me.

Have you experienced the same?  

Product owners?

What are some of the things to look for when starting up an agile team and choosing the product owner?

-->

A good product owner must have:

Knowledge

·      Knows enough about the product to create and maintain a backlog – can write reasonable requirements and eventually stories.

·      Knows enough about the product and it’s context to conveys the vision and goals of the project and each sprint.

·      Understands the needs of the customer.

·      Knows enough about the technology to make reasonable decisions.

Authority

·      Can carry through the result of any tough decisions.

·      Owns the product success (or failure), so can prioritize the backlog and eliminate stories if they’re not high value.

·      Represents the customer, interfaces and engages the customer.

·      Can change the course of the project at the end of every Sprint.

·      Can terminate a Sprint if he/she determines such action is required.

·      Has the recognition to communicate status externally.

Availability

·      Has the time to work on the product backlog, despite other responsibilities.

·      Can actively participate in the daily Scrums, Sprint Planning Meetings and Sprint Reviews and Retrospectives.

·      Has enough time to quickly respond to questions (that day) and sit with the development team when needed.

·      Actively inspects the product progress at the end of every Sprint and has complete authority to accept or reject work done.

Aptitude

·      Able to resist the temptation to micromanage.

·      Not be afraid to make tough decisions.

·      Able to work in a team environment.

·      Focused, proactive, and engaged in the product.   

·      Good negotiator.

·      Deeply interested in helping the team be successful.

·      A “People Person” with patience.

·      Willing to learn and flexible enough to deal with the changes of agile.