I attended my first seminar on Wednesday, which gave me some insight into what the unit of Development Practice will be about. Its essentially going to be about developing myself as a reflective practitioner, meaning that I develop not only my skills but my capacity to reflect on why I develop and use the skills I have in the way I do and how it relates to my chosen path.
I have found that this unit, and presumably subsequent units have been organised according to a methodology called Scrum, which itself is an Agile framework for project management in software development. The weeks have been organised into what are known as sprints, which are as follows.
- Orientation
- Rapid Ideation 1
- Rapid Ideation 2
- Finalise
We are currently on the first sprint of this unit – Orientation, which means that this sprint is about developing the knowledge and methods so that I can be more reflective. I have to admit that I initially did not understand why the unit was set up like this when I first saw it or why we describe each stage as a sprint. This did trip me up at first but I started to gain an understanding of this when I read up on Agile framework and more specifically, Scrum.
As Agile framework is largely used in software development, this is something which I lacked any knowledge in, though I had heard of it. While I come from an artistic background, I realise there will be a huge amount of overlap with programming and that in studying game development, creative and technical skills will very often converge. Indeed, we cannot forget that game development itself is a form of software development, as games themselves are pieces of software with the use value of being played and therefore a methodology that was made for software development would be the most appropriate.
This would mean that I need to develop my own coding skills to complement my creative skills, but it would also mean that I will be working with others that specialise in programming. I also need to be careful not to polarise and talk as though there is a fine line between those who are artistic and those who are technical because we will all count on one another and learn from one another to produce high quality games. I decided to do some research into Agile and in particular, Scrum in order to find out why this is being encouraged over other traditional means of project management.
Waterfall method
Before diving into Agile, I had a look at a more conventional methodology for project management and assessed its drawbacks.
The waterfall method is named as such because apparently it consists of each step followed by the next in sequence (Intetics, 2016). I guess it’s named as such because it starts in one place and inevitably ends in the other.
A waterfall methodology would consist of a team of experts, all of whom have been assigned specific titles and are designated a fixed set of duties according to their title and expertise (Flex.falmouth.ac.uk, 2020).
The waterfall methodology consists of one end goal and one vision for the product that is being developed, which never changes. To reach this goal, the waterfall methodology consists of the following stages
- Planning – This stage consists of researching and studying the feasibility of this project, as well as the value for its stakeholders
- Define – At this stage, the requirements of the project get locked down
- Design – This stage acknowledges more than one solution to a problem and the system architect analyses these before selecting the most appropriate components to
- Build – Possibly both the longest and the most intense of all the stages, this stage is where all of the development of the product happens, as soon as everyone in the team understands how it works
- Test – This stage is done throughout the lifecycle of system development in preparation for deploying the system to ensure there are no bugs and everything has been set up correctly
- Deploy – This is when the system is released after it has passed the when the system passes the testing stage. can be done in stages or if everyone is feeling confident, can b deployed at once
- Maintain – This last stage is an ongoing one and involves updating it to accommodate changes such as developments in hardware and replacing redundant hardware. This stage is often overlooked and can do untold damage to the system design. incremental checks should be factored in, redundant hardware replaced
While I am rejecting this methodology, its important to remember that its not just problematic in itself. It does have some advantages. It is very easy to schedule the stages, owing to its rigid structure . Each stage of the process also requires heavy documentation, meaning there is little room for ambiguity and each member of the team should know what is expected of them.
Now, there are many drawbacks as to why I will not be using this method. There is no room for reflection in this method and no accommodation for change. This is done entirely as a pipeline production where only the end vision is considered and once the path for reaching that vision is set, there is no room for flexibility.
There is no overlap considered in this model and each stage is done in sequence. This could particularly cause problems as certain stages require overlap to avoid problems later down the line, such as building and testing.
There is a lot of risk involved here as majority of the development is carried out late into the lifecycle of this process. This methodology offers very little leeway for the end user to see prototypes, designs or work-in-progress and little to no opportunity for their input to lead the direction of the end product. Furthermore, this methodology is intensified by the fact the development only happens during the fourth stage of this process and even if this stage is broken down into micro-stages, it leaves little room for flexibility.
Most of all this methodology does not accommodate, reflective practice as each part of the process is done in sequence and essentially in isolation and would not accommodate the level of intensity required for this unit.
Agile
Before I move onto analysing Scrum, I need to talk about Agile.
Agile is a set of frameworks for project management as part of the system development life cycle. Agile is not one methodology but there are many methodologies within Agile and Scrum is just one of them (Productplan, n.d).
There is indeed a manifesto on what Agile represents, which was written up by several of the pioneers of Agile and can be read here.
Agile is essentially a non-hierarchical approach to system development that prioritises people and customer satisfaction. It is focused on each of the team members interacting with one another equally and using a broad range of skills to collaborate and develop working software. In contrast to the Waterfall method, Agile methods are designed to allow team members to respond to changes that arise, rather than relying on comprehensive documentation and a set plan. While the end vision is never lost, Agile methods focus on reaching it in increments or smaller stages, which allow for quicker and more flexible development.
While there are may methods of Agile that exist, I will mostly focus on Scrum, as this is one of the most lightweight and easy to learn Agile methods. I will explore Scrum and how it applies to reflective practice specifically but also how it can be applied to other areas of my development.
Scrum
I am already very familiar with the term ‘scrum’ as I follow the Six Nations every year. In rugby, a scrum is formation in which both opposing teams bind together in rows to gain control of the ball and restart play after either a foul in the case of rugby union or if the ball goes out of play in the case of rugby league.
In this analogy, the scrum is a metaphor for the team developing a project and the ball is the project. The ball gets passed between each of the players many times during a scrum and in a similar way, the project gets passed between several of the team members, all of whom have different expertise.
The scrum is an ideal analogy for this Agile methodology as it scrums happen many times during a rugby game and project management. A rugby game is played in phases and while all the players in a rugby team have a clear goal in mind, which is scoring that try, the very rules and mechanics of a rugby match demand that the team achieve this through multiple phases of play. An Agile framework functions much like a rugby game in this respect as the vision of the project is achieved in increments.
This type of approach to teamwork can also be applied to certain co-operative multiplayer computer games, particularly real time strategy. Take Defence of the Ancients (Dota) for example (Valve, 2003 and 2013). The object of a Dota game is to ultimately reach the opposing team’s base and to destroy their structure, known as an ‘ancient’. However, this cannot be done by simply buying the most expensive available items for your character, rushing straight into combat with the other team as you will otherwise get quickly obliterated.
Instead, a good Dota game is played in stages, first you work together to accumulate as much gold as possible to buy weapons and armour, which over time you upgrade and you also utilise your creeps to fight with the opposing team’s creeps, as well as their towers in order to advance forward. Eventually as you become stronger, unlock more abilities and destroy more of the opposing team’s forces, you can then work your way to achieving the goal of destroying the opponent’s ancient.
The Scrum team
A scrum team is non-hierarchical and works towards a common goal (Cprime, 2021). The team is less defined by specific titles and instead all members can bring their range of skill sets to the project to ensure it is realised. This will be very important throughout the course of this masters as everyone who is studying on this course- judging by the introductions people have given on Canvas – has come from a vast range of professional and academic backgrounds. We all have very diverse and unique skills that we can bring to this course and as this is a co-operative process, we can all learn from one another and bridge gaps.
Within a scrum team, there are two unique roles that need to be appointed – the Scrum Master and the Product Owner. These roles are considered equal to the rest of the team as it is the entire team is collectively responsible for the project, but these roles are still crucial.
The Scrum Master is responsible keeping the project moving forward, maintains the unified vision of the project and mediates between team members as well as recording any obstacles along with way.
The Product Owner is a key stakeholder of the project. They could be a client or an integral member of the scrum team. They must have a great insight and understanding of the project as well as its intended users. The product owner’s main role is to oversee the product backlog, which is the name given to a list of features and assets to be implemented by the rest of the team. The product owner organises the product backlog according to priority.
The product backlog
Once the vision and the end goal is established in a project, the product backlog is created. The product backlog forms a backbone of the project and it grows over time when new features are added or issues arise such as bugs. The product backlog is established through a series of user stories, which are written by the product owner and give an idea of how users will interact with the product and therefore what features will be required.
The sprint
The sprint is an integral part of the Scrum project life cycle and earlier in this post I established how this unit had been divided into sprints.
A sprint starts with a clear, concise product vision which is establish not just by the Scrum team but also in collaboration with other stakeholders such as clients or potential users. This is one of the most significant ways Scrum diverges from Waterfall in that the client and end users are involved throughout the process and this helps maintain a unified vision.
A sprints is usually 2 weeks long but this may vary. The development practice unit has been developed to 3 week sprints in order to accommodate part time learning.
Teams should opt for the shortest sprint possible as this allows users the leeway to make mistakes quickly in a short time frame, but also to learn from them quickly. The sprint should neither be too long or too short. Not too short that it intensifies the process and incites panic but not too long that team members become complacent and slow the pace of work.
This is crucial to being a reflective practitioner on a Masters’ degree, as I will need to learn new skills in a short time frame, but I will also need to be allowed to make mistakes that I can learn from and become more rounded in my practice. This is yet another example of how Scrum is radically different from Waterfall, in that it embraces failure as part of the learning and development process.
Sprints always start with a planning meeting, which consists of the team negotiating tasks from the product backlog according to the backlog. Tasks that are chosen for a given sprint are are added to the sprint backlog and once the planning meeting is done, the sprint backlog is locked in and does not change during the duration of the sprint. Commitments to a sprint cannot be changed once it has started.
The only ways that the course of a sprint is altered is if the sprint master decided to cancel the entire sprint due to unforeseen circumstances or major product changes that would prevent the sprint from going ahead.
Stand-up meetings
During every day of a sprint, the Scrum team has stand up meetings, which are named this because they are generally held with all attendees, who can, standing up.
They are intentionally kept short and to ensure all members of the team are kept up to date with the progress of all other team members and useful for disseminating information to everyone integral to the project.
Each member answers the following questions during this meeting:
- What did they do yesterday?
- What do they intend to do today?
- What is blocking their progress?
The Scrum Master documents all of the obstructions mentioned and will then have one-to-ones with team members to help them overcome these obstacles.
This format is somewhat similar to what my team does in my current job. All members of the creative time have a 20 minute catch up meeting each day to talk about what they did the day before and what work they need to do today, as well as any problems they are having. These are also supplemented by one to one meetings with our line manager to discuss any further issues.
Stakeholders, such as clients may also be present at these meetings, which mean that they have more input into the entire development process which ensures the original vision is not lost and it also means they have an opportunity to see more of the development work throughout the process and not just at the end.
The end of a sprint
At the end of a given sprint, two final meetings will be held to help bring that part of the product development lifecycle to a close.
The first is a sprint review where the progress made is weight up against the goals. The hope is that the product backlog is complete and that a product is ready to be demoed by the team.
The second is a sprint retrospective which acknowledges that there can always be room for improvement. The three main questions that are raised here are:
- What went wrong
- What went well
- What can be improved
This helps the team maintain awareness around a project and see the bigger picture. Once the sprint retrospective is complete, the process starts again and the succeeding sprint commences.
Conclusion
Having analysed and reflected on the Scrum, I can certainly understand why this unit has been formatted in the way that it has. It has been done to ensure that we can learn quickly in a short time frame and reflect from these on a frequent basis. While I cannot say for sure that the Scrum methodology will work for future projects as I have not applied it before, this analysis indicates that there is a strong likelihood that applying this methodology will help us to develop projects in a relatively quick but efficient manner within a small team.
Scrum methodology offers a very democratic approach to project management and it will allow us to collaborate and begin the development process fairly swiftly while allowing us to reflect on how well a project is going and where there is room for improvement.
While studying Scrum, I did a course about it on Linkedin Learning (O’Connell, 2020) and I am pleased to say that I am now certified in the basics of Scrum.
References
Beck, K., Beedle, M., van Bennekum, A., Cockburn, A., Cunningham, W., Fowler, M., Grenning, J., Highsmith, J., Hunt, A., Jeffries, R., Kern, J., Marick, B., Martin, R., Mellor, S., Schwaber, K., Sutherland, J. and Thomas, D., 2001. Manifesto for Agile Software Development. [online] Agilemanifesto.org. Available at: <https://agilemanifesto.org/> [Accessed 29 January 2021].
Cprime. 2021. What is AGILE? – What is SCRUM? – Agile FAQ’s | Cprime. [online] Available at: <https://www.cprime.com/resources/what-is-agile-what-is-scrum/> [Accessed 28 January 2021].
Flex.falmouth.ac.uk. 2020. Time and Agile Development. [online] Available at: <https://flex.falmouth.ac.uk/courses/911/pages/week-1-time-management-and-agile-development?module_item_id=49134> [Accessed 28 January 2021].
IceFrog. (2003) Defense of the Ancients [Computer game]. Valve.
Intetics. 2016. Waterfall vs. Agile: How to choose the right software development methodology for your IT project | Intetics. [online] Available at: <https://intetics.com/blog/waterfall-vs-agile-how-to-choose-software-development-methodology> [Accessed 29 January 2021].
O’Connell, K., 2020. The scrum approach to project success – Scrum: The Basics Video Tutorial | LinkedIn Learning, formerly Lynda.com. [online] LinkedIn Learning. Available at: <https://www.linkedin.com/learning/scrum-the-basics/the-scrum-approach-to-project-success-2?u=56738929> [Accessed 28 January 2021].
Productplan.com. n.d. What is an Agile Framework? | Definition and Overview. [online] Available at: <https://www.productplan.com/glossary/agile-framework/> [Accessed 28 January 2021].
Productplan.com. 2021. What is the Scrum Agile Framework? | Definition and Overview. [online] Available at: <https://www.productplan.com/glossary/scrum-agile-framework/> [Accessed 28 January 2021].
Valve. (2013) Dota 2 [Computer game]. Valve.
8 Replies to “What is Agile / Scrum?”