Lessons Learned from Agile Cambridge 2010 Day 2

Following another 5.45 start, I managed to arrive at the venue for around 8.30am for the second day of the conference. I spent the first half hour or so before the second keynote speech talking to some of the guys from the Cambridge Crystallographic Data Centre who were attending the conference in their numbers.

Building Trust in Agile Teams – Rachel Davies

Having attended the workshop that Rachel ran the previous day, I was looking forward to this session. It was quite an open session with lots of interaction with the audience. Rachel talked about how trust is the foundation of teamwork and as good Agile process depends on teamwork, it is obviously an important factor. A statement that sticks in my head from this session was that lack of trust is like a tax on team interaction, showing that it will slow the team down and the costs will go up.

Rachel borrowed £20 from an audience member and also got a team to agree to do the ‘trust fall’ to portray how trust has to be gained by all involved to allow progress, especially with the trust fall, the team had to trust each other and also the ‘fallee’ has to trust that the team will catch them. Rachel then discussed different techniques to gain trust from a team both from a Scrum Master type role and from a team member, suggestions such as getting to know the rest of the team and to support the team by creating transparency for the team. The key lesson to take from this session was that building trust takes time and it will take a lot longer to regain it if it is lost.

I have to admit, I always thought that trust for teams was almost a given so this session definitely opened my eyes to the point that not everyone is necessarily as trusting as I am. I certainly feel that Rachels book ‘Agile Coaching’ will be worth buying at some point in the near future.

User Story Mapping & Dimensional Planning – Willem van den Ende & Marc Evers

After the half hour break and another cup of tea, I attended this workshop which was extremely well attended to the point that I turned up at the time the session started and the room was already full. The session kicked off with the guys descriping a better way to break down high level requirements into manageable user stories. This was done by first breaking down the system into the different users of the system, so their example was an online auction site, there would be the seller, the buyer and the site admin. Under each of these users would be a goal for the system, then under these would be organised activities that would be required to meet the user goal. Once these had been established, individual tasks to make up these features can be created and sub-tasks (tools) can be defined from then. As shown in the diagram below (courtesy of Jeff Patton and Karl Scotland)

In our team, we discussed setting up a similar mapping for developing a smart energy monitor for the home, which in itself is an interesting product, but was perhaps a bit too complex for this particular exercise as we kept coming up with features we felt were important. We did however narrow our options down to just the home user and the electricity supplier, we were then able to put a story board together.

Willem and Marc then discussed the next stage which was the dimensional planning, this is also shown in the diagram above and relates to selecting a number of releases from the tasks and sub-tasks that have been defined in the story board. They can be organised in a way that the minimum release can be defined and from that, subsequent releases can then also be planned. This is all done before any estimates have been considered. So the minimum release can then be planned and a timeline can be defined.

The guys also described a very interesting set of analogies to describe the releases. They used the terms ‘dirt-track road’, ‘cobbled road’ and ‘asphalt road’ which described the different qualities of the release. Dirt-track road would be a minimum quality release that will get the user from A to B. Cobbled road would be the quality level that most users would be happy with, it would do all that was needed but wouldn’t have any ‘bells’ and ‘whistles’. The asphalt road would be the ultimate version, a highly polished release.

All in all, this was a very insightful session where I felt I learned a lot on how to fathom out high level requirements in a very simple and straight forward way.

The Challenges of Measuring ‘Agility’ – Simon Cromarty and Simon Tutin (GE)

I had sat with these guys at the pub the night before so was intrigued as to what they would be discussing in this session. They had both been tight lipped the previous night on what exactly they would be talking about. They kicked it off by showing the journey that GE had come along as an agile company to get to the level they were at now. It showed that to get to a relatively stable agile ability, it does take several years.

Simon C then split us into groups and asked as to discuss what we thought ‘Agile’ meant, this was actually quite a thought provoking question as it was amazing how many differing opinions there were within the groups, obviously there were all the generic answers such as ‘adaptable teams’, ‘fail fast’, ‘short development iterations’ and ‘collaborative environments’ amongst others. There was quite a long list on the board by the time the Simons had gond around all the groups and collated them. Then Simon C asked what we thought made an agile team successful, this again provoked a lot of discussion within the groups and from what I remember our team came up with ideas such as ‘delivering on time/early’, ‘all the team being enthusiastic about the process and working together’  and ‘if the project is going to fail, the signs of a successful team is that they fail early’.

Simon C then discussed an assessment that is done with all the agile teams at GE, which is a 200 question paper where the team discusses together and ranks each answer between -3 and 4. -3 meaning that this is a systemic or oganisation impediment that the team can’t sort on their own, 3 meaning that they ‘always achieve this’ and 4 meaning ‘we have a better way’. This was a clever way of assessing the teams but also giving them the motivation to improve what needs to be improved and therefore forever evolving as an agile team. Ienjoyed this session and felt this assessment was definitely a way of showing how ‘agile’ a team could be.

In the break before the final session, I found myself stuck between purchasing 2 or 3 different books from the book stand, but in the end stumping for a book by Nat Pryce and Steve Freeman (Little would I know they were on the panel in the final session) called ‘Growing Object-Oriented Software, Guided by Test. A book all about Test-Driven Development which was one of the big themes from this conference.

Creating A Development Process For Your Team: What, How and Why – Giovanni Asproni, Nat Pryce, Steve Freeman, Rachel Davies, Allan Kelly & Willem van den Ende

This was a panel session where questions were fired at them from the audience, questions started with ‘How do you pursuade a company to fully buy into Agile’ which caused discussion around finding the right reasons for moving to agile and to move over slowly. The panel also stressed that Scrum is not really enough for a company on its own, they also need to use XP practices such as Pair Programming and TDD. There was then quite a lot of questions about Pair Programming and also people asking as to why Scrum is not necessarily enough. The panel described that scrum is just a project facilitation tool and that for the team to be completely agile, other methods must also be used.

It was an interesting session and I can’t remember even half the questions that were asked but I remember feeling like I had learned a lot from that particular session.

Mark Dalgarno then brought the conference to a close, there was then a quick flurry of goodbyes and the invevitable exchange of business cards between people and everyone then set of on their journey home.

It was a fantastic conference, it was great to meet like-minded professionals and exchange stories of our experience with the agile processes.

I must say thanks to Mark Dalgarno and team for putting on such a great conference and to Redgate for sponsoring the conference, being out in force to make us all feel slightly envious of their working environment and for providing lots of chocolate for the 2 days! Thanks to all the speakers and for everyone who I spoke to for being so welcoming and interesting!!

I hope I will be able to attend in 2011 and maybe even bring some colleagues along with me. 🙂


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s