Notes from Agile North
Contents
- Agile in Waterfall Case Studies
- Agile 101
- From Chaos to Kanban
- CRC-the Forgotten Design Tool
- The theory of constraints
- Embracing Change: Guiding teams on Mt. Agile
- Conclusions
I attended the conference on 14th May 2010 at UCLAN. I got a lot out of the conference and want to share my enthusiasm and what I found out. Here are my notes on the talks I attended.
Agile in Waterfall Case Studies
Kevin Murray, Valtech
The content of this talk was really valuable but it was unfortunately marred by death by powerpoint where all of the speaker’s points were put up on the screen and then read back to us. This is typical of a lot of corporate presentations and it really doesn’t work. The endless bullet points get in the way after a while and don’t help, your audience can read faster than you can talk and start waiting for the slide to change, it doesn’t engage them. See this presentation for an excellent discussion of this. Powerpoint can also kill people for real when it’s used badly . As an aside I recommend Tufte’s work to anyone who has to communicate complex ideas.
Despite this drawback substance of the talk was very useful and consisted of two case studies. The first case study described how they managed to go from a long waterfall process with one delivery a year and panic stations at the end of each cycle to two deliveries a year with everyone knowing what was happening and no surprises or panics. This took a while and a lot of care and thought. One thing that came across very strongly was that this was done by a change of culture, not a change of team. Agile’s emphasis on short cycle pushing out working code meant that the test teams were kept busy and problems (and hence rescheduling of other resources) were caught early. The original contractor had done the typical “easy things first” on their list of tasks, which always meant a last-minute panic and integration pain. This was a large ongoing project for the government and everybody was happy with the result, and they managed to easily keep within the terms needed by the project governance – the constant sharing sparked from agile made it easy, in fact. They used a relatively long sprint and large team size, but it worked. In the second Kevin was the “14th project manager in 3 years”, asked to take on a team who were badly motivated in a department that is unfortunately known for failure. The first thing he did was sit with the team and then protect them from their users (who liked having daily 2 hour meetings). Then he implemented the usual scrum way of working and attacked the issues. Again it worked and they managed to calm things down and get things done.
Hats off to Kevin. He’s obviously very competent and good at rescuing complex projects and has proved conclusively that even large projects for the government can successfully use agile.
Agile 101
Nick McKenna
This talk was more of a question and answer session where the dreaded bullet points were used to spark debate and interact with the audience, so they worked in this context. Nick presented a couple of imaginary timetables to take people to doing the “full stack” of scrum from a standing start. The discussion was lively and covered a lot of the things that might trip you up, including the “interfering MD” and “no senior sponsor”. These used to trip you up anyway, so no change there, if we’re being honest. Nick’s an engaging speaker and knows his stuff.
From Chaos to Kanban
Paul Shannon and Craig Judson, Codeweavers
This was a very honest talk from two developers from Codeweavers, who talked about how their teams confronted their difficult work environment and eventually managed to get in control of things and turn them around. The talk was presented as a series of observations and responses from Paul and Craig, with some comments and aside from Kevin Rutherford who they brought in as an Agile Coach. The slides are here and this was a run through before they present at XP2010, the full paper is here .
The main thing I got from it was that they didn’t just say “we’ve fixed it now” when they had managed to overcome the problems in the previous observation, there was a strong emphasis on doing retrospectives and getting past and through the next problem. They have a quick standup every 2 hours. It seems a little pointless for me to reiterate what’s in the slides but the one thing I did take away was that they needed Kevin’s input when they got stuck. Just getting yourself the certified scrum master isn’t enough – you need input from an experienced coach to get past yourself.
CRC-the Forgotten Design Tool
Sam Wessel
For me, this was the most disappointing session because I think I got it quite quickly. We were split into groups and the group I was in were thinking far too much. I think that CRC needs a “test first” approach, as in get something down and then refine it later. They were trying to get it right straight away and it doesn’t work that way. Myself, I tend to use the only UML diagram I can be bothered with, the swim lanes with interactions, to model class interactions, usually collaboratively in front of a board. I very rarely use electronic tools for this kind of work and think that the CRC cards will be a useful tool when I need them.
The Theory of Constraints
Kevin Rutherford
I believe that Kevin was asked to step in at the last moment but he didn’t disappoint. For me this was the most interesting and useful talk of the day. He talked about Goldblatt’s Theory of Constraints as outlined in his novel The Goal and how it applies to agile. To illustrate he used a simple task of setting up some dice so that they all showed each number in order, varying the number of dice and the number of people doing the task at a time. One person do all dice and passing on, one person doing one at a time and passing on, everybody doing the complete task. When you draw a graph of these scenarios, you get classic waterfall (nothing, nothing, pow!), 1st attempt at agile (as in people still have specialisms) and generalists getting things done in parallel. The illustration is of course simple and not “real life”, but nevertheless very effective. The speedup each time was at least an order of magnitude, and, of course, you start seeing the benefits of your investment as soon as the first “die” is through the process.
The theory says that the slowest element in a supply chain controls the whole speed of the chain, and even speeding up the wrong piece could make things worse. The thinner you can cut your deliverables up the faster you can deliver them, which became “the thinner you go the faster the flow”. I tweeted this and it looks like a few others (including Kevin) retweeted it which is good. The thing that is being supplied is whatever is of value to the organisation. Agile is the quintessence of this, finding value and getting it out as fast as possible.
Kevin talked about Kent Beck’s latest idea – write and deploy one line at a time sounds crazy, but it could work very well – the team will be experts in deployment straight away and be experts in finding value straight away. I’d like to try this, if I can find other brave like minded people. I suppose it has some resonance with the OSS mantra of “release early, release often”. Maybe this would be a good way to start something new.
I saw a lot of parallels with Cockburn’s I’ve come to bury Agile, not to praise it talk where he compares producing software with a manufacturing process where the unit of inventory is the unvalidated decision. Speeding process up involves working out where the decisions aren’t being validated and adding more resources there.
Both of these talks articulate things I have understood for a while but not been able to do much with. I will start to look for opportunities to do more with them. I felt a great resonance with wanting to produce something of value to the organisation as quickly and often as possible.
Another startling but also precious idea I got from this talk was how useless a “green field” is – you need to get the code/delivery space “brown”, as in something real has been put out where it can be used, as fast as possible, then you can start making it better and engaging with your users.
Embracing Change: Guiding teams on Mt. Agile
Jim Barritt (Thoughtworks) and Mark Crossfield (Autotrader)
Autotrader brought Thoughtworks in to help them with some new things and the talk covered what they did to make things work, environments and working practices. There weren’t any bullet points (I think Thoughtworks stay away from them as corporate policy, never seen them used by a one of their employees, good!), and the talk used a metaphor of mountain climbing in order to illustrate what they did. I was very tired at the end of the day and can’t do the talk justice, but will attempt to cover the points I can remember here.
In essence, when you go climbing you need to make sure you have the right kit, guides and information. The kit consisted of using Cruise, a Thoughtworks product that tracks your commits, puts them into a test suite, runs them and then pushes them through to a production deploy. They are of course using test-first. One of the interesting things they were doing was having a single binary that gets pushed through the different stages, to minimise environmental problems. A lot of up-front effort was spent making this tool work properly, but like having something to attach your rope to, it is worth it because any falling off the hill doesn’t result in a broken head.
I missed the middle of the talk, it just didn’t go in. The end was interesting, Jim started talking about having the “story” of the code in and making sure that new people were told the story, so that they understood why decisions had been made the way they were and were encouraged to keep asking until they had an answer or just change stuff that wasn’t explained. As far as I could work out they have opted not to use a standard MVC and have their own way of doing things, hence the need for a story. I didn’t question them about this, but personally I tend to stick with a standard approach because I don’t like thinking about anything other than getting it done. I think the idea of the story teller has legs, but not rolling your own non-standard approach. In fact the whole NIH-I-wrote-a-new-one thing drives me nuts, let’s get to the requirements and deliver them right now, not next week. (NIH – not invented here). I may be misrepresenting things because I was very tired at this point. There was also an off the cuff comment about putting comments into the code, as in there aren’t any there already, which I’m sure I misunderstood.
Conclusions
Agile North was well worth attending and I met some really interesting people too (lots of activity on LinkedIn since the conference). They said they’d probably do another in October, probably free. I will be attending if it doesn’t clash with the European Rails Con (really must book my ticket!).
Agile is also very subversive, one of the things that came up during the panel discussion at the end was how hard it is to get large, engineering or government driven organisations to change. They have years, decades, of getting projects out of the door following prescriptive methods that work for them, even if they aren’t the best way of doing things. Agile empowers the people doing the work to talk to each other and make sure things get done. Top-down multi-year projects don’t work this way and corporate governance is king. In chatting to people at the bar one of the speakers told me that he had been asked to implement Scrum into a large corporate and failed more than once. It only works if the will comes from above and below in these large organisations, and it can never work if you don’t trust and listen to the people who work for you. The macho 1990’s management my way or the highway attitude does not fit, and will not make it work, neither does a culture where you always do what you’ve always done because it gets you what you always want. It’s a gentle revolution, allowing people to work together and practice their craft without fear or being strangled by the dead hand of bureaucracy.
Some practices, if done honestly, such as test-first and stand up meetings, will help in any situation. But the heart has to be in it. Organisations like Thoughtworks are making them work across disparate teams in many locations and have published talks on how to do this.
None of this is new, either. Good project managers knew about managing by walking around and used to use what Alistair Cockburn calls information radiators, as in whiteboards and diagrams saying what needs to be done.
