Dan Pink, formerly Al Gore’s speechwriter, delivered a brilliant speech at TED in London earlier this year, called “The Surprising Science of Motivation.”  In this talk he lays out the scientific case against incentives as a business motivator.  As an unreprentant capitalist, this got my attention.  Almost every job I’ve worked at I’ve either been an entreprenuer or I’ve worked with much of my compensation “at risk.”

Pink makes the point that in jobs which require creative, autonomous thinking incentives don’t work.  In fact they hurt productivity.  Further, Pink provides evidence that science has known this to be true for almost fifty years–it’s just that businesses haven’t woken up to it.  I want to tie this to the Agile programming movement, but first take a few minutes and listen to this short and brilliant presentation:

Agile programming methods have brought the “autonomy, mastery, purpose (AMP)” ideal to software programming.

The old method of software development—the “waterfall”– meant gathering a morass of heterogenous, detailed requirements and then “riding herd” on the software team as they marched for six months writing code almost always resulted in a huge rush of overtime development in the last month and delivery of a mediocre piece of software. This is still the method for large project software development in most shops, and it still governs Website development.

I joke with friends in the Internet strategy business that every Internet design firm has a four or five box methodology we walk out in every proposal. It usually goes something like this:

Or five boxes called “Inception, Inspiration, Initiation, Instantiation, and Installation.” You get the idea. For twenty years now it’s been a source of comfort to clients of mine. It shows them in four of five simple steps how we get from here to there. The problem is that it’s wrong, horribly wrong.

Here is an eternal truth about projects: you always see, understand and learn more about what you’re trying to accomplish as you go along. Often these new learnings result in important new ideas about how the project should turn out. There hasn’t been a Website project I’ve worked on in 20 years (yes, I go back to 1989) where the design wasn’t radically improved as we went along.

The problem was the four box waterfall. It made it expensive to go back and change things. The further you got into the four boxes the more costly it became to change anything. And almost without exception when we got to the last box the client would say something like, “Oh! You mean it works that way? I thought it was going to work this way! We have to have it this way!” This resulted in long hours of last minute coding and revisions.

Another problem inherent in the waterfall is that it’s much, much harder to create a completely workable 6-month project plan than a 2-week project plan. The 6-month project plan always results in horrifying discoveries like “we didn’t plan for that much content to be input,” or “we used up all the time and money we allotted for QA testing because the design stage ran long.”

Agile programming is built on short, iterative cycles that deliver completely functional code. That’s the central idea. The design team agrees with the business owner on what will get built in that cycle–a prototype, functional features, whatever they agree to deliver completely. It results in business owners getting what they want, which isn’t what they started out thinking they wanted. It’s something much better, with more effective solutions than first imagined. Software and design teams get what they want which is “autonomy, mastery, and purpose.” Sane work days. Better relationships with the business owner. More engagement from their internal clients. Better product.

Agile programming works creates a “product feature backlog” and the business owner and the programming team negotiate for what product features the team can completely design, build, test and deliver in a short period–say, one week. Agile delivers small increments of completely functional code. The business owner can add new product features, or request that features be changed, but its up to the programming team to figure out how to deliver the next piece of complete code. There it is–autonomy, mastery and purpose for the programming team, as well as the business owner, using Agile development.

I think Agile methods can be applied outside of software programming and Website design. I think they can–and should–be applied to strategic planning, business planning. I’m working on a business plan for a start-up right now and the Agile method has vastly improved the quality of what I’m working on. I agreed with the business owner to develop a business plan in three days, and I produced a ten page powerpoint as my deliverable. He took that and asked for one section to be blown out in detail. I wrote that in three days. He saw a new idea from that and asked for that section to be re-written to incorporate the new idea.

Both of us have autonomy, mastery and purpose. I work the way I want and the work is the result of my talents being fully engaged. Most of what I’ve learned in business I learned by working, not studying.

The risk of Agile is that you could wander hill and vale writing long strings of complete deliverables, but iterating and evolving away from the original business purpose, or any business purpose for that matter. The key is to focus on getting work finished. Finish a cycle, understand what you’ve learned, and measure the next step against the long-term business goal.

That may result in twenty or thirty boxes instead of four or five, but each one will be a well-defined and executed step towards bigger success than we imagined at the beginning.

Bookmark It