A Definition of Done is ...

Those who work with me know that the Definition of Done is something which I consider to be vital to effective software development. For me the subtitle of any Definition of Done should be along the lines of:

As a professional, when I say that my work is Done, it means that I genuinely believe that I have no further work to do and that I have myself verified that the work is of necessary quality and completeness as well as having the work appropriately checked by others. I will honestly be surprised if my work is defective in some manner when I say it is done. Please take a look at the list below of the characteristics that I consider to be important to my work:

After this subtitle, there is the list that most Agile practitioners are familiar with.

Agility is not Viral

Please note: This post was originally published on my Charteris blog in 2008 but is no longer accessible so I’m republishing it here as I feel it remains important.

At Charteris Day this week, we had a series of presentations discussing Agility. The various speakers covered both Business Consultancy (with a focus on our 'Customer Centricity' capability) and from the Technology Consultancy (with a focus on Agile software development). My contribution was to give a 20 minute talk explaining why I felt that the presentation ("Future Directions for Agile") by David Anderson at Agile 2008 in August was so important.

At the head of my presentation I discussed something that I have been articulating for some time now (including during the Park Bench session at the Alt.Net Conference) and I thought it would be worth repeating here to see if others agree with me or not.

First, a little background. During the late 90's I was developing shrinkwrap software using RAD. Whilst I was working for the IVIS Group on Tesco.com in 2002, I was introduced to eXtreme Programming. Since that time I have considered myself an extreme programmer, rather than an Agilist (for various reasons that I won't bore you with right now) and have acted as an agent of change at a number of organisations.

In hindsight, I think that at the beginning of the Millennium we genuinely believed that our principles and practices would prove to be viral and that the meme would spread. After all, we could demonstrate how effective the practices were. We could measure productivity and velocity in a far more transparent manner than  hitherto. The team members felt more empowered and gained more satisfaction from their work. Sponsors felt that, often for the first time, that they actually knew what their development staff were doing and how well. Sponsors especially appreciated the visibility of functional gain and the ability to direct the functional implementation. These characteristics were (and still are) real. It is not an illusion.

Given the reality of these powerful advantages, how could it not be viral? Why would the meme not spread? Yet it has not. At least, it has not in the way that we envisaged.

It is true that the term Agile Development has gained wide currency now, although perhaps not wide understanding. Many, possibly a majority, of development teams aspire to be Agile. It is also true that there are more agile teams now than there were. My observation about a lack of virality is separate to this.

So what do I mean? Over the years, I have engaged with a number of teams to, amongst other objectives, bring in Agile development practices; to act as an agent of change. To a greater or lesser extent, these engagements have proven successful and the teams grew demonstrably more Agile and effective. But then, the time comes to move on to the next engagement. After the departure of the agent of change, the team reverts to the status quo ante. Not immediately, but visibly and certainly. It isn't a deliberate, conscious decision to do so - it just happens, gradually. Six months or a year later, it is as if you had never been there.

Remember, this is a scenario where everyone was actually happier, more contented and fulfilled when they were Agile. Astonishing.

There have been times when I have questioned my own ability to effect change because of this phenomenon. It was very refreshing to hear David Anderson articulate that he has encountered the same problems.

If we accept that Agility is not viral then we are bound to start asking the question: why?

I will start by saying that I have no potted answer to this question, I am still in the process of seeking to gain understanding, but my first candidate explanation is this: "people are intrinsically lazy".

Ouch. That sounds contentious! Well, it shouldn't be. After all, there is a reason why we prefer to buy labour-saving devices. There is a reason why people walk across the grass along the hypotenuse of the trianglewhen the path follows the other two sides.

So why might laziness be an issue? I suspect it is because Agility is hard work. The practices we espouse are difficult and require us to work at a more challenging pace. Even if we feel better for doing it, it is easier not to do it. It is much the same as exercise. Why do gyms offer 'new joiner deals' in January? It is because they know full well that only a fraction of people will actually use their facilities all year and after the Christmas break people feel guilty about all that excess consumption.

Sponsors love the transparency of agile functional gain but it takes effort from them to achieve it. Sponsors are busy and in the absence of that agent of change hounding them to set aside time to contribute to the development process they start to miss meetings, they stop engaging fully with the development team and so agility is lost. The development team is just as guilty though. They too are busy people and it takes effort to ensure that the quality control practices are maintained. Knowing that the agent of change isn't around anymore to catch them out, they start cutting corners on their TDD. Before long, the team reverts to being less agile; possibly even entirely ceasing TDD for example.

The direction that David is taking in his talk is to look again at the CMM and he certainly marshals some strong arguments. He also challenges some of our practices by asking if Lean and Kanban are Agile. I am not yet wholly sure that these are the right answers but he is certainly asking the right questions.

I have a feeling that perhaps we have historically had a very mechanistic view of people and process. Perhaps this is why we assumed that agility would be viral, because we assumed utility was inherently compelling. When I use the term 'we' here, I suppose that I am really talking about alpha geeks. The same people who naturally gravitated to extreme programming, agile and now to alt.net. This is why there are so many discussions about "is alt.net elite.net?" and so on. If so, we need to recognise that most people are not like us. Even most software developers, I suspect. We therefore face the very real challenge of how to make agility sticky.

My suspicion is that we need to become sociologists and learn how to enculture organisations with agility.

I am very happy to say that I think that the agility presentations at Charteris Day look like they have succeeded in sparking the debate I believe is needed to grow our capability further as a consultancy; to better leverage the depth of knowledge in the company and to harness this for our clients. I'm sure that I will have more to say on this subject in the future.

Golden Hours

I quite often talk about “Golden Hours”. I employ the practice both at work and at the Open Space Coding Days. However, I find that there are relatively few people who have heard of the practice – a fact that I find somewhat surprising given the huge amount of value that I find that it delivers. Although I can’t quite recall where I first heard of Golden Hours, I have been using the practice for about 6 years, on and off.

Background

There has been a great deal of research over the years into human concentration and productivity, much of which indicates that humans tend to concentrate in sprints. Furthermore, deep concentration seems to take time to achieve (typically at least 10 to 15 minutes) and is easily disrupted, especially by multiple stimuli. The optimum concentration period seems to be in the region of 100 minutes and few are able to maintain deep concentration beyond that.

In addition to the general research, there is a body of productivity studies (including a great deal on developer productivity). Much of this indicates that, regardless of the number of hours actually worked, the vast bulk of productive coding time amounts to about 4 hours a day.

When discussing this with developers, I find that this generally fits with their personal experience.

In Practice

Essentially, Golden Hours takes the observations made above and simply embraces them.

What does it look like in practice? I follow a regime as follows:

• Golden Hours run from 10:00 to 12:00 and from 14:00 to 16:00.
• All preparatory work must be carried out prior to the Golden Hours: all investigations and all communications must be complete. Preparation is regarded as ‘done’ when the pair who will work together are satisfied that they have sufficient knowledge to code for 2 hours without interruption.
• During the assigned Golden Hours, the developers should close all communications: shut off IM, close their email application, mute their phones and so on.
• During the assigned Golden Hours, nobody is allowed to interrupt the developers unless there is an emergency. Fire alarms count, the live systems failing catastrophically also count. Not much else counts as an emergency. This includes the CEO, other senior management and any other stakeholders. It isn’t negotiable. In reality, there is very little that can’t wait for a maximum of 2 hours.
• Depending upon your environment, there may need to be a buffer to protect the developers. In some organisations, that may involve having 1st-line tech support. In others, you may need a assign the ‘bouncer’ role to someone.

I have found that 2 hours is an excellent unit of time to work with. You can thoroughly prepare for a 2 hour coding stint in a relatively short time (I find to 30 minutes preparation time is typically sufficient). It is a length of time that external stakeholders are usually happy to live with the developers going incommunicado. Just the need to thoroughly prepare is an excellent practice that minimises wheel-spinning. Once you have bedded-in Golden Hours, I have also found that it is a good unit of time for estimation purposes – along the lines of “Assuming that you know everything that you need to know, how many golden hours do you estimate that this task / feature / story will take?”.

You may find the response to the introduction of Golden Hours surprising. When I brought the practice into MoveMe, the product owner immediately asked “Does this mean that developers can’t interrupt me during this time either?” with a big smile of his face. An excellent reminder that being unprepared and disorganised is a disruption to others.