During my 15 years working in the design industry a lot has changed. Styles, tools, trends, CMYK to RGB. Millimetres to pixels, CRT to LED, clicking to swiping, WAP to APP.
I’ve worked within the newsroom of the most circulated English language newspaper in the world, which, at it’s peak had a circulation of around 4.5 million. The two methodologies we used there where “The louder I scream, the faster you go” approach or, if you weren’t at your desk, the post-it note methodology. How this worked was the louder the shout, the sooner the deadline. Or, the more post-it notes stuck on your screen, the more urgent the request. This technique worked well in a newspaper environment where the longest deadline is 8 hours. In fact everyone from the Editor, Deputy editor, picture desk, back bench, front bench, middle bench, subs, super subs, News, features, sport are all shouting, the only department that refrains from shouting is HR.
The crossover from print to digital was a relatively smooth transition for me. But working in a digital environment is immensely different. You can’t send a newspaper off stone with a big empty hole in the middle. Whereas, online you can chuck it through the CMS now, then spend the next hour tweaking it.
From a development perspective, things differ even more. We use processes such as waterfall, Iterative waterfall, Agile/Scrum and Lean methodologies. Each has their pros and cons. And I believe it should be the project that dictates what methodology you use.
So, as a designer, which methodology is more preferable? Well, try telling a designer to create a “send” button but not to make it perfect, just an MVP of a button. A MINIMAL VIABLE BUTTON. Most will look at you and think “I’m not doing a half-assed job”. That’s the Agile approach in design.
Waterfall is so called as this type of development is often planned using a Gantt chart – you complete one phase (e.g. planning) before moving on to the next phase (e.g. development). In Waterfall approaches, you will rarely aim to re-visit a ‘phase’ once it’s completed. As such, you better get whatever you’re doing right the first time! This approach is highly risky, often more costly and generally less efficient than more Agile approaches.
Alternatively, the Agile movement proposes alternatives to traditional project management. Agile approaches are typically used in software development to help businesses respond to unpredictability.
What’s Wrong With Traditional Approaches?
In 1970, Dr. Winston Royce presented a paper entitled “Managing the Development of Large Software Systems,” which criticized sequential development. He asserted that software should not be developed like an automobile on an assembly line, in which each piece is added in sequential phases, each phase depending on the previous. Dr. Royce recommended against the phase based approach in which developers first gather all of a project’s requirements, then complete all of its architecture and design, then write all of the code, and so on. Royce specifically objected to the lack of communication between the specialized groups that complete each phase of work.
It’s easy to see the problems with the waterfall method. It assumes that every requirement can be identified before any design or coding occurs. Could you tell a team of developers everything that needed to be in a software product before any of it was up and running? Or would it be easier to describe your vision to the team if you could react to functional software? Many software developers have learned the answer to that question the hard way: At the end of a project, a team might have built the software it was asked to build, but, in the time it took to create, business realities have changed so dramatically that the product is irrelevant. Your company has spent time and money to create software that no one wants. Couldn’t it have been possible to ensure the end product would still be relevant before it was actually finished?
Today very few organisations openly admit to using waterfall or traditional command and control. But those habits persist.
Why Agile?
Agile development provides opportunities to assess the direction throughout the development lifecycle. This is achieved through regular cadences of work, known as Sprints or iterations, at the end of which teams must present a potentially shippable product increment. By focusing on the repetition of abbreviated work cycles as well as the functional product they yield, agile methodology is described as “iterative” and “incremental.” In waterfall, development teams only have one chance to get each aspect of a project right. In an agile paradigm, every aspect of development — requirements, design, etc. — is continually revisited. When a team stops and re-evaluates the direction of a project every two weeks, there’s time to steer it in another direction.
A Kanban Board is used to visualise the flow of work using Agile methodology.
This “inspect-and-adapt” approach to development greatly reduces development costs and time to market. Because teams can develop software at the same time they’re gathering requirements, “analysis paralysis” is less likely to impede a team from making progress. And because a team’s work cycle is limited to two weeks, stakeholders have recurring opportunities to calibrate releases for success in the real world. Agile development helps companies build the right product. Instead of committing to market a piece of software that hasn’t been written yet, agile empowers teams to continuously replan their release to optimise its value throughout development, allowing them to be as competitive as possible in the marketplace. Agile development preserves a product’s critical market relevance and ensures a team’s work doesn’t end up on a shelf, never released.
When should you use Waterfall methodology?
- When there is a clear picture of what the final product should be.
- When clients won’t have the ability to change the scope of the project once it has begun.
- When definition, not speed, is key to success.
When should you use Agile methodology?
- When rapid production is more important than the quality of the product.
- When clients will be able to chance the scope of the project.
- When there isn’t a clear picture of what the final product should look like.
- When you have skilled developers who are adaptable and able to think independently.
- When the product is intended for an industry with rapidly changing standards.
So which is best?
Agile and Waterfall methodologies both have their strengths and weaknesses. The key to deciding which one is right for you boils down to what type of project you are dealing with. If it’s going to be a project that changes rapidly then Agile is probably the most appropriate. If you know exactly what you need then maybe waterfall is better in this situation.
Or, why not be a fruitloop and mix the two up to combine both methodologies. Doing this can create the best development process for your project.
