There are a plethora of different management philosophies and this week we covered 2 of the most common systems: Waterfall and Agile. Both these systems are methodologies that whole teams follow during a product’s lifespan in order to coordinate development.
In my experience Agile is more modern and is what nearly all of the teams I have worked with have used, I do however find that Waterfall still has its uses and is valuable when you need to get things done without contact with the client until the deadline, and works well for tasks that don’t benefit as much from being more flexible such as when the deadline is equally inflexible or when you have a specific set of requirements you have to meet, although at the same time Waterfall suffers from being more rigid as it cannot adapt to changes as well as Agile can meaning often Agile development will create a better product that has the benefit of the experience gained during development affecting the release.
Let me explain the two systems in a bit more detail.
Waterfall:
Just as a waterfall flows down a cliffside, as does development fall down a series of phases during development, each of which must be finished before moving to the next. Waterfall is a more traditional workflow that has been used for many years, making it a reliable means-tested methodology. The product is designed in full at the start of the project giving an accurate view of what the end result will be like and the design is then unchanged as the development progresses. This makes the whole process very predictable as there is an unchanging design, developers won’t have to account for unknown changes later on in development, something that makes my own work much more difficult. There is a large advantage for a customer however in that it allows them to be very “hands-off” as they just need to confirm the design and the team can then work on it without needing anything else.
There are also several cons to this methodology as well, however. Because the design is unchanging, feedback is not taken into account as the product develops and this can lead to the team missing key requirements that would arise during development and potentially a worse or even faulty product. It is even possible that delays in production occur because people understand the design documentation in different ways without the feedback Agile methods have built in to catch these errors. The testing is all done at the end as well so if there are major issues, they are much harder to address.
Other issues with this methodology can arise when we see that design is done in full before a product has even started full development. An investor or customer will not see any of the product until the design has been finished and while this may give confidence in what the product is, it will cost a lot more time than an Agile methodology would to reach that stage. So using video games as an example, marketing could not happen as early as there is no product to show, meaning there would be a delay in beginning to grow an audience and potentially a smaller release because of it.
There is a modified Waterfall model called “Royce’s iterative feedback” that addresses the lack of iterative feedback but it’s not as flexible as Agile and involves taking huge steps backward to redesign, see below.
The stages of Waterfall can vary but are usually as follows:
1. Plan
A feasibility study will be carried out assessing strengths and weaknesses of a project comparing cost against value gained by stakeholders, this study contains a risk assessment and analysis.
2. Define
Requirements get locked down and an informal document is created called a statement of requirements containing the context, key objectives, and constraints. SMART targets may be used, SMART stands for specific, measurable, achievable, relevant, and time-bound.
3. Design
Different solutions will be investigated and assessed and a system design document is drawn up. Finally, a design will be selected.
4. Build
Development starts and designs are implemented. Basic testing of solutions will still happen during this stage however it will not be as intensive as the testing phase and likely focused on specific solutions.
5. Test
Intensive and focused testing with an aim to get the product ready for release. Bugs will be fixed and quality standards will be achieved. User Expectance testing happens during this stage, otherwise known as beta testing.
6. Deploy
Either an MVP is deployed first with new features are added as the product proves to be stable or the whole product is deployed at once depending on how confident the team is in the product’s stability. This could be compared to a game release.
7. Maintain
This would be post-launch updates and bug fixes for a game, however as a product lifetime goes on, new hardware or software changes or updates may be needed.
8. Evaluation
For games, we do an evaluation a few weeks after a product has launched to look at how successful we achieved our goals outlined in the define stage and how successful the product has been commercially. It is important to analyze both what worked well and what did not work in order to begin the next project in a more experienced and prepared way.
9. Disposal
This is the only step I have not yet done myself but I may have to eventually, it involves plans for how to end a product’s lifespan. If a project fails commercially or you need to shut it down for whatever reason, perhaps due to server costs or aging hardware, this stage covers how you would do that.
Scrum and Agile:
Agile development was created in response to Waterfall’s downsides and because of this offers more flexibility than Waterfall but also more uncertainty to the development process. Unlike Waterfall which is linear, Agile is iterative and involves smaller repeated Sprints, often depicted as loops and frequent review allowing the design to be changed to suit the needs of the product as they become apparent. The process also puts the development closer to the customer with feedback being more frequent and at set periods. Many products benefit from this kind of development as it can better meet the needs of an audience as the audience grows or changes, This leads to massive advantages for projects with continuous development or products as a service.
Scrums are used in Agile development as a key tool in progress tracking and time management. I have seen various structures for Scrums however some key roles include the Scrum master who organizes the Scrum and the Product Owner whose responsibility is to select the features from the backlog to develop. Its worth noting however that every member of the Scrum is considered equal, despite these roles.
One of the biggest advantages of Agile development is its flexibility. If something changes during development, the team is encouraged to adapt to the change in order to produce the best product through regular reviews at the start and end of Sprints. However, the only way to change the Backlog for the current Sprint is for the whole Sprint to be canceled by the Sprint Master. Individuals working in Agile structures are encouraged to be trusted in their area of development, this empowers the team and makes management simpler, often allowing team members to be self-organized.
Another large advantage to Agile development is that your product can get to market quicker as development starts much sooner, this means more of the product will be ready to show an audience for marketing and often that the product is ready on demand, even if not with a full feature set. This can also reduce risk as the product is always available in some form, unlike Waterfall where you could hit issues during the design stage and have nothing to show for it.
Of course, there are downsides for Agile as well, and although this method is more popular, we cannot ignore them. The main issue with Agile is that it is much less predictable than Waterfall, this is due to its iterative nature which allows the Product Owner to change direction or adapt to external changes, which while flexible, is a weakness as much as it can be a strength. The Product Owner must also be close to the product and invest their own time which some may not like, They are a member of the Agile team and should treat themselves as such, without them, the whole process fails. One reason the Product owner must be more involved is that iterative development does not support documentation as well as a system like Waterfall, the requirements regularly change and dependencies will be created and destroyed as the process moves on. This also means that things will be changed and may need to be reworked, which from a Product Owners point of view will require a lot of trust, and understanding of the project.
There are several types of Agile development, some include XP, Scrum (discussed here!), Kanban, Lean, and Agile Unified Process. Here I discuss primarily Scrum, however, I have also used Kanban in the past which involves a similar process but using a board filled with tasks that a team member can claim or be assigned to work on. When a task is done, it gets moved to be checked in then eventually moved to a “done” section. The process is similar, we get tasks each week and then review the next, it’s just a more visual way of organizing tasks.
Agile development is not as linear as Waterfall and the process is a little different, instead of the progress moving from 1 area to the next, there are some concepts to go over:
1. Product backlog
A detailed list of all features, usually created by the Product Owner
2. Sprint backlog
The current tasks in progress, it gets set during planning meetings at the start and end of Sprints.
3. Sprint
A period of time when people are working on tasks from a Spring backlog, usually 2 weeks but can vary. It can only be changed by the Sprint Master due to either unforeseen circumstances or major product changes.
4. Scrum
A daily meeting to go over what was worked on yesterday, the current task, and if there are any obstructions. Intended to be quick and for information distribution.
5. Sprint master
Leader of a Sprint
6. Product owner
A person who defines the vision of the product in collaboration with clients, owners and the Scrum team
7. Sprint Review
A meeting to look at progress against goals. Hopefully shows a shippable product.
8. Sprint Retrospective
A meeting to look at what went well, what went wrong, and what could be improved
Process
The process of an Agile development would be:
1. Create Product Backlog
2. Select tasks for Sprint Backlog
3. Start Sprint
4. Daily Scrum until Sprint ends
5. Sprint Review
6. Sprint Retrospective
5. goto 2
6. repeat until the project is finished
References:
Atlassian. 2021. What is Agile? | Atlassian. [online] Available at: <https://www.atlassian.com/agile> [Accessed 17 June 2021].
Parsons, T., 2021. When to Use Waterfall vs. Agile | Macadamian. [online] Macadamian. Available at: <https://www.macadamian.com/learn/when-to-use-waterfall-vs-agile/> [Accessed 17 June 2021].
Segue Technologies. 2021. Waterfall vs. Agile: Which Methodology is Right for Your Project?. [online] Available at: <https://www.seguetech.com/waterfall-vs-agile-methodology/> [Accessed 17 June 2021].
Trust Radius. 2021. [online] Available at: <https://www.trustradius.com/buyer-blog/difference-between-agile-vs-waterfall> [Accessed 17 June 2021].
ResearchGate. 2021. Figure 1: Waterfall model with Royce’s iterative feedback. When…. [online] Available at: <https://www.researchgate.net/figure/Waterfall-model-with-Royces-iterative-feedback-When-referring-to-the-waterfall-model-in_fig1_220631422> [Accessed 17 June 2021].
Blackwell, Jonathan. (2018). Applied Visual Metaphors in Organizational Management.
Course material