Month: October 2014

Hello, SQL Lighthouse: Meaningful deadlines FTW

SQL Lighthouse

Last week, my team released a beta version of the product we have been working on for the last six months – SQL Lighthouse.

This week, everyone on the team has been reminded how motivating it is to see an idea you’ve been working on start to gather recognition and, more importantly for us, users. At the time of writing (October 28th), we’ve seen our ‘active users’ figure (installations of the product that have seen some actual usage) surpass our usage target for the end of November by 160%. The product and the team have a long way to go, but we certainly feel we’ve proved that we are on the right track.

What does SQL Lighthouse do?

We built SQL Lighthouse to allow DBAs and database developers to identify and respond to damaging ‘database drift’. Database drift is where the state of a database has moved away from its expected or desired state over time, and it’s usually a bad thing. SQL Lighthouse will track database schemas, continually looking out for changes. It will then notify users of any change and give them valuable information about it. Users will be able to get to the bottom of any unexpected schema change and start making things right.

For more information, please visit the SQL Lighthouse product pages: http://www.red-gate.com/products/dlm/sql-lighthouse/

The story of the beta release

The run-up to the release of SQL Lighthouse’s beta version was probably the smoothest, most focussed and least stressful significant release phase I’ve experienced in my 15 years in software development. The primary reason for this was the talented team working on the project – no question. However, I’ve worked with great teams before and ‘big’ releases have seldom been delivered in such a controlled way.

The SQL Lighthouse Beta Release Train

The SQL Lighthouse Beta Release Train

The day after the release I spent a little time considering what I thought the success of the release was down to. I decided that three things had made a significant contribution:

1) Our weekly deployment cadence (which I’ve written about before, in relation to my last project) – meant that we could measure our progress in ‘stuff delivered’ and were never far from a shippable build

2) Our ‘release train plan’ – gave us a clear, visible illustration of what we had to deliver each week to meet our goal (image above and a subject I explored further in this post)

3) The team’s belief in the meaningful deadline we had set for ourselves – meant the entire team engaged in scope management and release planning on a daily basis

I find the third point particularly interesting because I’ve generally tried to shield my teams from project deadlines by which they MUST finish their work. The pressure of a deadline can make teams do inexplicable things – like cut corners with quality, ignore risks, work into the night and discard their principles. Plus, deadlines lead to estimates, and estimates are of the Dark Side.

However, today I sat in a retrospective meeting with my team as we considered what we learnt during the beta development phase. We spent time considering what aspects of the way we worked during that period should be kept and what should be jettisoned. Interestingly, the clear consensus in the room was that the three initiatives I called out above should stay. Yes, the team literally asked for deadlines.

Was this turkeys voting for Christmas? I don’t think so think.

The difference between the deadlines the team want, and the deadlines often handed down from ‘senior management’ at employers more domineering than our own, is that they should be meaningful and real. That is, meeting a deadline must clearly be tied to the success of the group and their endeavour. That way the deadline can be adopted by the group, rather than applied from outside the group in an oblique attempt in increase productivity.

You see, six weeks before the eventual beta release date, the team had set themselves the challenging target of releasing a public beta in time for Red Gate’s annual conference in London – SQL in the City. Why? We did this because, as a group we realised that for SQL Lighthouse to be a success this year, it was paramount that we had a public beta of the tool ready for hundreds of Red Gate users to see on the display booths and then go back to their office to download and try for themselves.

Furthermore, for the release to be compelling we needed to add three major features (audit, email alerts and set-up validation) and overhaul the look and feel of the entire application.  We discussed the relative priority of these changes, scheduled them to the cadence of our weekly releases, accepted the plan was achievable but tight and went for it. But above all, we all believed that meeting this deadline was vital to our success.

Stay on target

To their great credit, the team met the goal of releasing by SQL in the City and transformed the product from a proof-of-concept alpha into a genuinely useful tool. Before you ask: they didn’t work crazy hours, they didn’t hack code in and they didn’t abandon their principles. They continued to ship a release every week during this period, which helped garner feedback from our alpha users on the new features, gradually improve performance and iron-out issues.

If you want to know more about SQL Lighthouse’s journey from product idea to beta release, read Alex Yates’ (SQL Lighthouse team member and technical sales guy) excellent post The Story Behind SQL Lighthouse.

Retrospective Activity: By The Numbers

Introduction

I thought I’d share a sprint retrospective activity I came up with recently. As I outlined in a previous post, I like to structure the retrospectives I facilitate in the form popularised by Esther Derby and Diana Larsen in their book Agile Retrospectives. That structure has five sections, each with a specific goal:

  • Set the stage – Goal: Set the tone and direction for the retrospective
  • Gather data – Goal: Create a shared memory; highlight pertinent information and events
  • Generate insights – Goal: Think creatively; look for patterns, themes and connections
  • Decide what to do – Goal: Generate and prioritize valuable, clear actions
  • Close – Goal: Summarize and end the meeting

This activity – “By the numbers” – is an activity for the Gather Data stage.

Retro in progress

Retrospective Activity: By The Numbers

Purpose

This activity is useful for the Gather Data phase of a retrospective, as it encourages team members to focus on cold facts rather than evaluations or opinions (which are for the Generate Insights stage). Like any good retrospective activity, it leaves room for people to influence the path of the meeting by highlighting events and facts that have significance for them.

Time needed

This is a fairly quick activity that you can tailor to be fifteen to thirty minutes long.

Description

The team generate a list of the facts and figures that describe the current state of the project.

Steps

1.  Introduce the activity by saying “the aim of this activity is to create an overall picture of the current state of the project objectively, without evaluations or opinions. We’ll do this by calling-out numbers that illustrate where we are. For instance, we currently have X green tests and there are Y developers in the team.”

2.  Give each person a sheet of paper and a pen. Tell them they have three to five minutes (decide which!) to create a list of the numbers they think are significant for the project. Ask them not to look at each other’s paper and tell them that the numbers can be approximate if they can’t remember them precisely.

If the team are struggling to write much down, try a couple of the following prompts:

  • “Think about what has happened to you over the last sprint. What numbers are involved with those events?”
  • “What are this project’s vital statistics?”
  • “How would you describe the project to someone else only using figures?”
  • “What are the ideal numbers for aspects of the project? Now, what are the actual numbers?”

It’s likely team members will choose figures that help them illustrate an issue or achievement that’s on their mind – like “100 ignored unit tests” or “zero open support tickets”. This is great and will provide good food for thought in the next stage of the retrospective.

3.  When the group have finished making their lists, it is time to share. Ask for a volunteer to start the process by calling out one of their significant numbers. They should not divulge what the number pertains to. Write the number on a whiteboard so the team can all see it.

Ask the rest of the group to call-out and guess what the number relates to. The interaction might go something like this:

  • Volunteer: “37”
  • Team member #1: “Is it – the number of users who had a support query this month?”
  • Volunteer: “Nope”
  • Team member #2: “Is it – the number of days since we went to the pub as a team?”
  • Volunteer: “Nope”
  • Etc, Etc..

When someone guesses correctly or the process has taken longer than a minute or so, write what the number was related to up on the whiteboard.

4.  Go around the group in a round-robin fashion, asking people to share one of their significant numbers and the group guessing what they pertain to, until you have filled the whiteboard or the timebox you set for the activity.

5.  Debrief the activity by asking:

  • Are there any patterns in what is significant to us?
  • Are there any surprises there?
  • What numbers would you like to change and what would you change them to?

Variations

If the team is stumped when it comes to generating the numbers or are very worried about precision (e.g. “I don’t know how many unit tests we have, off the top of my head”), invite them to go back to the team area in the office to gather data. Make sure you get agreement on a definite time for them to be back in the meeting.

You can also make the activity a group game by breaking the team into two subgroups to come up with the numbers. Then you can make the activity competitive by scoring teams on how many of the opposing team’s numbers they can guess.

To decrease the time needed for the activity, remove the guessing part of the sharing phase – this would be less fun but would gather the same information.

What happened when we tried it?

I’ve run this activity couple of times, most recently today, and it’s worked well. Whenever I’ve used it some team members have taken a little time to warm to the activity, so I’ve needed to reiterate the instructions and encourage them to give it a shot.

Giving examples of the kind of thing you are looking for always helps. Today I gave the following examples, which seemed to unlock the group:

  • 347 people on the our beta mailing list
  • 24 technical debt items on out debt board

After a couple of attempts to guess what other people’s numbers are about, there’s usually good energy in the room. Suggestions can be frivolous and funny or serious and insightful – which is great. By the end, we got a pretty good idea of what people feel is important about the project at the moment.

If you are interested, here’s an image of the whiteboard after we’d done the activity today:

By the numbers

If you give “By the numbers” a go, let me know whether it worked well for you or not!