Software Development Methodologies
Mixing the best approaches can actually produce something even better.
It’s not exactly earth-shattering news that good project management delivers better software, in muchthe same way that a good cook makes better food. Anyone can chuck promising ingredients into a bowl; it’s knowing what to do with them that makes the difference.
With some big projects behind us, several in development and yet more on the horizon, we wanted to show how our project managers – Team Titan, as we call them – could, well, manage the work they do for hugely differing clients, requirements and sectors. It seems like no mean feat.
Mixing it up
The key is in being able to respond to the changing needs of each client and project over time, while still keeping a firm eye on the end goal. To do this, the team take an approach that mixes elements of modern, Agile development methods (generally, we use an Agile methodology known as Scrum, which encourages good communication between managers and developers) with slightly more traditional design concepts.
Created in the early 2000s, Agile was a response to the failings of project management practices that, in its early days, software development had inherited from manufacturing industries. Inflexible and restrictive, these ‘Waterfall’ methods often didn’t account for a fundamental point behind software design: things change.
An Agile approach – why’s it important?
Agile allows for more flexible projects by operating in ‘sprints’; at the end of each sprint, you aim to produce a functional, working product, which incorporates some of the features required by the client. Once the client’s provided feedback on that version, developers then set about adding further elements to the project. It’s entirely possible for a client to have a basic, working product from the first sprint onwards, and giving feedback at each stage makes it easier for changes in requirements to be met. It also allows for any issues in the product spec to be spotted far earlier, rather than lurking in the background until the final product is released.
An example from Spotify’s development team illustrating their processes probably explains this best. Rather than building a car chassis – which isn’t of much use on its own – and then adding the axles, wheels, doors and so on, you instead build a skateboard. If the client likes the skateboard, you upgrade it to a moped. Then a motorbike, then a car – at each stage taking on board what works and what doesn’t.
Scaling it down – adjusting for different project sizes
This is perfect for larger projects with a big end goal, but as client feedback can cause budget and timescale to shift around slightly in between sprints, it sometimes isn’t the best approach for smaller, more restricted projects. For these, the team use Prince2.
Prince2 is, in a nutshell, a Waterfall-like method with imrpoved client involvement It combines the heavy documentation and more rigid planning of older Waterfall methods with step-by-step client feedback in a manner more similar to Agile. It’s less flexible, but it does still allow for problems to be spotted earlier on, and it’s great for making sure clients are reassured with a ‘big-picture’ view of the entire project.
Being able to use both these methodologies, and having the expertise in using them that allows for mixing elements of them together, means that the best way of doing things can be judged on a per-project basis. It also happens that some clients are simply more comfortable with one method than another, often depending with the general style of their own business sector. It’s not a common approach to mix and match these styles, but we’ve seen the positive results time and time again. Happier clients, better communication and more robust products.
We think that’s worth experimenting for.