XPDays London 2010 - an amazing event

| XPDay 2010 Wiki | XPDay 2010 feedback page |  

The 2010 XPDay in London was an amazing experience and my thanks go to the organisers and all the many people that gave great open space sessions and experience reports.

Not since the 2009 Lean & Kanban exchange at SkillsMatter have I been so engergised after an event (and I have been to quite a few great events this year). I feel I have learnt so much in these two days that it will take me all the holidays to digest (and blog about) everything.

The open space format worked very well for me and produced some great sessions. A great job by Mike Sutton for introducing the open space approach in a very clear way.

It was amazing to see so many people wanting to talk about such a wide range of subjects and it was often a challenge to decide what to go to, but as Mike made clear, it was easy for us to move between sessions.

I enjoyed giving my experience report on Taking kanban to the masses, where I describe some of the practices I have used to help convey understanding of the kanban method and how to visualise your work effectively. Hopefully will be able to catch up with the videos of the other experience reports on the SkillsMatter.com website. I liked the idea of having one organised track, to give you some up front idea of what could be covered in the open spaces.

As for the venue itself, I liked just using the upstairs rooms of SkillsMatter, it seemed to maintain a closeness throughout the two days and helped create a safe environment for people to share their thoughts and ideas. Good food for lunch too, especially the pasta.

The biggest challenge we had with the event was people judging the popularity of there talks. As the venue had one smaller room there was a few occasions where we had to swap. Perhaps we could do a quick raise of hand for those interested in a talk when put on the wall, so that popular talks are put in a big room.

I am really looking forward to the event in 2011 and would be interested in getting more involved, perhaps even helping organise the event.

Session Hightlights
There were so many great sessions on the day that I did not get to see everything I wanted. The session highlights that I remember so far and will write more on are as follows

Kanban 1's Game with Jon Jagger
Forward Internet 25 release per day with no unnecessary overhead
Ideal University course - lots of philosophy, learning how to learn, etc...

There are many more, including a few by Benjamin Mitchell that should be up there.  I did missed out on the session about personnas by Sarah Lawfull, so will be looking for a write up about that one.

Reading list for learning Kanban and Lean

On my way to understanding lean concepts through the use of Kanban, I have found books by the following authors invaluable:

Eliyahu M. Goldratt
Reading The Goal was a fantastic journey into thinking about lean without getting bogged down in anything technical.  The Goal is a great novel and a long way from a dull technical book, it really gets you thinking about the core ideas behind Kanban.  Following with a more specific book on the Theory of Constraints defines the lessons learnt in The Goal and adds ideas on how to manage your own constraints in the system.

David J. Anderson
David J. Anderson is one of those leading a march towards Kanban and Lean adoption in software development and his Kanban book is a great guide to applying Kanban to your existing process and identifying opportunities to improve.

Alan Shalloway et al.
The Lean-Agile software development book includes the experiences of the authors extending agile practices into the wider organisation by adding lean techniques to the mix.

Douglas Adams

Douglas Adams had a fascinating way of looking at the world and always came up with brilliant ways of conveying that vision.  The way that Douglas would talk through Dirk Gently about the interconnectedness of all things really did grow my ability to engage in system thinking.  Reading the two Dirk Gently books: Dirk Gently's Holistic detective Agency and The Long dark tea time of the soul will help get you in a lean thinking way.

There are of course many other good books on Lean, but these are the ones that have suited me best so far (although there is still a lot to read).

Introducing change effectively - All in, but not all a once

When it comes to managing change then what ever practices you decide to adopt, its preferable to take an "all in" approach, in that you get as many people involved as you can.  This does not mean that you have to adopt everything all at once, but helps you understand the big picture of change within your organisation.

An all in approach gets people involved from all aspects of the business (including revenue generating customers), so you understand the most important issues surrounding change within the business.

An all in approach helps you set meaningful goals that support the business value (e.g. your customers) and aim to extend that business value (e.g.. more customers, happier customers)

For example, if you make a decision that scrum has benefits for your organisation, it is better to get more people on board with adopting the idea of scrum than it is to adopt a full blown implementation of a scrum based process for a select few.

Although scrum is a framework, to get the most out of scrum you need to implement that framework in a way that increases the agility and effectiveness of whole company.  It is too challenging to go from nothing to a full blown scrum process in one day (or one sprint) as this would be too much change for most companies (unless you are already agile in all but name).

Adopting XP practices also take time to bed in, whilst most of these practices are pretty straight forward and easy to get going, they take a little longer to become natural and comfortable.  Adoption will be much smoother if there is an all in approach where everyone can see the point of these new practices (overal goals and values)

Adopting Kanban is relatively low impact at first as you are not trying to introduce change into your practices, you are simply trying to visualise and expose the relevant details of your current working practice.  Using a Kanban method approach to represent everything thats valuable with your practices in a way that is engaging to work with and highly representative takes time and should continue to evolve as your practices evolve.

London Software Craftsmanship community - first meeting

There was a great turnout for the first meeting of the London Software Craftsmanship community, close to a full house at our gratious hosts SkillsMatter.  The following is a summary of the first meeting talk and discussions.

The founders of the LSCc David and Sandro, laid out their ideas about software craftsmanship for the community to chew over and discuss - which members did with great vigour especially towards the end of the evening.

David and Sandro set the tone by annoncing that they are asprining software craftsmen and started the community to bring together lots of ideas share experiences as to what that means.

Some scene setting by David, discussing how programmers are often used just like typists, when really development is an artistic process.  Terms like software factory are not what the industry is about and focused on the wrong things.

Warm-up
There was a bit of exercise to warm the audience up, getting us all to stand up to figure out just what sort of audience was attracted to this event.  It was good to see a mixture of developers, testers, coaches, analysts and even a CEO.  There was a big contingent of Java developers and quite a few .Net devs even thought there was the LDNUG event the same time.  It was good to see developers from the python, perl, android and even Erlang space too.  There was a nice mix of age groups, quite a few in the over 30 camp but also university students and recent grads.

The talk proper started with an example of how software engineering practices were introduded at NASA, allowing them to  deliver 42,000 lines of code with only 17 bugs - the only problem being this cost them $35 Million per year and projects were always delivered late.

Raising the agile model, this was portraied as a very productive time for those teams that really understood the principles and practices that agile estolled.  Software craftsmanship was not portraied as a replacement for agile, but perhaps as a way to help us get back to thinking about the core principles and practices of agile that may be forgotton as agile spreads and transforms into "wagile".

The good enough approach is not always good enough and it was felt that many agile projects are now, steadily and iteratively producing mediocre software.

The idea
So, is Software craftsmanship the new shiny toy on the shelf that we all want to play with or does it have something meaningful to say?

David introduced a quote by Robert C Martin:

"The original torch of the agile message has changd hands to the software craftsmanship movement"

and refered to the wikipedia entry on Software Craftsmanship.

Delving deeper it was not portraid not as a certification process, a training course, a book, a tool or specific technique.  Simply it is something that you are, the way you approach your work, treating software development as an art, a craft, something you care about.

The Manifesto
The desire to raise the bar of professional software development by practicing it well and heling others learn the craft was expressed in the creation of the manifesto for software crafstmanship:

• Not only working software, but also well-crafted software  -- it should be as easy / enjoyable to work on an old project as a greenfiled one
• Not only responding to change, but also steadily adding value - extending the life of your projects
• Not only individuals and interactions, but also a community of professionals - helping each other develop our craft
• Not only customer collaboration, but also a productive partnerships - we need to help our clients / employers to value better understanding and better solutions

So what does it take to craft software?
Offered up were the concepts of creativity, judgement, theory and practical skill.  Understanding that continuous improvement was seen as the most highly valueable goal, as there are always more things to learn.

One of the most common ways to practice the craft was to undertake deliberate practice - via coding and architectural kata to practice the are, coding dojo to learn language design, and code retreats to learn good design via test first development.

The Journey
Software craftsmanship talks about a journey from apprentice, to journeymen and then master.  The apprentice experiences more learning than teaching and is mentored closely by a master.  The journeyman has responsibility to take on projects unsupervised and works for many different masters to broaden the range of their experiences.  It was commented that the journeyman was best placed to move the industry forward as they have a broader view than a master.

Sandro talked about how you dont have a control over becoming a master - it is driven by the community who look to certain individuals that are perseved as being highly experienced in a particular area.

These labels whislt interesting to talk about how you travel along your journey are not in themselves an important aspect of software craftsmanship.

In summary
The great conversations continued in the "SkillsMatter" pub, The Slaughtered Lamb and there was a lot of merry making going on there after the event.

For myself, a simple way of thinking about all these concepts software craftsmanship is to consider being "responsible", taking actions that are the most responsible thing you could do at the time within the constrains put upon you whilst still delivering value.

Understanding can be difficult if there is confrontation!

When trying to share some knowledge or raise issues, I try to lead the audience (audience being an individual, team or community) on a thought trail rather than pointing out issues directly or just imparting the answer.  By laying out a path of thinking, the audience is more likely to engage with the concepts or information you are imparting and become involved in path to the answer.  Once on the path, the audience is more likely to accept the outcome.

Okay, so how do you start a thought trail, it sounds like a long, drawn out, boring process!
Start with the problem statement !!!  rather than a question ???

Using the Socratic method of understanding is beneficial to the person who is playing the role of Socraties as they are able to drill down in to the real meaning and understanding of another person.  However, asking a hard question (Why often being a hard question at times - if you don't know why you do something) and making people feel they should have the answers at their finger tips is not as conducive to knowledge sharing or collaborative problem solving

Empathise with the audience that have the problem, make that audience feel you are or have been in their situation, this will make them feel warmer and more receptive to what you have to say.

Example:
Socratic Question: Why are you talking to a reporting copy of a 3rd party database that is a day old rather than talking to the application in real time?

Empathy statement: I am concern that we are doing a lot of work to integrate with this application and the information may be out of date.  If the schema changes then we may have a broken system and have to carry out a lot of rework under pressure from our angry customers.  If we were able to talk to the application directly and ask it questions, perhaps that would require less setting up and would be less likely to change.

The Socratic question, whilst perfectly valid, puts potential conflict in the way of the problem space.  You can often make the person you put the question to feel that they are to blame or have made a stupid mistake.  If the person is made to feel uncomfortable or in the wrong, then they are less likely to work with you or listen to your advice to resolve the problem.

Using the empathy statement, you have asked the same question, but have asked the person to go on a journey with you to understand concerns of the problem raised and evaluate whether a different approach has merit.  The person is encouraged to feel part of the solution, rather than being the cause of the problem.

In writing this article I started to break the premise of the piece by using a title that was a Sochratic method style question: Empathy over Sochratic method?

Instead, I went for the title: Understanding can be difficult if there is confrontation!

I wrote this article after reading the preface of The Goal by Eliyahu M. Goldratt and Jeff Cox.  The preface is describing the style of the book which is in the form of a story.  The preface states that this has been an effective book style to get across the many issues coveres in an engaging way.

Some thoughts on Limiting work in progress (WIP)

Limiting your work in progress (WIP) has several benefits I can think of in making individuals and teams more effective

Maintaining Focus
If you regularly have to switch between tasks to get something done, or worse still some outside force is causing you to constantly switch, it is much harder to focus on the individual pieces of work.

When there is a lack of focus, mistakes are more readily made or aspects missed from the work.

Reduction of work / thinking time duplication
When it comes to knowledge based tasks, switching between different tasks has a significant time cost associated with it.  If you start working on some task that is going to take a half day to complete, but after a couple of hours have to work on something different, a significant amount of time is required to get back to where you were with the original work.

Working on one task until it is ready to pass on to the next stage gives better feedback on how long that type of activity can take.  Better feedback helps you more accurately adjust any estimation you are required to provide.


Maintaining a good flow of work
Switching between tasks interferes with the flow of those tasks and can delay work being completed at the perceived time. Any planning and estimation done prior to the work may not be judged correctly if you do not include time wasted due to task switching.

If you minimise your work in progress and only work on one task at once it is easier to get accurate measurements of time required to complete each task, giving better feedback to your planning and estimation activities.


Avoid building a psychological mountain
If you have too much work or you see the work as to vast or complicated, there is a natural tendency to be overwhelmed or demotivated by the scale or complexity of the work.

Humans can process more work when it is viewed as small and not overly complex.


Technical Debt / Stale work
If you have a lot of work that is in progress, then the effort already invested into it has yet to deliver any value to the customer (in a personal Kanban, the customer may often be yourself).  The more work in progress you have therefore means more investment without return of value.

In manufacturing, if you have a high investment (inventory) without delivering any value (sold products) then your business is not being effective.

In software development, if you have a large number of requirements (stories, use cases, etc) in various stages of development, then that is a considerable investment made without that software realising those requirements in the hands of the paying customers.

If you minimise the overall work in progress you have less investment and less risk should there be a change to the project.

Summary
There may well be other benefits to limiting your work in progress, but this is all I can think of for a wet Sunday afternoon.  If you can suggest others, I would be most interested.

Thank you.

Reading list for learning Kanban and Lean

On my way to understanding lean concepts through the use of Kanban, I have found books by the following authors invaluable:

Eliyahu M. Goldratt
Reading The Goal was a fantastic journey into thinking about lean without getting bogged down in anything technical.  The Goal is a great novel and a long way from a dull technical book, it really gets you thinking about the core ideas behind Kanban.  Following with a more specific book on the Theory of Constraints defines the lessons learnt in The Goal and adds ideas on how to manage your own constraints in the system.

David J. Anderson
David J. Anderson is one of those leading a march towards Kanban and Lean adoption in software development and his Kanban book is a great guide to applying Kanban to your existing process and identifying opportunities to improve.

Alan Shalloway et al.
The Lean-Agile software development book includes the experiences of the authors extending agile practices into the wider organisation by adding lean techniques to the mix.

Douglas Adams

Douglas Adams had a fascinating way of looking at the world and always came up with brilliant ways of conveying that vision.  The way that Douglas would talk through Dirk Gently about the interconnectedness of all things really did grow my ability to engage in system thinking.  Reading the two Dirk Gently books: Dirk Gently's Holistic detective Agency and The Long dark tea time of the soul will help get you in a lean thinking way.

There are of course many other good books on Lean, but these are the ones that have suited me best so far (although there is still a lot to read).