Product Development Manager at AIRCOM International
Leatherhead,
United Kingdom

April 2007-July 2010

In this role I ran a team to deliver a software product which monitored and reported on the performance of mobile networks. This was for customers such as AT&T, Telefonica (largest Spanish mobile operator) and Turkcell (largest Turkish mobile operator). To build the necessary tools we used C++, C# and Delphi and all using Oracle as the DB engine.

From a process perspective initially the company used a waterfall approach where there was high investment in upfront requirement gathering, fleshing these out to the nth degree then writing design to architect and incorporate the necessary changes etc etc. After this investment we would steam ahead at full speed, delivering everything we 'absolutely knew' was required (because we had the details in a document - didn't we?) only to get to the end and find out that the what we had fleshed out at the beginning is now 'slightly' or 'mostly' incorrect or that the market requirement had changed. I say 'slightly' incorrect here as most of the time the customers would not drop whole features but after seeing what we were doing they would want to change things or make things fit to they style of business. This caused us to re-address requirements, design and software implementation many times and delayed releases. Another problem we saw with this approach was how unaligned other areas of the business were. Due to the lower volume of communication everybody 'thought' they knew what we going on and when, but this was proven wrong many times - at worst this would mean sales would promise the release to a customer without 'knowing' the actual content or targeted date.

So... after seeing this occurring we suggested to move the business to a more Agile approach. We restructured the way the epic features were added to the backlog as these were no long flesh out to the nth degree. The closer things came in priority the more detail/investment these were given. We structured our team and I became the SCRUM master (and the was the team lead - which worked for us), the product engineering team appointed a Product Owner and we made a start.

The benefits we saw:

  A massive increase in communication which in turn made are development more accurate
  A boost in team moral as delivering more frequently meant they can show off what they had achieved more frequently
  A common structure to projects through the business
  The increase in communication meant that all interested departments knew what was happening and when

Difficulties:

  Business owners still wanting detailed upfront costs - "why would I pay for something if I don't know when I'll get it"
  As team lead and SCRUM master I had to try and wear two hats and make the team not 'report' to me in the standups
  Justifying ideal days - the business owners would say "well why can't we always work that fast!"
  Stopping scope creep and change of direction within the sprint cycle. I over came this by pressing the STOP SPRINT button a few times and the PO's soon learnt :-)
  Initially getting the team to self organise and not look at me to allocate their work

Overall I implemented SCRUM in this role 4 years ago and its still being used. The roots fundamental to it still exist and are strong. I agree with Lyssa Adkins in her book Coaching Agile Teams and the roots shes suggests are: Courage, Focus, Openness (very important), Respect and above all Commitment.

Show Details