Is Waterscrum The Answer To Large Development Projects?

In our previous article we talked about the role of an interaction designer in an agile environment. This time we are seeking answers to the question: is agile development always a good way to go?
 

Main drawbacks of waterfall, i.e. the traditional method

The traditional waterfall method is usually divided into the following phases: initiation, design, development and implementation. Development is often a long process, lasting 6 months, a year, or even longer.

Waterfall tends to fail when the project goes into the coding phase because connections between clients and developers starts to break. Most of the time you can trace failures to gaps in communication. Poor communication is also the reason why these projects tend to fail even when supervised.
 

Agile development works well when conditions are met  

The goal of agile development is to keep the link between clients and developers, and also to bring products to the market as early as possible. For example in Scrum development sprints last 1-4 weeks and in the end of every sprint a piece of software is built. This piece is fully functional and ready to be tested with real users.
 

Working in an agile environment also sets some clear development limitations. The constant lack of time makes it harder to build unneeded functionalities and it’s harder to overthink. Focusing on the important aspects and having regular weekly meetings, is what helps you steer the ship in the right direction.

You might think that agile is the best way to approach development, but agile doesn’t work everywhere. Sometimes it only gets you in trouble.

In our experience projects tend to fail when people start to push it in environments that are not agile by nature. This tends to look like a circus clown trying to attach a saddle to a wild bull which, as you can probably imagine, is not a pretty sight and can lead to some serious injuries.
 

When to go agile

If you take in consideration the estimated time that goes into building a functionality then agile does not mean cheaper costs, but it does help you focus on what’s important.

If requirements are clear and functionalities are well defined then traditional methods tend to be cheaper, i.e. when due to technological reasons a software that the users have grown to like is rewritten.

Agile is also not the best for building critical systems. You can’t build process management and automatic guidance systems in small chunks which might or might not explode. In certain places you can only launch a product that is thoroughly thought-out, tested and not in any way rushed.  

In our experience agile works well in companies and organisations that are agile themselves. It often shows great results for game developers and startups, and for everyone else who are not developing critical applications.

There are also other types of institutions - corporations and public sector institutions where a lot of people are talking about agility, but real work is done in an environment where it is simply not possible due to legal restrictions. Even though people themselves might be fascinated by it.
 

Waterscrum – a mix of agile and traditional development methods

This is why a lot of developers have opted to a development method called waterscum, waterscrumfall or wateragility, meant for companies who talk a lot about agility but are not developing in an agile way.

A waterscrum project begins with clearly isolated user requirement analysis. Work is usually organized into 1-3 week long sprints.

User requirements are usually based on the user requirement analysis done in the pre-analysis stage. This is in contrast to a typical agile project where they are gathered on the go. Development is done in the end, either at once or in multiple sprints.

This is not an unsuitable combination. In large organisations it is often what people perceive agile to be. It is important to understand that in certain places non-agile methods show great results while agile methods fail.

Recently there have been discussions in the Estonian public sector that „developers should not be restricted by the current legislation. Instead we should think things through and change the legislation, so that it makes sense. “

This way of thinking is good, but legislation is not a very agile process. In fact, it is slow, cumbersome and energy consuming.

Laws can’t be changed in a series of sprints. Before doing anything you need to have a solid overview. Then you can pick out the right tools for the job.

We do however encourage you to move towards faster changes and use the opportunities interaction designers and analysts can provide you. These two that can greatly help your projects succeed and increase the odds of getting good end results
 

How interaction designers and analysts can help

It takes a lot of time to assemble large development teams. This is mostly because good developers have projects already in the pipeline and finding good coders can take a massive amount of time.

Due to a smaller work volume (compared to the developers’) we are usually ready to begin in just a few months. User requirement analysis and prototyping takes a good amount of time, so you can use this time to gather a good development team. 
 

Prototyping is heavily recommended in all projects that are larger than average.

This is because you now know that the requirements that were written down earlier work. User testing is important because the system you are building needs to be clear to the end users. Bad user experience = more complaints and lost revenue.

User testing lets you to see how your users understand the system. If there are any hiccups in the system's logic then designers can make changes until no significant errors are found.

You get a tested prototype and a set of requirements that make the development process faster because the developers now have a clear idea of what they are building.
 

Conclusion

Seriously consider the pros and cons of various development methods. Don't go with the fad  If you need to make a choice between a fashionable and a tailored option then do go with the second and don’t neglect testing!
 

Share your experiences!

Got an interesting story to tell? Leave a comment to share it with our readers. If you have any questions or if you want to know more about the subject then write to us at trinidad@trinidad.ee.