Scott Ambler - Agile In The Real World

I was able the catch Scott Ambler speak at the IBM Burnaby office today. It wasn't a long talk, about 1 hour or so, but he packed in a great deal of information. Here are my notes.

Traditional Software Design

Academics came up with a bunch of ideas that should work, a theory. Traditional method of: Requirements, Analysis, Design, Program and Test methods mean that validation of the Requirements and Analysis isn't done until the Test phase. Which means that the guys doing the Requirements and Analysis have no clue of the damage until it is too late. Each step information is lost or misinterpreted. The famous quote. Build software like building a bridge. ....but now we know differently.

Agile or Evolutionary method

Agile is not theory, it is based on practice. Less upfront documents. Tests = Specification. High quality software delivered every iteration. Scope creep is good! If you stop feature creep it means you are making software that the stakeholder doesn't want.

Success

80% of stakeholders want what they need, not what the spec designed. B.R.U.F. Leads to Significant Wastage: 45% of features delivered were never used when designing with serial methods. http://www.agilemodeling.com/essays/examiningBRUF.htm Success is not "On time, on budget, to specification." Success is more about delivering quality software that the stakeholder wants today. Spending the money wisely. Deliver working software frequently allows the stakeholders to continually gage the success of a project. Documentation doesn't give value, only delivering working quality software does. More collaboration == more success. White board things often with everyone. Focus on quality...more testing = higher quality. There is no silver bullet, agile requires skilled people.

Developers

Developers should move away from specialization. It isn't effective. Being a specialist means having to hand off things when done. Each time that happens ~25% information is lost. Specialization in 1 or 2 areas is helpful, but have many general skills and domain knowledge. Learn about databases, business analysis, etc.

What you get from Agile

Agile teams are smaller, produce higher quality software that meets the needs of the stakeholders and this basically reduces cost. Agile gives stakeholders control over budget, schedule and scope. Developers give back quality software that the stakeholders want. There are documents in agile. But the type and amounts are chosen smartly. Documents are about stable ideas. There is nothing speculative about agile documentation, which is how traditional methods approach documentation. If you do TDD your tests will be the specification. Every iteration the stakeholders can see if the deliverable is where they want to be. With this information they can govern the spending. But the stakeholders have to know what they want and developers have to deliver quality software every iteration. Repeatable results, not repeatable process. Addresses the risk early.

Must Dos

Learn at the end of iteration. Refactor every iteration. Just in time planning. You can only predict the short term. Continuous Integration. TTD Use static debug tools. Reduce solo development - you must pair!

Example

Eclipse is a very successful agile project. It has delivered its major release on time every year. Google "Eclipse Way Process" to see the Eclipse agile practice. Eclipse does a 6 week iteration due to very distributed workforce. Iteration Stats. 2 wks iteration 32% 4 wks iteraton 21% No need to be longer then 4 weeks unless.

Not everything is green field

Agile needs to cope with entrenched process, legacy code, and governance of IT. Traceability is needed sometime, up front modelling needed sometimes, depending on the project type.

Company

Find out how to motivate developers. don't heard cats. Don't enforce standards, find out what standards people want to follow. Each team should own their code. Have a small number of project metrics, too many is bad. Defect trends and burn rate are good. These show a team is delivering value or not and the stakeholders are getting value for money or not. Help teams that need it. Get ideas from teams that are doing well. Spend money wisely. Ask....how well has it worked in the past. Staged finance is another option, try it compared to annual budgets. HR should reward quality of delivered software, not just years of service.