Accelerating Agile

The fastest teams I've ever worked with have been agile. Not big-A, all-about-the-TDD, automate-everything, methodology-over-thinking Agile, but quietly-getting-on-with-business, delivering-the-goods, making-the-trade-offs agile. Think agile manifesto over agile methodology.

It turns out the things I thought were great agile practices, while useful in certain circumstances, are by no means the whole story. Kaizen, or continuous improvement, must be coupled with kaikaku, or abrupt change, in order to avoid getting stuck in the local maximum of 1990s Agile methods.

This talk is about how really high-performing teams work. Not just one or two flukes but enough that there might be something to it. The patterns and ideas in this talk are genuine experiences from active practitioners. This is agile in actuality. Agile is an attitude, not a rulebook.

Transcript

1. - an experience report Dan North @tastapod Dan North & Associates Accelerating Agile
2. @tastapod Once upon a time...
3. @tastapod Step 1: Learn the domain ✔ Seed the team with a domain expert ✔ Study trading – just like a trader! ✔ Practise trading with the traders and while you're there...
4. @tastapod Step 2: Prioritise risky over valuable ✔ Actively surface uncertainty ✔ Domain uncertainty – Integrating with a trading exchange – Managing orders ✔ Technical uncertainty – Latency, Throughput – Toolchain
5. @tastapod Step 3: Plan as far as you need ✔ Adjust as you learn ✔ Reset the board – Every week? Every day? ✔ Review your planning horizon
6. @tastapod Step 4: Try something different Languages – Scala – JavaScript and nodejs – Erlang, Clojure, Go Programming styles – CSP – Actors – Single Event Loop a.k.a. “Turn-based processing” – Fork-join
7. @tastapod Step 5: Fire, Aim, Ready ✔ Get something (anything!) in front of users ✔ The best feedback is from real use ✔ Showcase frequently – even daily!
8. @tastapod Step 6: Build small, separate pieces “Share memory by communicating” DRY is the enemy of decoupled Don't be afraid of functions ...languages or libraries
9. @tastapod Step 7: Deploy small, separate pieces ✔ Make component deployment quick ✔ Make product deployment consistent ✔ Make components self-describing ✔ Make environments unsurprising
10. @tastapod Step 8: Prefer simple over easy I'm using Java. I'm writing HTTP-based services. Do I really need a servlet container? – https://github.com/webbit/webbit I need to manage binary dependencies. Do I really need an XML-based Internet downloader? – https://github.com/mfoemmel/fig How hard does monitoring really need to be? – Idea to wireframe to working implementation in a morning!
11. @tastapod Step 9: Make the trade-offs Build vs. buy vs. OSS Learning a framework vs. rolling your own Does logging really need a “framework”?
12. @tastapod Step 10: Share the love ✔ Pairing ✔ Learning lunches ✔ Code review (!!) ✔ On-boarding
13. @tastapod Step 11: Be ok with “failure” Product Development not Project Delivery Progress is a series of experiments Failing fast is succeeding!
14. @tastapod Step 12: There are always 12 steps Delivering this fast can be addictive :) It can also cause feelings of euphoria There are probably groups you can talk to
15. @tastapod Thanks for listening dan@dannorth.net http://dannorth.net And big thanks to my former team at DRW