Agile2007: Wednesday

As you may have noticed, I’m getting a little behind posting these. On the offchance that anyone’s actually reading, rest assured that I still have my scribbled notes, so they’ll be appearing here eventually.

Presenter First: TDD for Large, Complex GUIs

Scott Miller (Atomic Object)

I was torn between this session and the one on Ruby metaprogramming, but it wasn’t clear who that one was pitched at, so I decided not to risk sitting through another basic tutorial. Alkesh went to the Ruby one, and apparently it was pretty good (if I’d noticed that David Chelimsky was presenting, I probably would have gone along). Anyway, as we all know Alkesh doesn’t have a blog (actually that’s not strictly true), so you won’t be able to read about it :-)

The Presenter First session was billed as advanced, which meant they could get away with skipping a lot of background and piling into the interesting bits, which was a pleasant change. The example code was all .NET, but it’s close enough to Java that I could easily figure out what was going on. The testing made heavy use of mocks, and was very much BDD style, although using NUnit (I assume) rather than a specific BDD framework (apparently there’s an NSpec).

The basic aim of MVP is to separate flow control logic from the data model (or worse still the view). UI events are passed to the presenter by the view, and the presenter then performs whichever actions are required by calling methods on the model, and if necessary updating the view. Similarly, system events are passed to the presenter by the model, and the presenter updates the view. The intention is to have as simple a view as possible (because it’s difficult to unit test UI code), and to avoid coupling the model to a specific UI or to the sequence of events for a particular user story.

Presenter first is a way of developing MVP code which (as you would expect) concentrates on the presenter first. The presenter’s behaviour is specified by mocking out view and model methods as the need for those methods arises and injecting events, then by implementing the (limited) behaviour of the model and view. One side-effect of this is that your database design is both emergent and implementation-independent, allowing you to replace your database (which might be memory or file based, not necessarily a relational database) with another implementation of the same interface.

The pattern can be applied recursively – if a view becomes too complex, it can be split into another MVP triad, with the presenter acting as an adaptor, in that it appears as a presenter to its own model and view, but like a view to the parent presenter.

On a slight tangent, one thing that surprised me was that Visual Studio apparently doesn’t show compile errors as you type, with that feature requiring the Resharper plugin. What sort of cowboy outfit are they running over in Redmond?

Agile Development Using a Functional Language

Robert C Fischer (Fischer Venture Management Corporation)

Took me a while to find the room for this one. Turns out that unlike meeting rooms 1–17, meeting room 18 isn’t on the meeting room floor. Still, I did better than the guy who was supposed to be presenting, who apparently never turned up at the conference at all. Which made for rather a short session.

Agile Blending: How to be a methodologist not a methodist!

Rachel Davies (Agile Experience Limited)

This was quite an interactive session, despite being held in a massive room. The main thrust behind it was that we shouldn’t get hung up on following “pure” XP, Scrum or whatever, but find out about a variety of different methodologies and choose the practices from each which address our highest priority needs.

Based on quick show of hands the overwhelming majority of people in the room followed either XP, Scrum or a mixture, with a handful of DSDM, Lean and Crystal people. We went on to discuss amongst each table which practices we followed, which we felt guilty for not following, which we’d added recently and which we were thinking about adopting in the future. It was obvious that there’s a large set of “agile” practices (although, of course, the Agile Manifesto doesn’t define any at all – that’s left to each methodology), and a wide variance in the number of practices that people calling themselves agile actually follow.

Rachel said that many people regard sprints, sprint planning and stand-ups as the core Scrum practices, and TDD and pair programming as those for XP (although pairing has always been our team’s weakest XP practice). There are often good reasons for not immediately adopting all the practices of a methodology immediately, although you have to make an informed decision, particularly as practices often reinforce each other (this is particularly true of XP).

Many teams or organisations make the mistake of adopting an agile methodology because they feel they want to “be agile”, rather than having a clear reason in mind. We were asked why our organisation had chosen to adopt agile development – in BT’s case I think the main driver is improving our responsiveness. Personally I started using XP because it allowed us to deliver stuff very quickly without wasting time on documents but without sacrificing quality either (and in fact massively increasing it). I also liked the emphasis on working directly with the customer/users, as this was something I’d already seen the benefits of.

Apparently Rachel has seen teams who not only never paired, but barely spoke to each other, with developers pitting themselves against each other in counterproductive commit wars. This is the kind of thing that can only be fixed by the team itself (with coaching), not by trying to impose agile methods from above, for example by mandating daily stand-ups. Too many teams request Scrum training because they’ve been told to, rather than because they think it will help. This is something I’ve definitely come across at work – for those of us trying to drive agile from the bottom up it’s great to have executive level support, but it doesn’t make much difference to those (and there are many) who see it as just another fad, and only do enough to tick the right boxes.

In the Q&A at the end, someone asked what the most common pitfalls there were when trying to adopt agile development. The two that Rachel mentioned were allocating roles to the team (you’re the scrum master, you’re the technical lead etc), without clarifying the real responsibilities; and getting hooked on reporting tools instead of talking to each other.

Someone else asked about achieving agility in a highly-regulated environment. Rachel said that there were lots of things you could do even if you started with a formal contract of requirements, such as splitting it into independent features and developing them incrementally. Another audience member made the point that most people go way over the top trying to document processes for auditors, when surprisingly little is usually required (often just basics like “all bugs are recorded and tracked”).

The Role of Leadership in Software Development

Mary Poppendieck (Poppendieck.LLC)

As expected, Mary was a very good speaker, running through the history of lean management from Taylor’s scientific management (pretty much the antithesis of lean/agile thinking, based on the assumption that all workers were too lazy and unintelligent to be allowed any control over how they did their jobs), through the methods used to improve production in the US during the war (and abandoned afterwards) to Deming‘s work in Japan and the Toyota Production System (TPS) and Lean in general.

One of the important aspects of the TPS is that, while each task should be carried out according to a standard, that standard is owned by the people performing the task, and should be continuously improving. One way of encouraging these improvements – or kaizen – is to create an initial standard, but make it a poor one (but not too bad). This motivates the people following the standard to improve it.

One of the most important responsibilities of a supervisor in the TPS is to keep improving the standards. Apparently Taiichi Ohno, the father of the TPS, once accused someone of being a ‘salary thief’ because he hadn’t changed the process in a month. He used to insist on the standards being posted up in the factory, and looked out for any paper that had started to yellow, because that was a sure sign that it hadn’t been improved recently. As an aside, one of the challenges we had when handing over our previous project to an offshore/outsourced team was to impress on them that our ‘quality plan’ (actually a smallish wiki page) wasn’t set in stone, and that it ought to keep changing as they improved the processes.

Mary also made a few comments about teams which chimed with what I’ve been banging on about for a while: people aren’t ‘resources’; good teams should be kept together; and performance bonuses for software developers aren’t a great idea, but any system should reward teams, not individuals (see this essay for more). When measuring success, it should be in terms of real business benefit: “technical success is a euphemism for failure”.

Managers should think horizontally, rather than focussing on their vertical slice of the process. This is definitely something that’s being adopted in BT, with the shift to end-to-end customer experience programmes (lead-to-cash, trouble-to-resolve etc). As an extreme example of focus on the customer experience, A group of senior Lexus engineers spent three months living in luxury in LA, so that they could understand their target customers. Nice work if you can get it!

One comment about Lean that seemed to conflict with the basic principles of Agile was that “the chief engineer sets milestones, and people make sure they meet them”. That sounds an awful lot like Gantt chart management to me, but maybe it makes sense in a production (as opposed to development) environment, or maybe I misunderstood the point.

In response to a question from the floor, Mary talked a little about reducing waste in terms of product backlogs. Her suggestion was to limit the backlog to only what would fit in two iterations. That way the customer knows that if his request makes it into the backlog he’ll get it in no more than three iterations’ time, rather than seeing it languishing at the bottom of the list forever. Sounds like a nice idea in theory (and a little like 37 Signals’ Start with No), but I think there may be a danger of good ideas being forgotten because they don’t quite make it onto the backlog (I guess the customer just keeps their own list). Also, what if something more important comes along, and you have to throw away something at the bottom of the list to fit it in? Obviously you’d discuss it with the customer, but all of a sudden that certainty of delivery disappears.

Finally, a random factoid on the importance of good management which I can easily believe to be true: 80% of people who leave a company do so because of their immediate superior.

[tags]agile2007, washington, MVP, presenter-first, lean, TPS, Poppendieck[/tags]