Paul Hammond's Blog

I travel a reasonable amount for work.  I live 25 miles from London's Heathrow airport and 20 miles from London's Gatwick airport and neither is conveniently accessible to me using public transportation.  As a result, I regularly need to use a taxi company to deliver me to and pick me up from the requisite terminal.

I have been using the same company for a couple of years now.  For almost every single journey, they have been good enough that I would have given them a "completely satisfactory" rating.  They were always on time to pick me up from my house, the were always waiting for me a little sign bearing my name when I came through the arrivals door with even when my flight was delayed, and their cars were always clean and comfortable.

Note that I said "almost" in the last paragraph.

There have been 3 occasions lately when they let me down.  All three were for early pick-ups at my house (usually at 4:30am) for day trips to Dublin.

The first time, no car had arrived by 4:40am, so I called the company.  The dispatcher called me right back and told me that the driver had gone to Bayseed Road instead of Hayseed Road (where I actually live).  This seemed reasonable until I used Windows Live Local to discover that there wasn't a Bayseed Road within 200 miles of where I live; a little white lie to save face with the customer.  He arrived at my house at 4:50, and I got to the airport with plenty of time to spare, so I let it go.

The second time, once again I had to call the company at about 4:40am.  Again, the dispatcher called me back.  "Sorry, the driver overslept, he's just getting ready and will be with you in 15 minutes".  At least they were honest this time.  Once again, he arrived at about 5am and I just made my flight (although I didn't get the decent breakfast I wanted).  Being a fairly easy going guy, and given the continued excellent service the rest of the time, I let it go.

Yesterday, I had another 4:30am pick-up.  At 4:35am, when the car didn't show, I called the office.  No answer.  And there was no answer the following 15 times I called between 4:35am and 5:00am.  A no-show, and no explanation.  At this point I had to take my own car, leaving my wife without it for the day; she had plans so this was pretty inconvenient.  I called the office later on, and spoke to the owner of the company - he was very apologetic.  He told me he would call back with the reason for the no-show.  He didn't call me back.

Three strikes, they are out.  I am now looking for other taxi companies to do business with, and the original company have lost business to the tune of £80 for every single trip I make.  Despite a very high satisfaction rate for most of the journeys I made with them, just three failures were enough to make me "fire" them.

So how can you apply this story to your development team?  For me, this was all about trust, about making a commitment and sticking to it.  The taxi company was providing me a service, one that had potentially difficult consequences for me if it wasn't provided to a satisfactory level.  Despite providing a good enough service most of the time, the few times they failed completely killed any trust I had in them.  I would feel 0% confident about booking another 4:30am taxi from them.  Also, I had to chase them for status updates in each case, and for that last incident I couldn't get an answer.  If the drivers were running late, someone should have called and reset my expectations.  For that matter, someone should have called the drivers to make sure they weren't running late in the first place.

Once your team makes a commitment, they MUST do whatever it takes to keep that commitment.  If they cannot meet the commitment, then they MUST communicate as early as possible with their customer to understand the ramifications of missing the commitment, as well as collaborating on what an alternative delivery might look like.  Even though the trust between your team and your customer will be eroded a little, proactively facing negative news will help maintain a "win-win" attitude between the two parties.

I attended a number of excellent sessions at the Agile 2007 conference in Washington D.C. this year.  One of the most thought provoking for me was the session by Bob Martin on Developer Professionalism and Craftsmanship.

I have worked as both a developer and as a manager of developers for many years.  As time goes by, it is very easy to lapse into bad habits, to forget that my profession is as defined as any other craft and deserves to be treated as such.  As with any defined craft, consistent high quality relies very much on two things - good quality teaching, and large amounts of discipline by every one of its practitioners.

Bob listed a lot of attributes that he believes makes a "professional" developer.  Many of the items were related to Agile development practices; short iterations, feedback loops, deferring decisions etc.  Of the rest, I wanted to highlight some that resonated with me, because I have seen many teams (and definitely myself!) fall short in these areas.

Progressive Widening and Deepening

For progressive widening, start small and get wider.  For example, when coding a login screen, simply show the username box and a button and allow a login with just the username typed (no checking).  Then add a password box and still allow the login with no checking.  Then have the user enter a username that is checked.  Then a password.

For progressive deepening, develop your features in layers - ensure a feature completely works in each layer (e.g. the UI) before moving to the next.  This will help with decoupling your application layers from each other.

Don't Write Bad Code(!)

Go fast by going well; ensure your code is clean at all times.  Bob gives a good analogy with a kitchen; if you wash up as you go when preparing food, next time you cook everything is already prepared.  If you never wash up, you are always surrounded by food stained plates and pots and pans, and it gets worse over time.  At this point Bob said, quote, "using Test Driven Development is a matter of minimum professionalism".

Test/QA "Should" Find Nothing

This should be the default expectation for every single team member, and developers (more than anyone else) should be driven by this expectation.  The goal for TDD should be 100% code coverage, which in turn will contribute to this expectation.

Debugging Should Not Be Necessary 

When writing your code, debugging should not be necessary because you are writing such small amounts of code to pass your tests (which you wrote first!).  Worst case, debugging should be in code you *just wrote*, in which case you could even delete the code and write it again!

"Manual Test Scripts Are Immoral"

Manual test scripts are essentially programs, and people shouldn't execute programs.  Running manual test scripts is high-stress and tedious and therefore error prone; .  Testers should invest their time in exploratory testing, because, and again I quote, "testers are creative people with diabolical minds".

Definition Of Done

I blogged about the importance of "Defining Done" before.  Done is when all acceptance tests pass.  Bob's tips included:

• ALWAYS automate "done".
• Have end-to-end tests for every definition of "end-to-end".
• An important tactical point he made was that all acceptance tests should be done by the mid-point of the iteration at latest to ensure they can be built in to the build process for at least half of the iteration.

[Note: I do have a small issue with the ideologies above.  I work predominantly in the Web space, and automating the UI part of what we do is a tough problem - multiple browser and OS combinations gives us tough challenges when automating.  It is definitely possible to do, but the cost can be quite high when creating and maintaining your test suites.  I'd love to hear from anyone who is having success with TDD and automated testing in the Web development area.]

Finally, Bob talked about the concept of an Apprenticeship in software engineering - something I think is a fantastic idea.  I have a new developer on my team, and I am going to spend time with him over the next year or so helping him become the best developer he can be.  I am also going to challenge the other developers on my team to reflect on the areas where they could be more disciplined, and support them in becoming better developers.

Let's not settle for being reasonable engineers, lets become master craftsmen and create masterpieces of coding beauty, solutions that we can be proud of...

[Bob Martin gave this talk at another conference this year, and Julien Delhomme has written up Bob's full list here: http://juliendelhomme.com/?p=18]

I just read Sanaz's post on being in "Ship Mode" - the state of your mind in the period running up to a ship date.  In her post, she describes a state where you are working extra hard, often doing longer hours or weekend work, your inbox overflows, even your music style changes (r'n'b gives way to rock!) and other symptoms.

This represents many of the experiences from my software development career.  Sanaz's post implies that despite the hard work, she still loves doing what she does, and in this respect she is very lucky.  She works on a cool product and the satisfaction of that can be enormous; enough to overcome the stress of "ship mode".  In my experience, there have been many times when the teams I was working with have been in a much less positive mindset, instead death marching towards almost-certain failure.

However, whichever mindset you are in (positive or negative), being in "ship mode" is not congruent with idea of Sustainable Pace.  Unless you are working at a sustainable pace, you cannot guarantee any level of predictability or consistency, and therefore cannot reliably plan or execute against commitments you make.

In my team, there have been a few recent events that have created a real dilemma for us.  Environment outages, sickness and other issues have caused products to be at risk of being incomplete at iteration end, and many of the team members were chomping at the bit to "work whatever hours needed to get this thing finished.  After all, we're Microsoft employees, we are obligated to go that extra mile".

I couldn't decide what was "right".  After all, that is not sustainable, right?  It breaks the rules, goes against the philosophy.  Some people did work extra hours, things did get done.  I still wasn't comfortable.

My good friend Mitch posted about Breaking the Rules of Agile - Working Overtime.  The key sentence he wrote in his post that helped me find some clarity in my thinking was "teams work overtime when its needed, not demanded".  He goes on to talk about some situations where his team made pragmatic and collective decisions about working overtime to meet the commitments they made.  He summarises the post with:

If you find yourself in the position where your team (or a team you coach or "manage") needs to work overtime, have the team ask itself if overtime is needed.  If it is, talk about it, define the goals of what will be done in the overtime sessions (or weekends) and outline the exit criteria.  Follow this with a discussion on who is needed to do the work, and as a result, work the overtime.  Remember, this is a team exercise.

I will be working with my team to make this exercise a team norm in times of "schedule stress".

In your personal life, when you start a task, I would make a guess that you are normally pretty clear in your mind about what steps you have to take to be finished.

Painting your living room might involve moving some furniture, masking the edges, painting a number of coats.  You also need to perhaps choose and buy paint, find some brushes.  You need to remember to clean your brushes when you are finished, and maybe tidy up the dust sheets.  Not only is it easy to think through the steps, it is also fairly obvious to you if you miss something out.  The furniture may be in the wrong place, there may be a dust sheet where the rug used to be, perhaps the brushes are still in the sink, preventing the washing up.  Even if two or three people help out, it is still reasonably easy to know when you are finished.

When writing software, it is invariably much harder to pin down everything that needs to be completed in order to call things finished.  Additionally, it is not so obvious when you haven’t managed to complete everything you needed to.  You won’t trip over those 40 open issues when you walk into the room.  That unfinished documentation doesn’t sit in the kitchen sink waiting to be discovered and cleaned up.  On top of that, it seems that different individuals in a software team have different ideas of what the things are that need to be worked on to call something complete.

This was one of the situations my team struggled with – an incomplete and differing understanding of what constitutes done.

Defining “Done”.

In order to overcome this, the team went through an exercise together to define what “done” means for our team (thanks to Mitch Lacey for the technique).  This exercise has three parts, a brainstorming session followed by categorisation and then an annotation session.

Brainstorming: get the whole team into a room, and give everyone a pad of post-it notes.  Ask everyone to write one thing on a post-it that needs to happen for their software to be done.  For example “write code”, or maybe “be bug free”.  When someone writes an item, they throw the post-it in the middle of the table and shout out what they wrote.  Don’t worry about duplicates or uniqueness, just churn out the ideas as fast as they will come.  Cover every base – documentation, testing, deployment, customer interaction, operational issues – everything that people can think of for their software to be maximum quality and shippable (or even shipped!).  5–10 minutes is probably enough to exhaust this exercise.

Categorisation: now you hopefully have a mountain of post-its (I think our team had well over 70).  The team should categorise these buy clustering similar tasks together on a white board, removing duplicates as they go.  This should give you a draft set of “done items”.

Annotation: finally, the team should create a “done list” document by copying down each post-it item, discussing what it means (and retitling it if necessary), and then adding a sentence or two to ensure its meaning is completely unambiguous.

The “Done List”.

Your team now has a “Done List” that was collaboratively produced, and has team-wide buy-in.  This can now be used for two things – a reminder list for when you are planning to ensure the team is not forgetting work that needs to be done to be complete, and a checklist to use at the end to ensure the team really has done everything necessary.

Benefits.

There are a number of benefits to using this technique:

• Everyone in your team knows the bar they are striving to reach.  In fact, they helped create that bar, and all bought in to the list that was created.
• You can articulate, both inside and outside of your team, the exact goals your team has when shipping high quality software.
• You have a great "soft" tool for ensuring you don’t forget things when planning.  This can help improve your estimation also (more on this in a later post).

There is a great article by Robert Holler (president and CEO of VersionOne) over at the Agile Journal website that talks about the 5 C’s of Agile Management.

In the introduction to the piece, there is one sentence that I found very interesting: “Yet individuals with the desire to change the fundamental rules of the software game and accept the empirical nature of software development are faced with numerous opportunities.”

This one sentence sums up very well two of the major realisations I have had over the past year or so of “Agile discovery”. 

Firstly, in order to be successful with Agile I believe you need to allow yourself to throw away everything you knew from before and to start your thinking again, from a very basic level.  I am not saying there is no place for the years of experience you already have in the software industry – of course this is highly valuable, and key to continued success.  But unless you are willing to challenge all of the norms you previously worked within the confines of, I do not believe you will fully reap the benefits Agile has to offer.

Secondly, writing software (as with most things you do in life) relies on leveraging your finely tuned common sense!  Understanding that requirements ALWAYS change, estimation is ALWAYS imprecise, trust ALWAYS gets tested between the various protagonists of a project (both internal and external to the development team) is key.  Yet we often find ourselves looking for more ways to combat these things, more processes to mitigate the risks and address the dependencies.  More buffering to “guarantee” our success.  We hide from the reality that some of these things can never be managed!  The word “accept” that Robert uses is pivotal – until you accept that software development is empirical in nature, you cannot possibly maximise the benefits of Agile to your team.

Robert articulates the 5 C’s as Courage, Context, Course, Cadence and Cost.  As a manager in an Agile organisation, I will definitely be coming back to these 5 concepts again and again when thinking about how we can continue to improve and successfully deliver on our commitments to our business.

It has been 13 months now since I posted my first entry under the “Scrum / Agile Development” category.  That was when I had just been certified as a ScrumMaster and my team was very early on in its adoption of Agile.  Since then, I have learned an awful lot, but I haven’t felt like I had enough wisdom to make further postings worthwhile to the few people who read my blog!

I now find myself sitting in the BA lounge in Chicago’s O’Hare airport, returning from the Agile 2006 conference in Minneapolis.  Having had a week to think deeply about some of the happenings over the past 13 months, as well as a chance to think about the future, I realised that I have a number of key defining moments that I can talk about in my teams’ Agile learning growth.

If you are in my team, you probably recognise the title “Post Game Huddle” from a few internal mails I sent.  I liked how it fits with the Scrum analogy, where working on the products is the “game” and these thoughts are the coaches talk after the game is over.  So, I am keeping the title for some forthcoming thoughts about how other teams can leapfrog some of the hurdles that slowed my team down.

This is just an intro, watch out for more entries in the coming few weeks.

http://www.waterfall2006.com/

I’ll see you there…!

About 3 months ago, my group at MSN decided to adopt a new project management methodology called Scrum.  Projects undertaken using Scrum take an iterative and incremental approach to software development.  The keys to success are frequent inspection and adaptation.  Every day, you examine the world in which the project is living, and you make the changes necessary to ensure a successful outcome.  It is a highly collaborative approach, relying on face-to-face communications instead of reams of documentation.  By definition, it brings your team and its customers very close together.

One of the roles in a project run using Scrum is the ScrumMaster.  This person ensures that everyone follows the Scrum rules, and helps the team achieve its goals.  Over the past two days I have attended a Certified ScrumMaster course run by Ken Schwaber.  It has been an excellent couple of days, and I have learned a lot more about Scrum and its application.  Also, I am now a Certified ScrumMaster.

Someone once said to me “you take driving lessons in order to learn how to pass your driving test, and once you have your licence you then start to learn how to drive”.  That is the way I feel today about Scrum.  I have spent many personal hours reading books, blogs and forums, and I have now committed 2 days of my time to become a Certified ScrumMaster.  But somehow, I still feel very much like an amateur.  You see, the rules of Scrum might be very easy, but the nuances of its application are very hard.  Simply changing the long-standing “waterfall” mindset that prevails within most organisations is a challenge in itself.  Doing it in a way that allows the new process to succeed is even harder.

I am very much looking forward to the coming months, a period where I expect to be outside of my comfort zone quite regularly.  The role of ScrumMaster requires personal attributes that I, as a traditional geek, need to really work on.