Agile training
A few weeks back I participated in a four-day Agile training provided by the POWERSHiFTER client I've been working with for the past year and half.
The client started a transition to Agile about 3 years ago, but corporate environments are slow to change. This particular client did not have much experience in what a successful Agile development workflow looks like, with varying experience and expectation across the whole department. So in my mind, this training had long been overdue.
The session I participated in was more oriented towards the technical staff, especially developers and QA. In fact, I'd say it wasn't really "Agile"-specific training at all -- it was training in how to write expressive and maintainable code -- the type of code necessary for Agile to work effectively.
The training was provided by the Toronto-based LeanIntuit. Declan Whelan was flown out to Vancouver, spending two weeks with two separate development teams.
The first day was on Acceptance-test driven development, which presented a vision of how Agile teams go from incoming requirements to defined user stories with acceptance criteria, to automated tests (using cucumber), to realized features in production. The takeaway was that a whole Agile team can work together effectively to systematically introduce new slices of functionality. Not especially relevant to our exact day-to-day, but a good presentation of how Agile could work, and does work, in optimal environments.
The next few days were largely around TDD and clean-coding techniques. It was largely 101 stuff, but a welcome refresher for myself, and a much needed introduction for many of the attendees.
It's not that the developers of this client are particularly bad developers -- just that they have not been able to benefit from experience. Declan was quick to point out that he sees this dynamic at nearly all of the companies he provides training and coaching to:
Developers who have never read Clean Code or Domain-driven Design, developers who have never been introduced to concepts like SOLID Principles, Simple design or Extreme Programming. Javascript developers unfamiliar with functional programming and backend developers who believe TDD is a waste of time.
It was neat to see the eyes light up of individuals when things would just "click" for them. After three days of practical exercises and discussion, many people seemed much more open to ideas that Declan presented with care, without much force.
One particular technique that stood out for me was the "Golden Master", used in refactoring legacy code -- especially legacy code with minimal/non-existent/failing unit tests. Oh, I can think of multiple occasions where I wish I had known about this one. In a nutshell, all original output is dumped to files, and as you refactor you comparing diffs between the new output and the original (the "golden" master). If the output differs, then you've messed up or introduced a bug.