The first week of the Development Practice course we started looking at time management and how different development methods can be utilised to improve it. In this post, I will quickly cover the different methods and share my experience and opinion on them.

Development methods

Waterfall

The Waterfall development model takes its name from its structure. The model is fully linear which is both its strength and its weakness. While it provides a lot of structure it lacks support for reflection and incremental improvement, which is so prevalent in development nowadays.

Agile

Agile is a term used to describe all different development models that focus on continuous delivery and adapting to rapidly changing requirements. It aims to address the issues with Waterfall, namely the lack of incremental improvements. Agile defines regular cycles of delivery and iteration in order to factor those changing requirements into the next iteration. Here I will review two of the most prevalent approaches.

Kanban

Kanban originates from manifacturing. It focuses on visualising the work that needs to be done on a board (most of the time nowadays a digital one) and the individual workflow steps that each piece of work needs without defining sprints or other team synchronisation or reflection points.

Scrum

The Scrum model build on top of Kanban and provides regular catch-ups and retrospectives to allow the team to reflect and improve their structure, process and practices.

In my opinion Scrum and Kanban can be combined to utilise the benefits of both. To me agile means doing what works best for your team and project so teams should not feel obligated to strictly conform a single agile approach. Instead they should take advantage of the tools provided (such as retrospectives) to establish their preferred practices.

In summary

Picking the right development method is one of the most important decisions a team has to make. It must be driven by a wide variety of factors such as team size, type of project the team is working on and even the client expectations for the delivery of the project. If the client expects one delivery at the end and the team is very large a waterfall method would provide rigidness and stability and allow the disjointed collaboration of the team. On the other hand, if the people are split into smaller teams and their project is some form of a service (a website or a "game as a service") an Agile approach would suit the team a lot better. However, each of these methods has drawbacks which have to be considered and mitigated to ensure the success of the team (Mohammad and Alwada'n, 2013).

In reality

In my career, I've been working in small to medium size companies on a wide variety of projects - from websites like Skyscanner to phone apps for the oil & gas industry and optimising people's workflow. So far, all companies choose Scrum as the predominant approach. I believe the choice is definitely better than sticking to the workflow model as smaller teams can be more cohesive and collaborate more effectively.

This, however, is not always the right choice for the team. In a lot of cases, the decision is driven from "higher up" in the company and is enforced on all teams. This is because the consistency makes monitoring team accomplishments easier for the CxO team. Ensuring that there is a data point for each team each week for their progress and whether or not they delivered on what they have committed the previous week.

One negative of Scrum is that if it is not applied in the right setting it can slow down the team towards the end of each sprint. This can happen when the delivery of features is fully continuous rather than in batches each sprint. In this situation, the sprint is nothing more than a grouping of tasks that need to be done and a limitation of what can be picked up. Towards the end of the sprint, there would be fewer tasks to work on and sometimes not all people will have something to work on. In such situation, the right decision is to pull a stretch card instead of getting more people to work on said tasks as in most cases getting people up to speed is only going to slow down the progress.

What I think would resolve a lot of the problems is allowing flexibility to each individual team (within reason of course) with support from dedicated experts within the organisation. That would allow the optimisation each team needs to deliver at their peak velocity and reduce the frustration of the individuals in it.

A new perspective I am looking at is how this can be applied to the Games Industry. Waterfall and Scrum can be combined where, initially, only the designers would be involved in the project until the design has evolved enough for prototyping to start. Afterwards, all of the creative team and the programmers would work together until the project is mature enough for the QA team to join as well. The result would be an overall Waterfall approach which is not fully sequential but has slightly overlapping steps and the freedom to utilise the increased flexibility of Agile within each step.

References

Mohammad, A.H. and Alwada'n, T., 2013. Agile software methodologies: strength and weakness. International Journal of Engineering Science and Technology.