The track in question was entitled “Agile in Actuality: Stories from the Front Line” and the track coordinator was Katherine Kirk, whom I’d see present a great talk two years ago on how her team had used Kanban to salvage a BBC iPlayer project from certain doom. Ironically, it was her talk that I skipped this year to attend another track, as she was covering fire-fighting another BBC project this year, which wasn’t something I thought I’d benefit from. So I’ll talk about my one deviation from the track first.
New capabilities of HTML5 browsers, Maximiliano Firtman
Max is a man who knows web development. He hinted at this through the huge pile of books he’s written and through an excellent presentation on what a nightmare developing HTML-based apps for mobile can be if you approach it unprepared. Developing for mobile has three key problems:
- HTML5 is in draft and in flux. Many browsers can claim to be HTML5 compatible, yet offer completely different behaviours, when experimental feature APIs are used for example.
- Screen-size hell. Different devices offer wildly varying resolutions and screen sizes. Rendering an HTML app well in all these resolutions is a massive challenge.
People over Process: Applying it in real world software development
Getting back to the main track, I feel the title of the first talk, by Glen Ford, better summed up the sessions I attended than the official title did. From talks by Glen, Dan North and Benjamin Mitchell, I took away a fairly consistent set of ideas:
- There is no agile rulebook, so don’t become process-bound when using agile techniques. Glen cited an example of a company he had worked for, where a team was clearly unhappy with Scrum, but they were following it to the letter. He explained that doing so was clearly what was making them unhappy, as the process wasn’t working for them. Dan offered a great sound bite warning of the dangers of becoming process/rule-bound: “DRY is enemy of decoupled”. If you avoid copying & pasting, you risk coupling aspects of your code together when refactoring common features. If your company successfully releases often off the back of a continuous integration/deployment system, tests early and often, sees waterfall as a plague upon humanity etc, then your company does agile. Whether you have a fully qualified Scrum Master to ensure you follow the rules of Scrum to the letter matters not at all. Do what works for you.
- “Fire, aim, ready.” Another great phrase from Dan. A company cannot be agile in isolation; it needs the support of the customer. Benjamin gave an example of a company he’d worked for that he talked in to being honest to a customer as early as possible, by explaining they’d not be able to meet their targets. The customer was obviously disappointed by the news and ran through the usual “can’t you just do overtime” type “helpful” suggestions. However, the customer then went on to sing the praises of the company to others, for they felt they could be trusted to keep everyone informed of progress, even if the news was bad. In Dan’s talk, he espoused the benefits of involving the customer as much as possible in the entire development process, including encouraging them to test as early and as often as possible. I love this idea. When I first started out as a developer, one of the golden rules of the time was that bugs got more expensive to fix the further they migrated from the programmer and customer bugs were the most expensive of all. Over the years I’ve learned that this is a classic “treating the symptoms” advice: the problem was not that customer feedback was expensive, but that waterfall makes everything expensive to change and fix. Customer feedback is not expensive, it’s priceless. Waste that invaluable resource at your own peril.
- Understand your domain; understand why your jobs exists. Glen, during his talk, described three companies he’d worked for. In the third example, he worked with a team of highly skilled, highly experienced developers. Ironically, it proved to be a near-paralysing environment to work in: an example of “ask 10 developers for an opinion on how to do something, and you’ll get 11 answers”. These people sought perfection in everything they did, at the expense of actually making progress. One of the directors brought things back down to earth, by pointing out that if they didn’t achieve a milestone in six months, the backers would pull out and the company would fold. The key to overcoming “perfection paralysis” was to acknowledge what the goals of the company were and to focus on them. By understanding the “why”, the team had a clear focus. In a similar vein, Dan explained that one of the strengths of a stock trading company he’d recently worked for was that they taught trading to all staff, including the developers. Only by understanding how the company worked, could the developers be properly focused on what they needed to be doing to get the job done efficiently.
- Trust and responsibility. An army typically employs low skilled, low achieving folk. They need strong processes to manage such a group of people. In contrast, developers are highly skilled, motivated and intelligent folk. Imposing processes on such people will give the impression that they aren’t trusted to act in a responsible and disciplined fashion. With trust comes responsibility though. As developers we have a responsibility to behave in a professional and disciplined fashion. An important part of this process, touched on by Dan is in how we think of ourselves within our company. If you see yourself – or your company sees you – as part of the company’s IT infrastructure, rather than as part of its business infrastructure, then things have gone wrong. Unless what you do has no benefit to the company, then what you do is part of the business. Again this comes back to “know your domain”. If you understand the nature of your company’s business and how what you do effects that business, you are in a position to effect it in a positive fashion. “Be effective, not productive” as Dan put it. You can follow procedures and produce code all day long, but unless they are effective, you are wasting your time and that of your company.
In summary, I took away from the day the ideas that being an agile isn’t about following agile processes. It’s about the company being honest, adaptable, disciplined and effective. In other words it’s about being professional. A business full of professional developers doesn’t worry about processes; it puts people, and the interactions between those people, first.
So ended the second great day at QCon London 2013.