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