Thursday, July 30, 2009

Realistic About Risk: Software Development with Real Options

At QCON London 2008, Olav Maassen and Chris Matts gave a talk about Real Options. They started out with a quick exercise where the audience was divided up into teams and each team had to write down who they thought would finish task A 1st and who would finish task B 1st. then they gave detailed instructions of each task and asked the teams to complete them. At the end, none of the teams picked the correct winner, where as both Olav and Chris picked correctly. The point of the exercise was that Olav and Chris made their decisions later where as the teams made their decision early even before knowing what the tasks were.

They then compared the risk profile of an agile project (many short increments) vs. the risk profile of waterfall project (one long increment). People who are risk averse prefer the waterfall model even though the agile risk profile appears safer.

Next they explain real options which is an approach that allow optimal decisions with the current context. It has two aspects: Math and Psychology. Using math to price real options is hard, but the results of the math tell us that:

1. Options have value

2. Options expire

3. Never commit early unless you know why

When making a decision, you can be right, wrong, or uncertain. People hate uncertainty so much that they will rather be wrong than uncertain. From a psychological aspect, rather than saying don’t make the decision now, say let’s make the decision under these conditions and circumstances (postponed till a future date) “let’s do it when…”

They wrap up by showing how real options apply in IT. No big upfront design and defer decisions too last responsible moment. Pair programming gives you options by sharing knowledge and making you less dependent on one person. Also, by assign juniors 1st to projects this leaves seniors (valuable skills) to coach and mentor with an option to work on emergency or high priority projects that come up later. When using an MS project plan, it gives us the zero probability date. Before that date there is no chance of delivering early. On that date you have zero percent probability of delivering and then the distribution builds from there. A study shows that to get 90% probability you need to multiply the given estimates by 4.

This presentation is available on InfoQ at  http://www.infoq.com/presentations/software-with-real-options

Sunday, July 26, 2009

Coaching and Scaling Agility

At QCON San Francisco 2008, David Hussman gave a presentation on coaching. He defines coaching as helping plan products, helping with iterative delivery, helping tune and improve, and helping to build community. Coaching is about guiding people from how to why Shu, Ha, Ri or practice, improvise, and evolve. Coaching gigs and styles vary greatly. They can be prescriptive where this is what you should do or descriptive where this is what I have seen work.

When coaching large communities, it is important to understand that there is no recipe. Each community is unique. David recommends coaching respectful change where change must happen with people and not to them. Try to understand who people are, how they work right now, what’s working for them, and what motivates them to change. Try to find some set of practices, a way to bound as a community, some way to talk about products, some way to deliver it, and some way to tune it.

Then David talks about providing real education by building a library, providing pragmatic (need to try and experience things) training, coaching classes, facilitating training, and teaching TDD-refactoring.

David talks about chartering which covers who is involved, what we are trying to get done, what are the risks, timeline, etc… David uses chartering to find common goals and build a collective groove. Here is what we are trying to do, here is how we know when we are done, this is who is building it, etc...

Next David discusses scaling core practices. He recommends creating pragmatic product roadmaps (3, 6, 12, 18 months), pairing beyond programming (business person, testing person, and development person), radiating information, making issues visible, and promoting improvisation.

Then David describes two situations: many teams, many products or many teams one product. They need to be working in cross cutting concerns. Also we need to build customer communities composed of people that have interest, passion, knowledge, and some decision making capability.

Lastly, David discusses issues with large distributed communities. Conference calls are NOT just like being there. One option is building whole sub-teams around common goals and common understandings.

This presentation is available on InfoQ at http://www.infoq.com/presentations/coaching-scaling-agility

Monday, July 20, 2009

Behavior Driven Development

The RSpec Book: Behaviour Driven Development with Rspec, Cucumber, and FriendsAt QCON 2008, Dan North gave a talk about BDD. Dan start by stating that projects fail because the products come in too late, cost too much, do the wrong thing, are unstable in production and crash every day, break the rules, or the code is impossible to work with.

Next Dan compares the bottom up and top down approached to delivering software. Frederick Taylor’s scientific management theory kind of says that people are lazy and stupid and as a result we need to make their work simple and we need to constantly monitor them. We need to separate work from management. Top down process on delivering software is based on premise that people downstream are increasingly pluggable and prone to make mistakes so we need to front load our process with all the smart stuff so there is less risk of something going wrong as we go further along. Since the price of defects increase the later it is discovered, we need big upfront design(BUFD). Plan, requirements specs, functional design, detailed design, test plans is hedging against the exponential cost of change, but this is in turn creates it and thus creates a reinforcing loop. There is no cause and effect, they both cause one another.

Meanwhile Deming’s premise is that people generally want to do a good job and take pride in their work and they respond well to an encouraging environment. Bottom up process builds business objects to represent business domain and then produces an architecture to wire them together.

Next Dan shares statistics that say that 60% of features are never or rarely used, 30% are sometimes used, and 10% to 15% are often or always used.

Then Dan explains that Behavior Driven Development is about implementing an application by describing it from the point of view of its stake holders. Only focus on high-value features, flatten the cost of change of anything at any stage, prioritize often, change often, adapt to feedback and continuously learn. Pull requirements as needed, evolve the design, code that can change, frequent code integration, frequent regression tests

BDD is derivative from XP (TDD, CI), Domain Driven Design, Acceptance Test Driven Planning (estimation based on building one scenario on top of another), Neurolinguistic programming (NLP), systems thinking.



BDD is getting the words right, enough is enough and more is waste while less is irresponsible, agreeing on DONE, outside-in (more systemic approach), interactions (series of interaction between people with different skills and software is an output of these interactions). People over process.

Dan next elaborates: