For all you tech-loving people out there, our Chief Technology Officer, Mark Wood explains the ins and outs of what goes on behind the scenes at GD. Literally.
‘Since starting here in April 2011 I’ve had the opportunity (and challenge!) to completely build the technology team back up from a base where the existing team was failing and the Technology team was not delivering change and driving GlassesDirect forward. Building new teams is something that I’ve been lucky enough to do a few time before, especially during my time at Betfair but this was my first time as an organisation’s CTO. There are many aspects to building a successful new team from bringing in the right talent to choosing which fires to fight first to implementing the right processes and tackling inertia already within an organisation but for the purpose of this first posting I’ll tackle a subject close to my heart, the product deliver process. In my opinion software development is a modern day manufacturing process, in the way that car production or other factory based manufacturing is seen and I am a firm believer that if the business approaches it with this mentality it this will help drive the business in the right direction in terms of interacting and thinking about how to use this valuable resource but still appreciating the human aspect of it.
The delivery process we have chosen is agile.During my time at Tradefair and then subsequently back at Betfair I worked to roll out agile (SCRUM specifically) development to teams and that is what we have implemented here at GlassesDirect. My experience of this methodology really showed me this was the way to provide the stakeholders and customers with control of WHAT gets built, ensures they are EMPOWERED to make the PRIORITY calls and understand the COST of the requests that are raised. It crucially also really helps promote responsibility and accountability for story delivery and issue resolution within the Technology team whilst also avoiding death marches and unsatisfied stakeholders.
So what size team is involved in the change here at GlassesDirect.com? It has fluctuated, but currently 1 x QA, 8 x Dev / Architecture / FE and 1 product manager plus a 2 x Dev Ops / Sys Admin / office support team. I like to think of it as small but incredibly nicely formed. We have followed the SCRUM process tightly but now, after 9 months of running with this, the team is really starting to flavour the ceremonies and processes to the way we want to work and the specific challenges we have to face. Whether this is through the daily pointing of stories with integrated tasking, or through the revolving of the ScrumMaster function (we don’t have a dedicated ScrumMaster here) throughout the team.
It has taken a while to roll out Scrum within the organisation. Rolling a new process out to a technology team poses one set of issues, but we had another challenge which was establishing a product function and then get the stakeholders to understand and start playing by the new rules. I’m pleased to say that this is something that is really getting traction within the organisation now and the route from idea through to delivered product is well understood and has become part of people’s thinking. The process feels current andÂ it is as simple as it could be, although there is always room for improvement (I’ll be writing a blog on retrospectives and why all teams should have them later on).Â Within our 2 week sprints we can see products moving rapidly from idea to production and start gaining immediate business benefit. And, if I take the months of Feb and March we have delivered 129 points worth of stories and 67 new features / defect fixes have been deployed to production.
We’ve decided to go with Rally (http://www.rallydev.com/) as our agile management tool of choice. It is built specifically for Scrum and after a learning period which, was as much about learning the new Scrum process as the tool itself we now see it as an integral part of our tool set which helps us deliver to the level we do.
Changing or implementing a new process is never easy, especially if people already have preconceived ideas about what agile ‘means’. My experience here was that agile/Scrum was very confused with hot housing a team and creating a new, rapidly evolved product in a very short time-boxed period. This took time to change but the real catalyst was when people began to see the changes both in process but also in the delivery of new features. Personally, I’m excited by the next level we are moving toward technically, which is the ability to take more advantage of our excellent automated test coverage, development processes and to push on towards continuous deployment (we’re getting really quite close)!
Maybe the next blog should be about the toolset and the development mentality we have here, would that be of Â interest? Please let me know and if you’d like to discuss this or anything else in the tech blog please feel free to drop me a mail – firstname.lastname@example.org