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).

Agile Fairytale - stories to express agile concepts

Agile fairytale is a neat way to express agile concepts in a way that is easily understood, using a context more likely to be meaningful or recognisable to a wide audience.


At the heart of Agile Fairytales are three fundamental concepts:

• Agile Values - Agile Fairytales extends the 5 Agile values of Communication, Simplicity, Courage, Feedback, Respect to include Trust and Transparency and applies them to real life
• People - Agile Fairytales is based on the belief that we can all change for the better
• Continuous Improvement - Agile Fairytales encourages us to improve one step at a time

A Creative Thinking Tool

Agile Fairytales uses simple narratives to structure the way we look at problems. Each fairytale is designed to give us insights into our experiences through a better understanding of ourselves.

When to Use Agile Fairytales

Agile Fairytales are useful in the following situations:

• As an icebreaker
• When creating a new team
• For improving the performance of team members
• As a game with friends and family

Interesting presentations from Agile2010

Here are some presentations I found from the Agile 2010 conference:

Business value modeling - agilecoach.com

QCon brainstorming night

Thanks to the hospitality of the QCon organisesrs, last nights QCon brainstorming session was a great event. As well as all the great discussions going on, there was a seriously generous helping of really nice food and what seemed a never ending supply of drinks.

QCon is a regular event aimed at those interested and engaged in enterprise software development.  The event aims to provide the highest quality presenters and most engaging topics each year.  Previously the QCon schedule has been organised from the input of those wishing to present, but for QCon 2011 the goal is to include ideas and recommendations from the community of people who pay to attend QCon when deciding on the schedule.

There was over 30 people that turned up and it was a great atmosphere. I turned up there early (no surprise) with a friend and we were greeted by our very friendly host, Jørn Larsen (on the far right of the picture).

The evening started with all of us grouped around a big table with lots of flipchart sheets and post-it notes.  As not everyone was lucky enough to make QCon 2010, we briefly discussed QCon and the different types of days and event that typically go.  Usually there are two days of tutorials before the main conference, with the conference itself having a large number of tracks each day (see QCon 2010 tracks).

For the brainstorming proper, we started creating lists of topics we thought would be good for the next qcon event and also identifying any speakers we thought were really good at presenting and generally entertaining the crowd.

I started the ball rolling by writing down some ideas, although half way through writing my first idea I had a feeling that everyone was watching me.  When I looked up everyone was watching me, but got on with adding my crazy ideas and this helped encourage everyone else to do the same.

Very quickly there was a wealth of ideas that came poring out and after I had run out of ideas myself I started writing down lots of ideas that people were discussing as them to make sure they were captured.

We also had a kind of retrospective sheet where we could put post-it notes on for things we wanted to see more of or less of, as well as things to start doing and stop doing.  The funniest comment I saw was to "Stop giving uncle bob martin a small room" - alluding to the fact that he is always a popular speaker and you cant always get in to see him.

All the flipchart sheets got stuck to the wall and we churned out dozens of sheets worth of ideas.  However, it all kind of got put on hold when the first wave of food turned up.  Yes, there was so much food that it did come in waves.  No one went home hungry and even I was too full by the end to want a doggy back to take home what was left.

There were lots of great discussions happening, its a shame we didn't record them for AppleTV!!  There was a continuing trickle of ideas added in between the food, drink and chat until the end of the evening.

Jen and his team now have a very busy few days going through all the weird and wonderful ideas that the group came up with, including all my Kanban, lean system thinking, rightshifting and continual improvements suggestions (I think there was a whole page just on those).  If even just a small part of the ideas we all came up with make it in then QCon 2011 should be a really great event.

If you want to know more about what may be appearing at QCon 2011, you can have a look at the tracks for QCon 2010. The most interesting ones for me were  Agile Evolution, Software Craftsmanship, Dev and Ops: A single team and Irresponsible Architectures & Unusual Architects