You are invited to propose a session for the first day of the conference. They’re are particularly interested in the following

• Experience reports—share your stories of challenge and success with Agile and Lean techniques. Experience reports will be intensively shepherded by experienced practitioners.
• Hands-on technical sessions—share techniques and practices in practical sessions: workshops, tutorials, simulations
• Practitioners’ advances in the art—share the techniques of expert Agile and Lean practitioners, work with them to move the craft forward.

The second day of the conference will be an OpenSpace session with topics selected at the end of the first day. Programmed sessions are most suitable for topics requiring some set up or extensive preparation.

To submit a session, please go to http://xpday-london.editme.com/XpDay2009Submissions

Submissions will be accepted until Friday 14th August.

One of the most interesting things he said was that when they were coming up with the name for what they were trying to promote they considered “agile”, but thought it would be too difficult to sell and so decided on Lean instead. Also, he didn’t have much understanding of modern software development, but at a glance saw very little difference between what we called Agile and he called Lean.

So when we talk about Lean Software Development being an Agile methodology we’ve got it the wrong way around. Agile is Lean, Scrum is Lean, XP is Lean. You were already doing Lean Software Development, you just didn’t know it!

In my mind it’s time to drop the titles (which all carry too much stigma) and simply start referring to it as professional software development.

It followed the same format as the previous time I ran it so you can go there to find the slides etc.

Here’s the output from the discussion. I’m running this session again at SPA 2009 and after that I will collate the output from all three into something coherent and useful:

How do you keep the context stable?
The problem is managing the context. If the business says you need to do it sooner that changes the context.
What about if the business doesn’t have the full context? What about issues you don’t know about?
Why are we different to any other type of organisation?
It’s too difficult to estimate more than 2 months ahead
Familiar work is easy to estimate, the unknown is not (which is mainly what we do)
If we report back to the business regularly they can’t deny hard facts
Manage the risk by working iteratively
It’s quite common for people to start building skyscrapers before the architects finish designing the top

• but their customer’s not going to ask for another 20 floors and more space halfway through

We need to help the customer understand what they need
People need to know whether it’s a viable business case
Projects are never agile if you have requirements up front (fine if nothing changes though)
You should only commit to work three months ahead
“2 years” for a software project is too long – will not be competitive
Movies spend a long time in development, then they get the budget and the scope gets cut to fit. But, they are more predictable than software.
Too much money (e.g. banks) will never produce good software – scope to big.
Are big estimates/commitments ever believed by anyone? Often they’re only used to make projects viable
IT departments are not pushing back enough – should never suggest you can plan more than 3 months in advance
2 types of estimation:

1. The real business of estimation (e.g. stories, iteration scope, tasks ect)
2. The game of estimating within the business context

Agile projects are rarely ever really agile as they’re operating withing the context of the business/traditional practices.

We were also honoured with a keynote from the inventor of Lean, Jon Daniels and his colleague Marc Baker who gave us a frightening insight in to the state of the NHS and how Lean practices are having dramatic effects, but I want to post separately about them.

Other sessions:

Software Craftsmanship

With Jason Gorman’s software craftsmanship conference coming up in the new year, John Daniels wanted to talk about what craftsmanship meant to us. It was a really interesting discussion and the general feeling was that people were uncomfortable with the idea that we could define what it meant to be a software craftsman as there are far to many skills and too much diversity in the types of these skills. This was summed up well by the following: To explain what a craftsman is, Keith Braithwaite used the example of his uncle(?) who has been a farrier for most of his life with people coming to him to learn the skills, yet he only considers himself a journeyman and we explored the similarities/differences between what he did and what we do. In the end someone came up with the excellent point that we don’t make and fit horseshoes, we build cathedrals and there are so many different skills needed (which change all the time) we could never be expected to “master” them. I’m going to Software Craftsmanship 2009 and I look forward to seeing how it pans out.

Why aren’t they typing more?

Douglas Squirrel asked us how we deal with people asking unanswerable questions like “why aren’t they typing more?” and “you need to focus on productivity rather than agility”. There were lots of interesting ideas, but the most revealing one for me was that we need to be able to deal with people rationalising rather than being rational (e.g. the idea that being busy = productivity). Someone mentioned a book called Predicably Irrational which investigates this phenomenon (and I shall add to my reading list). Most of what we do within an agile context flies in the face of conventional wisdom and is very radical compared to the most of the organisations we work with/within. I think this is a problem as a community we need to spend more time looking into.

Not only that but I will also be presenting at XPDay in December! The session is called “Using lean to evolve out of Scrum” which was the brainchild of Matt Wynne and based around our experiences working together on a project.

Gobsmacked I am.