The Cast of Characters You Will Meet in your Agile Customer Journey

• The derailer
• The snake oil salesman
• The bargainer
• The visionary
• The frustrated individual whose talent is being wasted
• The fiefdom warrior
• The lazy bugger who doesn't want to put any effort into bringing their business to life

What books to read and why to formulate your own method

My challenge is to create a planning and tracking system for an agency with many customers and projects in varying states, on-going support and maintenance issues, and fixed deadlines. Here are some observations:

1. Dates are fixed, but projects appear to be 1-3 months behind
2. Different types of work are not timeboxed - there are no boundary conditions on work activities to create focus
3. As a small company, people have to wear many hats, but some hats work better than others. This has meant that planning has taken a back seat to selling and doing, which makes sense in this environment.

In creating a system, I've suggested reading:

Agile Project Management With Scrum - some of the ideas don't really carry in the fixed-date scenario, but this book does a great job of showing the effectiveness of boundary conditions, the requirement for creativity and improvisation in real life (there is no silver bullet), and the value of empiricism: observe what is happening and make new decisions based on this reality.


Agile Estimating and Planning - the most useful hands-on guide

Extreme Programming Explained - embrace change and set yourself up to successfully live with and manage change

Storyboard Art

Dudes are hardcore about their planning/tracking boards.

http://www.flickr.com/photos/agileinaction/
http://www.think-box.co.uk/blog/2008/05/simplified-planning-board.html

It's not the shoes, Mars...

Great article on the idea of personal agility. People on a team need to feel a personal sense of responsibility to their projects. More interestingly, they need a certain amount of emotional intelligence and personal development to be effective leaders. Traditional carrots and sticks as we know only work for some people.

The best performers at my last job were people who had a carrot bigger than the paycheck, e.g. they needed a green card, or people who just loved the thrill of chasing down the solution to the difficult problem, regardless of the impact this problem might be having. Anyone who did not have these characteristics generally failed to get promoted on my last team.

It looked like they only promoted people who worked 60-80+ hours a week, but it's interesting to think about why those people were willing to work those hours on problems that were the result of what I would characterize as management shortcomings, when the majority of the team was not. It is because the majority of the team had no incentive to work on things they knew were dumb, things that had a small impact on customers, or things that were just painful to work on.

In other words, personal agility is not a new way of commanding and controlling. It is a paradigmatic shift where management must lead by example, show and not tell, and instilling a sense of ownership (and developing a consequent sense of leadership). This is not something you can do by brute force, it is, like house music, something you need to feel. "If you don't feel the stirring in your heart after the first few bars of a tango, go find something else to do". (Rough paraphrase from 'La Cafe de los Mastros').

Design for Today's Problems, Not Tomorrow's

p. 110 of Extreme Programming.

"The traditional strategy for reducing the cost of software over time is to reduce the probability and cost of rework. XP goes exactly backwards. Rather than reduce the frequency of rework, XP revels in rework...
"The key is that risk is money just as much as time is money. If you put in a design feature today and you use it tomorrow, you win,because you pay less to put it in today.... However... If there is enough uncertainty, the value of the option of waiting is high enough that you would be better off waiting.
"Design isn't free. another aspect of this situation is that when you put more design in today, you increase the overhead of the system. There is more to test, more to understand, more to explain. So every day you don't just pay interest on the money you spent, you also pay a little design tax. With this in mind, the difference in today's investment and tomorrow's investment can be much greater and it is still a good idea to design tomorrow for tomorrow's problems.
"As if this weren't enough, the killer is risk.... You can't just evaluate the cost of something that happens tomorrow. You also have to evaluate the probability of it happening....
"So, the cost of making a design decision today is the cost of making the decision plus the interest we pay on that money plus the inertia it adds to the system [emph. added]. The benefit of making a design decision today is the expected value of the decision being profitably used in the future.
"If the cost of today's decision is high, and the probability of its being right is low, and the probability of knowing a better way tomorrow is high, and the cost of putting in the design tomorrow is low, then we can conclude that we should never make a design decision today if we don't need it today."

Example: From Chapter 3
"Suppose you're programming merrily along and you see that you could add a feature that would cost you $10. you figure the ROI on this feature (its net present value or NPV) is somewhere around $15. So the NPV of adding this feature is $5.
"Suppose you knew in your heart that it wasn't clear at all how much this new feature would be worth -- it was just your guess, not something you really knew was worth $15 to the customer. In fact, you figure that its value to the customer could vary as much as 100% from your estimate. Suppose further that it would still cost you about $10 to add that feature one year from now.
"What would be the value of the strategy of just waiting, of not implementing the feature now? Well, at the usual interest rates of about 5%, the options theory calculator cranks out a value of $7.87.
"The option of waiting is worth more than the value (NPV = $5) of investing now to add the feature. Why? With that much uncertainty, the feature certainly might be much more valuable to the customer, in which case you're no worse off waiting than you would have been by implementing it now. Or it could be worth zilch--in which case you've saved the trouble of a worthless exercise.
"In the jargon of trading, options 'eliminate downside risk'".

Plan for priorities, not development

From Extreme Programming Explained: "Planning for priorities vs. planning for development -- Ber aware of the purposes of planning. Planning so the customer can establish priorities needs much less detail to be valuable than planning for implementation, where you need specific test cases."

Simple Story Template

Great post on a simple story template from Mike Cohn. "As a , I want so that ". Simple constraint.