Agile Adoption Patterns

This bit of news is a little late, but hopefully still useful to someone out there who's interested in introducing agile practices to their project.

A few months ago, Addison-Wesley released a great resource for teams and coaches relatively new to agile methods: Agile Adoption Patterns by Amr Elssamadisy. Unlike much of the Agile literature, this book doesn't just tell you what the end of the long road to agility looks like. It tells you how to get there, from where you are now. This book won't solve any problems for you, but it'll help you recognize the problems you'll face, and it'll arm you with some tools to deal with them with a minimum of pain and frustration.

I've reviewed the book for InfoQ, so you can read more of my thoughts on it here.

Making Documents Lean

I was going to write a whole post about lean documents, but while doing my research, I quickly came across this article by Scott Ambler over at AgileModeling.com. It's a long read, so if you're short on time, read the Critical Points and Why Do People Document? sections. The former makes a great print-out list for your cubicle wall. The latter is more politically sensitive, so I wouldn't post it in public (since it's probably only relevant if you have a traditional, political workplace), but it is a great resource if you're interested in trying to introduce agile ideas and want to avoid resistance and backlash.

If you're really short on time, here are some highlights:

• The fundamental issue is communication, not documentation.
• Agilists write documentation if that's the best way to achieve the relevant goals, but there often proves to be better ways to achieve those goals than writing static documentation.
• Document stable things, not speculative things.
• Take an evolutionary approach to documentation development, seeking and then acting on feedback on a regular basis.
• Prefer executable work products such as customer tests and developer tests over static work products such as plain old documentation (POD).
• You should understand the total cost of ownership (TCO) for a document, and someone must explicitly choose to make that investment.
• Well-written documentation supports organizational memory effectively, but is a poor way to communicate during a project.
• Documentation should be concise: overviews/roadmaps are generally preferred over detailed documentation.
• With high quality source code and a test suite to back it up you need a lot less system documentation.
• The benefit of having documentation must be greater than the cost of creating and maintaining it.
• Ask whether you NEED the documentation, not whether you want it.
• The investment in system documentation is a business decision, not a technical one.

Risk Management Lessons Learned From Texas Hold 'Em

A couple years ago, I was an avid Texas Hold 'Em player. For about a year, I played 4 tables at a time online for a few hours a day, I read poker books, and I made enough money to pay my rent. (Because you're playing against other players rather than against a casino, it's actually possible to make money at poker.) Eventually it started feeling like a grind instead of a hobby, and I gave up on the game to spend more of my spare time on software-related pursuits.

These days I just play occasionally for fun, but I'm glad I put so much thought and energy into the game for a while. Hold 'em is a true meritocracy; you will only win in the long term if you are better than your opponents. There is no vagueness to the result. You either quickly learn to plug the holes in your game or you lose. Because it's a non-trivial undertaking but the results are so unavoidable, there are several life lessons that the game illustrates quite well.

Here are a few of my favorite lessons from hold 'em as they apply to risk management in software development projects:

Understand expected value, and use it!

Players who don't understand the concept of expected value don't generally do well at hold 'em (or any form of gambling, for that matter) in the long term. If you understand your chances of winning, the cost of losing, and the reward for winning, the decision of whether to call a bet or fold becomes purely mathematical. If you don't, the best you can do is guess. Often, you'll guess wrong.

Often project managers and sponsors usually don't know how much a project will really cost them or how much value they will gain from it. Even if cost & benefit projections are available or relatively easy to calculate, no one calculates the expected value.

I know of one company that began calculating the expected value (or ROI) of projects and realized they had signed a deal with a development cost ten times higher than they would get paid for it. Obviously projects like this have a negative expectation, but they get undertaken surprisingly often if no one checks the numbers.

The same analysis can (and should) be applied at a more granular level. It's old news that the majority of features in an average software product are rarely or never used. I have a suspicion that these features sneak into software products because no one bothers to think about their expected values.

One more thing: expected values aren't just for deciding whether to play a hand or not. You can (and should) also use them to decide whether to stay in a hand. We all know perfect project cost estimation is impossible, so continuously revisit your estimates once you have a few iterations under your belt. If the expected value of a project or feature changes, don't ignore that information! That brings us to lesson number 2:

Don't throw good money after bad.

The biggest mistake most players make is putting more money into a pot when they have very good reason to believe they are going to lose. Why would someone do this? They've crossed their threshold of pain. In other words, it's likely they've already lost $100, but there's some slim chance they haven't. The psychological difference between losing $100 and $200 is minimal, but the psychological difference between losing $100 and winning a few hundred is huge. Unfortunately, when you make decisions based on the emotional distance between different outcomes, rather than based on the statistical likelihood of those outcomes, you'll get yourself in trouble.

The same thing happens on software projects. Even when it is clear a project is a train wreck, if enough money has already gone into it, people will get really good at coming up with reasons to continue putting money into it. Don't be one of them. The fact that you made bad decisions is not a good reason to continue making bad decisions.

- - -

The interesting thing about these two lessons is that they aren't by any means earth-shattering; they're basic common sense. They basically boil down to this: only make decisions that make financial sense. After reading this article, you may find yourself thinking "Well, duh!"

It's tempting to dismiss the above lessons for that reason. We'd all like to think we are above irrational behavior, so we don't need to be reminded of such common-sense lessons. In poker at least, that's clearly not the case. The biggest challenge for would-be poker pros isn't knowing when to call, when to fold, when to raise; it's having the self-discipline to fold when you know you should. Optimism, pride, and desperate hope drive them to keep putting money into a pot they're unlikely to win.

I think the same thing happens in software development. Everyone realizes that they shouldn't pay twice as much to develop a product as they will be paid for it. The problem is that we don't always have to self-discipline to stop, measure both sides of the equation, and make the hard decisions based on the results.