Join the DZone community and get the full member experience.Join For Free
Discover how TDM Is Essential To Achieving Quality At Speed For Agile, DevOps, And Continuous Delivery. Brought to you in partnership with CA Technologies.
I’ve recently been doing some coaching at the BBC in Media City, Salford. During the first couple of weeks my commute home always took 90 minutes; then on maybe one day per week I got home in 65 minutes; now it usually takes 65 minutes, and only occasionally (maybe one day per week) takes 90 minutes. I have saved 25 minutes on my usual journey time, and I have done it without resorting to extreme measures such as (heaven forfend!) spending money or running. How? By developing a few “micro-habits” — little routines that each save a tiny amount of time, but which together add up to a huge saving of almost 30%. I believe this approach can be applied to everything we do, so I think it may be instructive to dig into that 25-minute saving to see how it is achieved…
First, let’s take a look at the typical 90-minute commute home:
- At 1600, pack away my things, leave the office and walk to the tram stop.
- Wait for the next tram, board it, and wait for it to move off.
- The tram journey takes 20-25 minutes to reach Piccadilly station, depending on traffic conditions in Manchester.
- Walk up to the main concourse in the station and to the departures board.
- Wait 20 seconds for the board to show trains to Macclesfield. The next train is the 1648, departing from platform 3.
- Walk to platform 3, stopping to find and show my ticket to the inspector at the gate.
- Wait for the train. The typical wait at this point is 10-12 minutes.
- Sit reading on the train until it arrives in Macclesfield at approximately 1718 (actually the usual arrival time is 1723).
- Walk 0.5km to my car, then drive 3km home. The drive takes 5-10 minutes, depending on traffic conditions.
I noticed that there is an express train leaving Manchester Piccadilly at 1635 and arriving in Macclesfield at 1655; I also noticed that I usually arrived in Piccadilly station at around 1638. So it would only require me to save 3-4 minutes in the first half of my journey in order to realise a 25-minute saving overall. Note that there are plenty of delays in this process. I have no control over some of these, such as random traffic hold-ups, or the actual arrival time of the next tram. But I do have control over some, and during the course of a couple of weeks I have developed the following micro-habits:
- During the afternoon, as I use things for the last time I put them away in my locker. This is a gamble, but most of the time it turns out to be okay. And it saves me upto 2 minutes of packing up time at 1600, which means I have slightly greater a chance of catching an earlier tram.
- Trams are scheduled every 12 minutes, so the expected mean wait time at any stop is 6 minutes. If there is no tram waiting (or imminently arriving) at Media City, I walk to the next stop down the line. That’s because Harbour City is on TWO tram lines, and so more trams pass through that stop. The walk takes 3 minutes, and always pays off: either I get the next tram out of Media City, thus saving nothing and losing nothing, or I get an earlier tram on the Eccles line, thus removing upto 3 minutes waiting from my journey.
- The rearmost door of the tram is always closest to the stairs when it pulls in to Piccadilly; so I always position myself close to that door, to minimise the time it takes to get up to the main concourse.
- I now ASSUME that I will be in time to catch the 1635, and I ASSUME that it will depart from platform 6 as usual. So I don’t go to the departure display and wait for it to show me current status; instead, I go directly to platform 6, a saving of 20-30 seconds.
- While walking to the tram I found my ticket and made sure it was in an easily accessible pocket. When I arrive on platform 6 I can now retrieve the ticket instantly and show it to the inspector without breaking step, thus saving 20 seconds.
As the departure of the 1635 is usually imminent at this point, these last two savings of upto 40 seconds can mean the difference between catching it and having to wait 13 minutes for the 1648. If there were no major delays on the tram I will now get on the 1635, which arrives in Macclesfield at 1655 (always). The remainder of my commute is unchanged, and so I arrive home at around 1705 — a total commute of 65 minutes instead of 90.
Most people will, I think, do similar things to these when faced with a regular commute such as mine. As I mentioned above, I believe this approach can be applied to everything we do, and in particular I think there are huge savings to be made in software development. I believe that many, if not most, software teams could significantly reduce cycle times — the time taken to pull a single product improvement through from “idea” to “in use” — by developing micro-habits to eliminate waste. I believe that the most productive teams, and the most productive developers, already do this; and I am sure that these micro-habits make the best upto ten times as productive as the rest.
So what are the micro-habits that will make this huge difference for software development? Some of them are universal and coarse-grained:
- use a refactoring tool,
- use a version-control tool,
- become test-infected,
- write black-box behavioural tests at all levels,
- pair program,
- refactor mercilessly,
- work outside-in, etc.
But I suspect that there are more that are specific to the developer, or to the team, or to the codebase, or to the technology being used. Some of mine are:
- learn the keyboard shortcuts for all of your tools,
- drink a lot of water,
- pick pieces of work that can be committed to trunk at least every hour,
- re-run the tests after every distraction,
- commit all work before going home or throw it away,
- automate tmux set-up,
- automate towards a single-click build,
- automate towards a single-click deploy, etc etc.
Do you have any stories showing how a few micro-habits have transformed a team’s productivity? There seems to be no written repository collecting such developer micro-habits together, and nor is there any obvious forum in which they are explored, shared and discussed. That seems a shame, and a huge waste. What should we as a community do about it?
[Credit to Sean Blezard for coining the term “micro-habit” when I explained to him the idea for this blog post.]
Published at DZone with permission of Kevin Rutherford , DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.