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 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.
Leading Agile Teams 
Leave a Reply