Agile and Lean: Crash Course

I’ve just spent the day at an Agile Scotland workshop run by Clarke Ching and Rob Lally, both freelance Agile consultants. The workshop was titled Agile and Lean Crash and aimed to provide an introduction to the basic Agile principles as well as some of the more popular agile methodologies such as Scrum and XP.

About 20 folks were at the session; mostly developers / techies (as expected), but a few project managers and a tester, which was good for different perspectives. Rob started the day with some real life Agile ‘war stories’ from some of his previous work on projects in the financial sector – it proved a good warm up and generated a fair bit of discussion from participants. Clarke took over later in the morning and showed a presentation on the history of Agile, Waterfall and benefits of incremental development, then kicked off a group exercise demonstrating TDD and Pair Programming using Excel. The session then moved onto discussions about the role of testers / QA in the Agile team and Clarke giving some examples of testing frameworks which could be used to automate some of the functional testing.

I’d seen some of Clarke’s presentation and the TDD demonstration before (I attended another of his workshops a few years ago), but it was a great refresher, and group discussion always brings new ideas and information to the table.

Overall a really useful and informative day, and the fact that it was free was an added bonus. Thanks to Rob and Clarke, and the least I can do in return is plug Clarke’s agile business books Rocks Into Gold and Rolling Rocks Downhill.

There is apparently another (smaller) course covering the same material planned for later in June, so contact Agile Scotland for more information

Snippets I took away from the day:

  1. Agile in it’s basic form is simple – 3 rules (x 2)
    1. Prioritise requirements
    2. Deliver
    3. Repeat

    One loop for delivery, the other for improvement – how you implement the above varies wildly, but the basic principle is the same.

  2. Timeboxing iterations – rather than rigid 1 – 4 week windows, try working in x week iterations, but work towards (x – 1) weeks – more likely to finish iteration early, meaning potential early start into next iteration (but no big deal if slight overrun), rather than ‘padding’ work to finish exactly on time.
  3. Developer estimates generally get better over time, but estimates should not be treated as commitments, and advanced estimation modelling (e.g. COCOMO) generally hasn’t been seen to be worth the investment of effort.
  4. TOC analysis applied to the development project can help increase the productivity of a team by identifying the bottleneck. Generally with Agile the test team becomes the bottleneck (as opposed to developers in Waterfall), but this must be addressed, as ‘working software’ means tested software, so if the test team cannot keep up with the developers, you’re just delivering unreleasable software, faster.

Stuff to read / products to look at


About this entry