Category: Development

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. 🙂

 

Being my first conference for just over 4 years, I was unsure of what to expect. Luckily, the journey was not eventful in anyway and finding the venue was relatively easy. It was great to join other professionals who were working in environments with varied amounts of agile methods being used. I felt that all the sessions I attended over the two days provided me with great information that I felt I could take back to work and suggest as ways in which we could adapt our current methods.

Testing at Google – Dr James A Whittaker

The first session was the Keynote Speech from Dr James Whittaker who is a Director of Testing at Google – ‘How Google Test Software’, it was very insightful to see how Google manage to test their software when they perform several releases a day for many of their products and this was made even more suprising when he mentioned the dev heavy ratio when comparing the amount of developers to testers. A phrase from his speech that sticks in my head was ‘Testing is like heath care, it’s an on going process’. It was a very useful talk and if I could take anything away from this talk, it was that with the amount of testers they have compared to developers, it is important to put the ball back into the court of the developers to make sure they have tested their own code to an acceptable standard before the testing team see it. Also with the methods they have in place to ensure that any bugs raised are fixed as early as possible, certainly make it seem like a very productive environment.

The Specification Game – Gojko Adzic & David de Florinier

After a half hour break and talking to some other guys about their processes, this next session was one of the most eye-opening and intriguing of the conference. The workshop that Gojko and David presented to us was that we had to produce the first iteration of a blackjack game, we were given a description of the game from which we had to pull the features we felt would be enough to produce an end-to-end working game for the first iteration. This is where we made our first mistake, Gojko had mentioned he was the customer and not once did I as the Product Owner for my team feel that I needed to check something or negotiate requirements with him. I picked the requirements I felt fit for the team and the team started developing the prototype while the testers were pulled over for a few pointers with David, when they returned, we didn’t sync up as a team to make sure they understood exactly what the developers were developing but instead they ploughed into writing test scripts. The problem with not syncing up as a team earlier on, then hit us when we ran the test scripts and we failed the majority of them for simple reasons such as the wrong words on the UI buttons (Stick and Twist rather than Hit and Stand) and the cards being dealt two at a time for each user rather than one card alternatively.

We then recieved the User Acceptance tests from the customer (Gojko) and quickly found that we failed all of them. Gojko then mentioned that not one team had gone to him earlier to get the acceptance tests, meaning that none of us actually gave the customer what they needed.

All this in 90 minutes, it was a very interesting session that highlighted 3 major points to me:

1. It’s important to interact with the customer to find out exactly their needs of the product and negotiate scope
2. Make sure the team is reading from the same page for the entire length of the project and that testers are aware of exactly what the developers are coding
3. Ask for the User Acceptance Tests as soon as possible, this way you can make sure your product covers the minimum of what the user wants.

A great session which was well led and left us all discussing it for the lunch break afterwards.

Creating Agile Environments – Rachel Davies and John McFayden

I was keen to attend this session as I was interested to see what would be defined as a good agile environment. The session was made up of two main group discussions where firstly people discussed their experience of workspaces from hell, followed by workspaces from heaven. The additional fun factor here was that we were asked in teams to create our worst and best environments using playdough and other creative materials.

There were some shocking stories for some of the worst environments but most had a common theme, such as division of teams with people working together but not being able to communicate very well with each other,  lack of communication with management, noisy or silent environments, lack of  motivation for employees and many others.

Obviously in a lot of cases, the good environments were an exact opposite – good communications, teams sitting in the same area so good collaboration, supportive management, incentives,  a happy environment. A few additional features were things such as modern technology both in machines and in communication tools, break out areas, windows with great views and project workspace.

The one thing I took away from this session was that for a team to work well together, the environment in which the team is located in is paramount to their success.

Winning Big with Specification by Example – Gojko Adzic

Before I attended this conference, several of our QA team attending the Iqnite conference in London and all came back to the office raving about this session. Having attended Gojkos workshop earlier in the day, I was keen to attend this session too.  The concept of Specification by Example was a new concept to me and listening to this presentation really opened my eyes to the idea of the collaboration between stakeholders, developers and testers to define high quality requirements that can be turned into a set of high quality user stories followed by a set of tests which would be the user acceptance tests, the difference being that the team will understand the need for these acceptance tests a lot more than if they were just given to the team by the users.

These then also turned into the living documentation which in itself is a very interesting concept, a document that will be continually up to date and will mean any change made to the software can be facilitated very easily. I can really see the benefits of using this approach and will be looking for Gojko’s new book when it is released.

The lesson shining through here again was to have the tests written before coding is started, then the team will know that the product is fit for purpose when it is complete.

Cyberdojo – Jon Jagger

I was looking forward to this session before the conference and when it came to the conference itself, I was so impressed with all the previous that I didn’t have time to even think about this before I turned up to it. The concept of this was reasonably simple, it was a pair programming exercise where every 5 minutes, whoever was ‘driving’ would move to another machine and become the ‘passenger’. The way it was set up was as follows:

• Every machine had a unique animal avatar
• The first users on each machine would choose a language (C, C++, Java, PHP, C#,Perl,Python)
• They would also choose an exercise (ranging from generating prime numbers to anagrams)

When the users have selected these, they are then given a test script that fails for this exercise and dummy source files.  As soon as you press the play button for the first time, the current program will compile and the tests will be run, depending on the state of the program, a colour will be displayed (green if it works and passes, yellow if it doesnt compile and red if it fails tests). Once everyone had moved around a few times, Jon added an extra rule that every time he rang a bell, all teams had to get to green. This gave an interesting dimension to the coding as some people would try to get their code working as effectively as they can in 5 minutes and then when the bell would ring they would be in a state where it either wouldn’t compile or they failed the tests. Others would do minimal amount of coding just so it continued to pass. It was a very interesting exercise that showed how important it is to control your code and the lesson I learnt here which I found very useful was that if you have completed your exercise at the requred time, rather than moving onto the next exercise, in a collaborative environment, it would be more useful to help others get to the same stage. Certainly a valuable lesson to take back to an agile team working in short sprints.

That was the end of the formal sessions but there was the evening event sponsored by the kind people at Redgate Software. I sat and discussed agile process with some very knowledgable people and learnt quite a bit about how other companies are adopting the agile processes. The most important thing I learnt from this time was that not to expect agile to work perfectly straight away. It will take time to get it right.

For what happened on the second day of the conference, there will be another entry soon.