My first experience of XP was excellent. Both days revolved around open space sessions and several other talks

Thursday’s talks

Testing Games Is Not a Game – It’s serious Stuff

As the title suggests, this talk was about testing in the games industry and how much testing is involved.

Lightening talks

Several people took it in turns to present a topic to the whole group that they would like to discuss in a smaller group. Each talk lasted for around 5 minutes and provided the xxxxxx for a group discussion with others that were interested.

Due to the amount of interesting topics, there was no way I could be everywhere. Therefore I had already spotted the talks that I was interested in on the timetable and decided to attend them.

TDD and asynchronous behavior

Evolving from Scrum to lean (Matt Wynne and Rob Bowley).

As a keen scrum practitioner, I can honestly that lean methods are slowly creeping into the scrum scene. Here Matt and Rob talked through a ‘war story’ and explained how they molded scrum to fit in at BBC Worldwide.

Key points:

• Value Stream Mapping to to analyze the flow of materials and information. The aim of this was to replace burn down charts, and stories into something a lot more visually meaningful. Also, story points where done away with and replace by number of stories done.
• Using a kanban board to show task movement. This seems useful for incorporating all tasks from concept and design through to development and release.
• The lean principal of “Stop the line”. As continuous integration was in use, if something was to break it must be fixed before any further development would continue.

It was extremely interesting and was rather a ashame this was implement in the final three months of the project. I walked away with a lot to think about and found the talk very beneficial.

Coaching self organizing teams (Joesph Pelrine)

I think Tom Hume sums it all up nicely

Friday’s Talks

Lean thinking: what is distinctive about it and where it is going?

To be hones I was a little disappointed as I only came away with just how poor the NHS is. However, it was interesting in how lean methods could potential help the NHS.

Open space session on agile tools

This was rather an interesting talk on what tools people are using within their agile projects. Add presentation

Open space session on web frameworks

The main frameworks that were brought up where :

• Groovy
• RoR
• Django
• Symfony

I think it is fair to say that they all had some very good point brought up about them all. Although there was no real conclusion, I walked away knowing that Django and Symfony are perhaps two of the better ones.

What I got out of the day

• Scrum doesn’t have to be implemented ‘out of box’ and its best to integrate other lean concepts into the lifecycle.
• Lean is the way forward and there are many other thinks lean can bring as i discovered in Matt and Robs talk.
• Testing, testing and more testing.

Early last year I heard about a management process called Scrum. As we didn’t really have any management process in place for the development team, I felt it necessary that we needed something. I began reading about Scrum, and could see the benefits that scrum would bring us. Before long, I booked myself on a SCM course, which was a 6 month wait. In the mean time, I decided to implement some of the scrum practices based on my understanding at the time. The first thing I done was bought 3 sprint boards, which were placed at the end of the office where everyone can view them. The following week we started to have morning scrum meetings. This was at most the very basic attempt at scrum that we employed.

Before letting you know of the results and how we actually benefited we did initially encounter many problems:

The morning scrum meetings

Every morning, we started off the morning scrum. This consisted of all the departments, and the stake holders. The problem this presented to us is, was there a need for the designers to be present when in most cases they where not needed and therefore produced waste. A knock on effect of having the design team there also sparked conversation. The result was a morning ‘catch up’ meeting that lasted up to an hour.

Of course reviewing the situation we ended up just including a PO, the SM and the team which of course worked better for us. However, the time boxed meetings still dragged on longer than the 15minutes.

The two questions that were eventually answered later where, should the designers be part of the team? How can be keep our morning scrum meeting time boxed?

Educating the team

Getting the top management to buy in was actually quiet easy, so to was the development team. However, everyone seemed to have a slightly different interpretation of Scrum. Of course this then produced mixed results like:

- Why do we needs morning scrum meetings when we can add all the work to trac and it can be monitored?

- How come we are not including the designers when we need to create GUI’s?

- User stories, story points etc what are they and we need hours!

These questions where later addressed too, but they were all fair points.

Sprint boards and tasks

To be honest, I found getting my head around user stories very hard. To me a task is a task, but creating user stories is a fine technique. Therefore tasks were usually a little to complicated and a little ambiguous. As of the sprint boards, sometimes task notes where tampered with and instead of having the notes in the order of the backlog they were very randomly placed.

The results

After 6 months and one scrum course I am now Certified Scrum Master. The course provided me with a wealth of information on scrum, not to mention the practical element showed me how to incorporate some of the practices. As a CSM I think everyone took me a lot more seriously which paved way for me to now fine tune the process.

The first problems that I addressed were the morning meetings and other small projects. Here I laid it straight, I ask the 3 quesitons and other than a reply no one should talk as we can arrange a meeting straight afterwards. Also, this was done standing around the sprint boards. Or other office based in Poland also joined in the morning scrum meetings as they too are part of the team. This resulted in a short and effective meeting, just like the scrum process dictates. The points as to why the relevant people have a meeting afterwards was to loose all the waste of everyone having to listen to a discussion that did not really effect them.

As of the other projects, we usually have 2-3 medium projects, then several tasks from many different projects that were mainly updates, added functionality, bug fixes etc. No book actually provided me with an answer. Therefore, the only thing i could think off is create an ‘other’ project that acted like any other project. This was welcomed and have been using it since.

The result of the problems were all overcome by simply educating everyone. To be honest we have seen vast improvements in our working practise. Some of the notable ones:

- Sprints on 5-10 days. Our clients instantly took to view and playing with the prototypes than the flat visuals that they were used to seeing. To quote one of the POs (as best as I can remember)
“We went over the visuals with the client, then before leaving I showed them the prototype and they loved it. I could tell they were still on the site after I left”

- Retrospectives formed an integral of the process. Having a retrospective after release highlighted all the pitfalls and good points through the sprint. It also serves as part of the documentation for ISO 9001.

- All management could see all the work being done at a glance by looking at the sprint boards. Also, the burndown charts are updated every morning so they are also aware of anything major, although just listening to the scrum meetings highlights this.

Another mis -understanding was using scrum along with scm tool. We use trac/svn as our source code management tool. Some of the developers though that just adding everything to trac without the morning meetings could be seen as more beneficial. But I reminding everyone of the key points

- Trac encourages collaboration to a certain extent, where scrum is total colaboration

- The PO’s don’t want to login to trac to see a list of tickets.

- Trac is for source code management, not managing the whole process.

- Problems would not be highlighted etc.

After everyone bought into this, a user story was accepted by a developer or pair of developers. They wrote the tests, documented it on the trac wiki and created their own ticket. Any additional information was added to the ticket and if needed the documentation on the wiki.

I have seen first hand how the process of just a system like trac in place can in fact let a project down.

Other things that I have learned as a result of trial/error, reading and attending events like the London Scrum Users Group.

When implementing scrum or introducing a client to scrum might help if you change the terminology. As we work with a lot of non technical peopel, the word scrum can scare people. Using words like process, release, release meeting, morning meeting, tasks etc masked the fact that scrum is present. I did find this useful and was something that I picked up from several people in the London Scrum Meeting.

User stories can be difficult to write at first. But after reading two books on user stories and agile estimation, some trial and error I finally sussed them, which had the benefit of more people understanding them and work being more accurate. A link to my linkedin profile and book review follows below in the list of other resources.

To use Scrum you either use it or you don’t. Of course implementing a few features can work but not as successfuly as following the process completely. One problem I encountered was slipping out of the process. One project suffered a great deal as a result of this.

Other resources
My linked in profile and book reviews

The london Scum Users Group linked group

The london Scum Users Group Wiki

In the new year, we have a few more developers starting at work and therefore this will be a test bed to see how successfully I can implement the whole of SCRUM. In July 2008 I will update this post about how I went on to fully implement SCUM and distributed SCRUM.

A few useful links:
CSM Courses
My Profile
Lean Software Development