Ative at Work

Agile software development

Ative at Work

Impressions From Agile 2007 - Day Two

Dave Thomas told about his experience with large-scale agile projects. His take on plans:

The Plan is really just The Best Wrong Answer

Having said that however, he also noted that he had a very good track record with hitting the shipping dates - the worst project was Visual Age for Java which was three weeks late. His secret? Letting the team own the plan and doing estimates in ranges (wideband delphi) to prepare the planning session, then iteratively negotiating over the estimates until a consensus is reached.


Release Engineering - Getting the Development Infrastructure Right

Dave Thomas also named Release Engineering - the work to create the development infrastructure, automated builds and testing and providing dashboards with status for the project to be a key activity. In fact, his experience is that around 10% of the total effort should go into this area. The key points:

  • it is not something you outsource to the IT-department - instead, use real developers and co-locate them with the development team the first 3-4 months of the project as they work to set up configuration management, automated build, integration and testing.
  • Do focus on dependency management - you need to have thin slices of all the components with automated acceptance tests for the interfaces in place early so no-one is blocked by missing components.
  • All components should be tested independently - and provide acceptance tests for all interfaces.
  • Set up an automatic "Product Development Dashboard" with all the vital information - the goal is to eliminate the need for asking, "how's it going". This includes build status, test status, coverage etc. 


Jim Highsmith did a nice presentation on agile from a management perspective, stating that the key to success with agile is to implement it throughout the enterprise. Doing it in silos is a suboptimisation.

The key benefits of going agile:

  • it helps solve issues on developing features in a large, complex system.
  • it improves quality, and
  • it improves predictability

The big value in agile is all the things you don't do.

  • not wasting time on the features you don't need (most features aren't used anyway).
  • the value is driven by the business needs, not by some arbitrary priorities.

The essence - from John Wooden: "Be Quick, But Don't Hurry".

Published aug 15 2007, 01:42 by Martin Jul
Filed under:


No Comments

About Martin Jul

Building better software faster is Martin's mission. He is a partner in Ative, and helps development teams implement lean/agile software development and improve their craftmanship teaching hands-on development practises such as iterative design and test-first. He is known to be a hardliner on quality and likes to get things done-done.
© Ative Consulting ApS