”FileWave is a specialized software company based in Switzerland that produces computer management & file distribution software – our development team is spread between Wil (Switzerland), San Francisco and Indiana, USA. Our target platforms are Mac, Windows and Linux.
We began using SCRUM in July 2010 – up to that point we’d be using a waterfall based development approach. Looking back on how our waterfall process worked, it had all the problems that are now well known when using this model: a huge up front planning load combined with initial uncertainty in the design/planning phase, heavy costs associated to changes to the plan (which of course inevitably needed to be made), timeline & delivery stress due to these required changes, leading to optimistic deadlines, which in turn made it difficult to release our software in a timely manner with the quality we required.
Under waterfall – there were a number of challenges like planning, quality control, scope and testing that proved very hard to estimate up front – this made the development cycle very difficult to plan and predict for.
Our motivation to change the development methods was inspired by the need to minimise the above mentioned issues – as well as to have a more flexible and predictable transparent development system that could provide early feedback of upcoming issues and the ability to handle change without the heavy costs waterfall imposes.
John Clayton, our head of development, proposed SCRUM because it was simple, easy to understand & employ and promoted virtues of value, like ”reduce waste”, ”self organize”, ”team takes responsibility”. For example, the cyclic nature of a team using SCRUM makes it possible to have a fast feedback loop which would solve some of our ”early warning” issues. The simple nature of planning incrementally would remove many of the problems and costs associated with changing the monolithic waterfall based specifications, because those specs just don’t get written anymore. Having ”conversation placeholders” (stories) means that everyone needs to take ownership and understand what is being done; which in turn leads to lots of questions and thus a clarification of the purpose of a given feature.
John Clayton has worked in large and small organizations all over the world – and knew that putting new processes in place isn’t as simple as flipping the switch, particularly if the change requires habitual/mindset modifications. John Clayton also wanted to ensure success by having an experienced guide or mentor when applying this new skill – and this where the idea to have an external consultant help us implement SCRUM came from.
Our challenges included not just how to put SCRUM in place, but how to keep it there – in a distributed development environment.
FileWave wanted to have a mentor that could understand every role in our company. As we chose to implement SCRUM top-down, we needed to have someone with real world exposure and experience both in the business and in development, as well as testing. From the beginning we decided that it wasn’t sufficient to have just 2 days of training and then be left with a whole bunch of unanswered questions as to how to put the new ideas into practice.
agile42 proposed and delivered a kick-off + team start-up package that worked beautifully. Our first training sessions were provided by Felix Schwarz and he proved adept in consulting at both the business and development levels – Felix not only made it easy for us grasp the SCRUM theory at different levels in the business, but was also able to turn this theory into good habits and understanding during the 2 weeks following our initial training.
So after 1 year – how did we do? Would we do the same thing again, and where did we benefit the most?
Yes; we can categorically recommend both the approach and agile42. Agile42 helped us make difficult company wide changes in a very short amount of time – and to ensure that these changes ”stuck”. In fact, Nurdan Eris, the company CEO can be quoted here; ”agile42 was the best investment we’ve ever made, period.”
Our major areas of improvement have been:
- a far more predictable release plan – which we’ve hit +/- 2 weeks each time (try that in waterfall).
- more transparency and trust between management and the dev team.
- a good understanding of our roles and responsibilities in both business and development – having the SCRUM roles allowed us to say ”no” when the dev team needed to – somehow we were never able to do that in waterfall.
- a higher awareness of values such as responsibility, care of quality, continual improvement.
Another measure of our success is in our product releases – about 2 months after beginning SCRUM, we delivered our best release in 2 years. 2 months after that we delivered a new product for the Linux OS. In Q1 2011 we delivered a major new version of the whole software suite – that’s 3 major product releases in 8 months, whereas in the year before SCRUM we’d made only 1.
We’re all very pleased with our progress to date – and just recently finished a 3 day consultancy with agile42 to help us iteratively improve our SCRUM process yet again, this time with a focus on the PO side of this – the list of changes we’re planning on making is long – proving that SCRUM is an iterative, continual process of improvement for all of us.
Ask any of our team for their one word definition of SCRUM, it’ll be a positive superlative.”
For more information on the filewave success story feel free to contact us.
