The programme for this year’s XPDay conference in London on 7th & 8th December has been published and it looks like it’s going to be a tub thumper. As well as lots of interesting programmed sessions (with an emphasis on experience reports and technical/programming), there’s not two but three keynotes this year including Dorian Swade on what we can learn from Charles Babbage and a story teller called Terry Saunders, who probably wonders what the heck he’s doing there, but will no doubt provide a welcome diversion from the usual topics. Also, after the success of last year’s open space the second day is pretty much wholly set aside for open space sessions.

On top of all that there’ll also no doubt be lots of entertaining conversation to be had after hours on both evenings in nearby pubs.

Tickets are on sale for £350 for both days which is by far the cheapest conference I’m aware of (as well as also being the best ;-)).

I will also be involved in a session, “Introducing Lean and Agile Practices to a Chaotic Environment” where, along with some of my colleagues (not just developers!), we’ll be discussing how our practices have evolved over the last 12 months. Hope to see you there.

I’ve done this one a couple of times now and had postive feedback both times. It’s a good alternative to the shuffling-cards-around-style retrospectives as it mostly involves talking (albeit in a controlled manner).

You can read about De Bono’s 6 Thinking Hats on Wikipedia where it is described as: “a thinking tool for group discussion and individual thinking. Combined with the idea of parallel thinking which is associated with it, it provides a means for groups to think together more effectively, and a means to plan thinking processes in a detailed and cohesive way”.

Use

The description above sums it up and as I said it’s a good alternative format to more familiar plans

Length of time

Approximately one hour but can be tailored to your needs

Short Description

The team discuss the previous iteration whilst all wearing one of De Bono’s “hats”. They then do the same but wearing another hat until all the hats have been worn. The hats relate to particular ways of thinking and force the group to collectively think and discuss in a particular way. The facilitator documents any output on a whiteboard. The ouput from the last hat (Red) is converted into actions.

Materials

A large whiteboard and 6 coloured cards (one for each hat) and a room with space to arrange chairs in a circle (no table).

Process

Preparation

Arrange chairs in a circle so all the participants are facing each other. Put the colored cards along the top of the whiteboard in order of hat wearing (see below). Be familiar with all the “hats”.

Introduction

Once everyone is seated introduce the exercise by giving a brief summary of De Bono’s Six Thinking Hats process. Then explain that the group will all put on the same hat and discuss the iteration (what went well, want didn’t go so well, what can we do to improve things) for 10 minutes and after that they will put on the next hat in the series and so on until the all the hats have been worn.

Very Important: If at anytime anyone starts talking in a manner not appropriate for the current hat interrupt the discussion and say something like: “That’s great Black Hat thinking, but we’re not wearing that hat right now. Remember, we’re wearing our Green Hats which are about alternatives and learning so please try to discuss the subject in this manner”.

Tip: The facilitator should try to stay out of the circle and try to avoud the participants talking directly to them. This is tricky as people have a habit of watching what you’re writing on the board. Try to block the board so they’re not distracted.

Order of hats

According to Wikipedia the order of hats most suited to process improvement is  Blue, White, White (Other peoples views), Yellow, Black, Green, Red, Blue but for this exercise we will use:

Blue, White, Yellow, Black, Green, Red

Blue Hat (5 minutes)

Use the blue hat to discuss the objectives for the session and write the output on the whiteboard.

White Hat (10 minutes)

Participants raise  and discuss anything from the last iteration which can be said to be a fact or information. Hunches and feelings and any discussion of reasons or other non information based output should be left for the appropriate hat.

Yellow Hat (10 minutes)

Participants can only talk about the good things that happened in the last iteration.

Black Hat (10 minutes)

Participants can only talk about the bad things that happened, any negative criticism they have or worst case scenarios they can think of.

Green Hat (10 minutes)

The discussion moves on to any ideas people have about solving problems or things that may add more value to the business or help in any way. Outside of the box helicopter view blue sky thinking is encouraged.

Red Hat (5 Minutes)

Give the participants a short period of time in which they can come up to the board and write down 2 emotive staments each. These could be the issues that have stood out for them the most or an idea for solving a problem. These statements should be instinctive which is why you will give them very little time to do this.

Conclusion and Actions

Spend a little time as a group having a look at the Red Hat output. Are there any themes? Do any of them have relationships to each other. Do any particularly stand out? From this get the group to decide on a couple of actions to take away. As always ensure the actions are very easy to execute (so nothing like “write more unit tests” or “refactor the database” and more like “try to write test first this iteration” and “arrange a meeting with the DBA to discuss a strategy for refactoring the database”).

Sometimes we want to test some really nasty legacy code but are inhibited by constructors taking tricky things like HttpWhatevers, God objects and so on which you do not care about but would require enormous effort setting up just to try and get an instance of the damn thing so you can test your method.

One way out is to create a parameterless constructor on the class which is only used for testing. Not at all nice, but sometimes necessary to create that first seam.

A candidate I was pair interviewing with introduced me to something which may prove preferable in these cases – the Microsoft serialization library has a method which will initialize a class without calling the constructor:

FormatterServices.GetSafeUninitializedObject
http://msdn.microsoft.com/en-us/library/system.runtime.serialization.formatterservices.getsafeuninitializedobject.aspx

This way you don’t have to modify the code!

I would only ever advise using this if your only other sensible option would be to override the constructor. Hopefully once you have your tests you would be able to confidently refactor out the problematic code.

The most obvious refactoring analogy I can think of is communal areas such as the kitchen of a shared flat. It’s everyone’s responsibility to keep it clean but often it quickly gets in a mess because people don’t bother to clean up after themselves. Sure, the cycle time to getting a meal may be quick, but after a while the kitchen becomes unusable. Finally a huge amount of effort has to be put in to cleaning it as some of the dirt such as on the cooker is really caked in by then. Other things are beyond cleaning have to be thrown away altogether.

Yesterday I spent a few minutes tidying the bookshelf at work. There was stuff on the shelves which shouldn’t have been there such as screws and mobile phone chargers ( commented out/redundant code), planning stuff spread across multiple shelves and mixed in with books (poor cohesion) and various colours and sizes of index cards in big unsorted piles (obfuscated unreadable code).

The same principles apply – leave it in a better condition than you found it. Be considerate of your colleagues and everyone benefits.

If you’re interested in working for the second biggest music download provider in the world, with an Agile and learning culture based in the coolest area of London (the Silicon Roundabout) we have openings for:

Quality Analysts/Testers

Developers

User Experience Developer

If you know me personally please get in touch, otherwise go here for more details:

http://www.7digital.com/business/careers

Please do not bother if you are a recruitment agency, seriously. You will be wasting your time.

If I was going to offer one piece of advice to anyone aspiring to be a top class software developer* (apart from writing lots of code) it would be to read books. Not just any books though, books written by masters.

Experience often counts for little in software development. If you’ve spent your whole career in the same shop with little exposure to other languages or people outside your organisation it’s quite possible that some 21 year old upstart with a copy of Clean Code under his or her arm will wipe the floor with you when it comes to effectively writing and maintaining software.

Granted, working with good or even great developers will mean a lot will rub off on you. I’ve learnt countless lessons from the people I’ve worked with, but if I look around me people are no older than 30 at most with an average of around 5 years developing software in probably no more than 3 different organisations.

People like Martin Fowler, Eric Gamma, Kent Beck, Robert C Martin, Craig Larman and Michael Feathers have been at it for 25 years or more and in that time have slowly built up the kind of reputation you only get from regularly being right.

Also granted, blogs are are an invaluable resource, but are rarely little more then a meme in someone’s head and give you nothing like the deep contextual insight you can get from a well written book. There is also little to assure you that the author is anymore likely to have a better idea than yourself. Believe me when I say there are many people blogging who rarely live up to the practices they preach and are no more or less likely than you to know the right or wrong way of doing something.

I have learnt a lot from both colleagues and blogs, but both pale to what I’ve learnt from the books I’ve read. I can comfortably say there is no way I would be where I am today without them and I strongly believe it will earn you more money. When you think of all the things you could do to try and put more folding stuff in you’re back pocket it’s a relatively simple win!

I’ve been inspired to write this after reading Eric Evans Domain Driven Design which has gone right into my top 5 books of all time. Why is it so good? It’s not because Eric has necessarily been born with some supernatural instinct for writing great software or that Domain Driven Design is going to save the planet. It’s because it’s full of the lessons that Eric has learnt in his long and illustrious career, carefully woven into a highly readable narrative. There’s nothing particularly new here. Like all the great books I’ve read it is no more than a distillation of the practices in the industry which through time have proven to be the most effective. I remember Martin Fowler once saying that people often asked him what would be the future of software development. His answer was that to see the future you only have to look to the past.

Below is a list of the books which significantly changed the way I think and work more than any other’s I’ve read. No doubt you’ve heard of them all already and are on a list of books to read in the back of your mind somewhere and I’m sure there are plenty of others that had as significant an impact on people as these have on me. However I think few will argue that any of these books do not deserve their place on this list. All I can say is get on and read them if you haven’t already.

Refactoring: Improving the Design of Existing Code by Martin Fowler
Domain Driven Design: Tackling Conplexity in the Heart of Software by Eric Evans
Working Effectively with Legacy Code by Micheal Feathers
Agile Software Development: Principles, Patterns and Practices by Robert C Martin
Clean Code: A Handbook of Agile Software Crafstmanship by Robert C Martin
xUnit Test Patterns: Refactoring Test Code by Gerard Meszaros
Lean Software Development by Mary and Tom Poppendieck
The Toyota Way: 14 Management Principles from the World’s Greatest Manufacturer by Jeffry LIker

*I am in no way professing to be a top class developer 🙂

Submissions are now open for programmed sessions at XpDay London 2009, to be held 7th and 8th December 2009. http://www.xpday.org/

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.

There isn’t any.

Certainly not enough to be able to draw a clear line between the two and start comparing the benefits of one against the other. Daniel Jones, the author of The Machine That Changed the World did a keynote at XPDay2008 and said from what he saw there wasn’t really much difference, apart from the name. In fact, when they were looking for a name for Lean they thought about using Agile.

Agile came from Lean, the related processes came from people studying Demming, The Toyota Production System or through convergent evolution. The two guys who invented Scrum are Japanese and that’s no coincidence.  When I started reading about Toyota and Demming it all simply made sense to me and explained where Agile came from.

Then I found an article written by Craig Larman on the history of iterative development and that wrapped it up: http://www2.umassd.edu/SWPI/xp/articles/r6047.pdf

There is no point spending any time discussing and trying to find differences between what is essentially the same thing just written in a different way.

It reminds me of how the Jews and Christians went their separate ways and then came the Muslims and then they split up into the Sunni and Shia’s. They’ve all been fighting bitterly for the last 2000 years but all worship the same god. Go figure!

It seems these days there are countless methodologies, processes and practices to choose from when developing software and, somewhat ironically, the list seems to be growing at the rate of Moore’s law. I’ve read about, discussed, been on courses and been to conferences about a lot of them and the thing I’ve consistently found most useful is talking to other practitioners about what they’re doing and what’s working (or not working) for them.

Recently there’s been a lot of (and subsequently criticism of) debate on message boards and blogs about the relative benefits of one paradigm versus the other.  Personally I don’t care much for subscribing to any particular paradigm and am much more interested in what works and what doesn’t (and in which circumstances) so my response is to publish what my team and company is actually doing right now. This is a snapshot of our current practices. Ask me again in 6 months and hopefully I’ll show you something very different.

The inspiration and influences for the way we work mostly come from Agile, Scrum, Extreme Programming, Software Craftsmanship, Lean, Lean Software Development, Kanban Software Development and The Toyota Way. It is all and none of these things.

Context

We are a small to medium size “start up” organisation working in the new media industry. The company employs around 60 people mainly based in the UK. The development department numbers around 20 co-located people. Agile practices are a relatively new introduction and the previous approach was of the typically chaotic type familiar to young businesses.  We mainly work in .Net using C# but also dabble in Ruby, Javascript and UI languages. The rest of the article mostly relates specifically to one of the teams working within the department but also addresses some of the practices of the department as a whole.

Team

The team is made up of 4-5 developers and a tester. There is no project manager at the team level – in the spirit of self-organisation (principle 11) the duties traditionally the responsibility of a PM are shared between the team members. The Product Owner role is shared between the stakeholders within the organisation for the products the team is responsible for.

Iterations

We currently work in 1 week Iterations. It’s a new team who are also new to many of the agile concepts and doing this enables us to control the amount of work in progress, focus on delivery, improve our discipline and most importantly have short feedback cycles so improvements can be discussed and applied frequently. The downside is the overhead created by the amount of meetings. Once we’re comfortable the team is working well together we will have the opportunity to change this if desired (e.g. Continuous Flow, changing the iteration length, changing the frequency of meetings).

Meetings

Each iteration we have the following meetings:

Work Prioritisation – occurs iteration minus one. Stakeholders come together to raise and prioritise work not yet commited to.
Requirements Gathering – occurs ad hoc when necessary. All the team is required to attend along with the customer/s to bash out requirements for work prioritised in the prioritisation meeting.
Planning – occurs at the beggining of the iteration. Prioritised features (MMFs) which have been analysed are broken down into stories, discussed, estimated and commited to based on our current velocity (avg. over last 6 weeks)
Stand Up – occurs daily at 10am at the task board. Anyone outside the team is welcome to watch
Retrospective – occurs at the end of the iteration. Any actions from the meeting are to be completed by the end of the next iteration.

Requirements

Features are requested at the prioritisation session and use the User Story format.

More detailed requirements are gathered during the requirements meetings mentioned above, with the customer/s and all team members present. We use whiteboards to bash out the requirements and convert them into acceptance criteria using the “Given, When, Then” format. We have a rule that no work can be commited to unless we’re happy we have a clear understanding of the requirements.

Task Board

The task board is essentially a Kanban board with each stage of the delivery process separated into columns. We have an implicit limit of 2 stories in active, but otherwise have not applied limits to any other columns. Features (MMF) are blue, the stories which make up the MMFs are yellow, bugs are pink and quick support tasks white. When a story is commited to, the feature card is moved into “commited”, above the titles of the columns and tracks the last related story.

Measurement & Metrics

We use an Excel spreadsheet to hold the product backlog and track the data from the Kanban/Task board. Whenever an MMF moves to another column the date this occured is recorded. You can download a copy of the spreadsheet here (you may want to check the calcs on the CFD, not sure they’re right). Among other things it calculates average cycle time, average velocity and projections based on velocity. I’ve tried a few bespoke tracking tools (such as Mingle) and found nothing is as powerful and flexible as Excel.

We have a manual Cumulative Flow Diagram (CFD) which each team member takes turns to update daily so everyone shares the responsibility (it is also their job to update the Excel spreadsheet each day). The CFD diagram only tracks the value delivered to the business (one unit = one MMF. Measure the output, not the input) and is also represented in the Excel spreadsheet. Why have both you may ask? Visibility.

We have some rudamentry code metrics set up through our continuous integration framework such as NDepend output and test coverage but are working towards something more visible and useful.

Estimation

Still very much a necessary evil.

For comitting to work for an iteration we use Story Points using the fibonacci (1, 2, 3, 5, 8…) sequence and achieve them by playing Planning Poker with everyone who may be involved in the work required to take part. We will only estimate (and commit to) work we have already analysed and gathered requirements for.

For longer term planning, as we don’t yet have enough information to be able to use cycle time for projecting work completion, using the velocity based on points completed per iteration has proven a very powerful toool to be able to give the rest of the business a better idea of our capacity and timescales (previously they had none). However this has well known drawbacks and we must be careful it does not get abused, as I have seen before (such as gaming of estimates, whether intentionally on subconsciously). Also, as we need to understand and have gathered the requirements to be able estimate this way it means there is very limited scope to how far into the future we can do this with any degree of confidence (as requirements will change). Once we have a reasonable amount of data in the system we will be able to use average cycle time, which will be much more powerful.

Coding Practices

Apart from the rules we’ve commited to as a team, Pair Programming, Unit Testing, Refactoring and the best working principles and practices of the software industry are encouraged from the top of the department and applied rigorously but pragmatically.

At the request of the department members (as a result of a disucssion on collective responsibility) we created a development standards document which includes topics such as naming conventions and testing. As much as possible the document is vague on implementation details to prevent it from holding us back when better working practices come along. We use shared Resharper and Visual Studio settings to help us keep to these standards.

As mentioned below we also frequently hold sessions to improve our skills.

Automated Testing

All new or modified code is covered by unit tests, integration tests (such as database interaction) and automated acceptance tests which test against the acceptance criteria (this last one is quite new territory).

Continuous Integration and Deployment

All projects are under continuous integration (we use TeamCity) and we are working towards having all deployments doing the same. We have monitors on the wall which show all the currently failing builds. Do I need to mention we use source control?

Roles and Responsibilities

Every role in the department is covered by a document explaining their roles and responsibilities. They are written in a way which encourages self-organisation and collective responsiblity. You can download them here. I will be talking about these descriptions more in a future article.

Learning Culture

Each week two hours are set aside for learning sessions such as coding dojos and presentations (we’re currently running a design patterns study group). Outside of these developers are actively encouraged to take the time to learn new practices during working hours (within reason). We have a library of books available on a range of subjects which are at the disposal of everyone. More often than not if there’s a book that someone would like to read the company will purchase it and add it to the library (books are pretty cheap in the grand scheme of things).

Continuous Improvement

Outside of retrospectives we have a monthly departmental session where the most pressing problems are discussed and actions taken away. However there is no limit or retriction to when improvements can be made and everyone is encouraged to take the initiative when they see a problem that needs addressing.