I am 99% done

On defining done and instituting code milestones — Why they are critical to your teams’ success & velocity.

It was 4.45pm PST and time for regular daily stand-ups. The team had a big smile on their face. Alex spoke beamingly, “I am 99% done! with the auction algorithm”. “Really?”, I said. Was it time to celebrate? Familiar conversation? What does it mean?

My long time mentor Jamie Dinkelacker, once reflected on the usage of the term done in stand-ups with me, “Sudhakar, done is always in the past tense”. ‘Done’ is a verb that has already been inflected for the past participle. This point stuck with me for life. There is nothing like 99% done.

The Last Mile can be the Hardest Mile

In one project, as launch day approached, the team was very confident of hitting the key dates. It was like are you done? Ya!— 99% done. Later as the hours rolled by, the team started seeing issues with missing messages in production, indexer delays, and database performance. Ooops! Much time was spent diagnosing and resolving replication issues. Ultimately, the team implemented their own replication and improved their QA setup to detect missing messages.

Why didn’t we detect this early? Team didn’t do testing at scale early enough. The team’s sense of urgency was not properly communicated or felt by dependent teams and lot of the todos started piling up. Were we 99% done? the last mile turned into 4–5 weeks launch delay, canceled vacation, and many fires to be put out. The team hadn’t incorporated slack time in planning to handle unpredictable situations. Team realised they had to introduce redundancy from the early on and better QA setup for load testing.

Defining “done” is an important aspect of working software for your team. You are in one of two states, done or not done period!

Code Milestones are Critical 

Teams need to maintain agility in “how to produce software”, NOT about “how to manage coders”. This is a fundamental distinction; the focus is productivity. Checked in code (CL) can be conceptually thought of as an integral function over time and you need to cut down waste to produce value. From defining done, to introducing non-intrusive tools, to lightweight processes, to not carrying dead code, to minimal work products, to decision meetings etc. all aid in checking in code that add business value.

Checked in code as an integral function

The Agile manifesto states that “working software is the primary measure of progress.” Empirical studies and retrospectives conclude that implemented, tested, and submitted code worked well. When I recount many words used in stand-ups, and represent it as a tag cloud (see below), you can see “code” level artefacts speak loud in most cases. In speaking with many developers, and asking “what could have gone better?”, teams indicated they could improve CL reviews, tests, and integration.

What worked well? Watch the loud words

In my previous article on improving productivity, if you recollect, I had pointed out that the energy of two geographically dispersed teams working on a project was dramatically improved when they delivered their first working demo. Here are some of the speed bumps the team encountered:

• Communication breakdowns between the backend team and the UI team due to inconsistent terminology.
• During design consultations these teams were contentious and team members often felt that their opinions were ignored.
• New team members arriving from cancelled projects exacerbated these problems.

Overall the two teams had very low morale and the project was going belly-up. The team decided that it would focus on a code milestone that would show off a working demo of two features which added a lot of value. As you work towards code milestones, be clear on the goal, get a good agreement on what “done” means for your team. If you are having issues getting buy-in from everyone, try using design principles to give more clarity and consensus on the goal and make decisions faster.

“If you chase two rabbits, both will escape”.

Observation

The team’s morale dramatically improved with the working demo. During the retrospective, the team voted with a “green (high energy)” or “red (low energy)” vote to characterise each major event in the project’s lifetime. The code check­in for this working demo was marked with overwhelmingly “high” votes. Other major milestones that positively impacted the morale are early prototypes, getting readability, major modules being checked , and integration with the products backend.

In one retrospective, I identified the following problems:

• Issues of ownership and control led to division in vision and direction.
• Conflicts in implementation strategy internally or between cross time­zone teams led to counter­productive arguments.
• Engineers in both teams had members whose past projects were cancelled.

A few non intrusive techniques that helped are:

• Use fixed length development cycles

• Introduce lightweight non-intrusive tools for engineers. I once wrote a python script that extracts documentation from checked-in code to highlight what features are in code during the release process that was very much appreciated by devs.
• Track project velocity using leading & lagging indicators, burndown charts and dashboards to
  help throw light on large backlogs.

“Managers use people to accomplish work, leaders use work to grow people” — Wayne Strider

Five Lessons Learnt

The practices I instilled in different projects varied from team to team, and did what worked for each team. Teams felt they made great progress because of the ability to “focus on one thing” and produce working code.

1. Facilitate Team definition of done and get agreement
2. Encourage regular demos to show off code (end to end) and get feedback.
3. Narrow the scope of individual milestones and meet demo deadlines.
4. Write complete code with unit and system tests.
5. Plan when possible for face to face meetings between geographically distributed teams.

You can reach the author at sudhakar.ramakrishnan108@gmail.com. Learn about future articles, upcoming courses and workshops in my low bandwidth newsletter.