XP Day

This was my second year at xpday and I can honestly say it excellent. This year’s programme really suited my personal agenda of lean software development, kanban and test driven development (TDD). Also the programme’s open space structure changed, but in a good way for me. The open space sessions occupied most of the second day this which I personally thought was good, as last year the open sessions where spread over both days. This ment that it was possible to get into more sessions as there where less of them.

XP Day 2009 Day 1 (Monday 7^th)

Mark Striebeck from google on – Developer Testing: From the Dark Ages to the Age of Enlightenment

Excellent talk on some of google’s testing strategies and just how serious google take testing. Some of the key points that I walk away with are:

• Identifying what is a good test – Using both devs and BA to say exactly what the tests should cover as there is no point writing a test if it produces no real value.
• Make code testable – Following test driven development (TDD) for example to write tests first before refactoring.
• Finalise and publish test results – Making all stake holders aware.
• Provide tools that integrate with the work flow – There is no point changing your work flow if it is not needed. In most cases tools can be integrated.
• Estimate costs for bug that are found – This I think was key when thinking of your testing strategy from a business point of view. Not only is code and rework affected, but other hidden items such as fixing the bug, re-deployment, re-testing etc.

Kanban Creation Workshop: Karl Scotland and Xavier Quesada Allue

Just by reading the title of this talk and seeing Karl’s name there too meant I made sure I was the first in the room for this. Both Karl and Xavier began with a brief introduction of kanban and the five elements:

1. Map the value stream
2. Visual the stream
3. Set the work in process (WIP) limits
4. Establish cadence
5. Reduce the tokens

After a small example of how to map the value stream, we where given an array of stationary and told to create our own kanban board based on a fictional project. There were four groups all trying to achieve the same goal, and it was amazing to see that we all came up with something slightly different yet we were all right.

Resources

Agile Management

Kanban for software development

Focusing On Delivery: Evolving from Scrum with Lean and Kanban: Benjamin Mitchell

This is the second time I have met Benjamin, and his talk was excellent. It was based on his experiences as a project manager who has implemented kanban in the work place. What I found interesting was all the data that he had collated and presented in meaningful graphs. This showed me just how important it is to collect and present data. In Benjamins talk he showed to us captured data like:

• Cumulative Flow Frequency
• Issues resolved
• Time from development start to integration testing
• Types of story by release
• Team waste

In a lean environment I can instantly see how data such as this can be used to make the process more lean.

XP Day 2009 Day 2 (Tuesday 8^th)

The second day

Tuesday was mainly open space and there were some really good topic of conversation. The ones that interested me

Agile testing

Although starting off slow, really got doing and nearly over run time. We mainly discussed various ways in which testing can and should be applied. A few points that I picked up are:

• Including BA’s in the design/testing phase.
• Root cause ananlysis on bugs to eliminate bug re-occurance
• Using Story Driven Development SDD
• Automate as many tests as you can.
• There is no point having 100% code coverage if the test’s that are written do not really work.
• Its the developers responsibility to fix any problems.

Resources:

London Agile Testing

Testing for web applications

Another interesting talk on vairous ways to test web applications. We are all in agreement that functional tests should be written. However manual testing over automated selenium testing was a debated area mainly between me and the rest of the group. The debate was the system should handle events though the web application’s framework because it can be tested. The problematic area is that its not easy to do with a Web 2.0 application. Further more, I later discovered that most of the people there all worked on large in house systems, not user facing web 2.0 applications. The out come was that it was more economical to outsource the manual QA

The yellow brick road

This was a very interesting practical lesson on agile coaching. We basically played a game which was themed on the wizard of OZ. We all had three people in the group and took it in turns of being the coach, client and listener. I found it amazing that just by listening and asking relevant questions, you can extract a great deal of information from a person.

Resources

The yellow brick road

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