GDD710 Development Practice Module - Week 1 - Research
________________________________________________________________________
I always considered the term "Agile" to be a methodology of its own nature. On the contrary, it is a somewhat philosophy. What I mean here is a set way of thinking, made up by a variation of values and principles from a document called the Agile Manifesto. Agile itself is a collection of methodologies based on interative development.
These methodologies involve Waterfall, Scrum, and Kanban, I will be elaborating on these types, as well as a newer addition to SDLCs called an Agile-Waterfall Hypid, known to few as the Incremental Method.
________________________________________________________________________
Figure 1: Fez, 2012. Polytron Corporation [Online] http://fezgame.com/
________________________________________________________________________
Waterfall
Waterfall is known to be the oldest SDLC model to be used for software development. Also known as the "Linear-Sequential Life Cycle", Waterfall has a one-way natural flow of development. This is because each phase acts as an input for the next, in a sequential way. Overlapping these phases would be breaking the strict rules of Watefall's process. Below is an Illustration of Waterfall that I encountered and comprehended over the years.
Waterfall Model
Figure 2: Waterfall Model (Solent University, 2019)
________________________________________________________________________
Waterfall Model Breakdown
1. Requirements - Any potential criteria, instructions or deadlines that need to be put into place. This stage manages the foundational aspects of the project, disregarding the specifics. This is where applying SMART goals occurs, depending on the product.
2. Analysis - System criteria is analysed, generating a products models and the business logic, bridging communication between the end-user interface and a database, thus applying production guidance. Product resources are also examined for feasability.
3. Design - The design specifications are constructed, outlining the technical design criteria. This involves the choice of programming language, hardware, overall software architecture and sources of data.
4. Implementation - Product source code is developed using given criteria from previous phases. In a traditional approach, the system is designed into minor components or elements. This allows ease when connecting and implementing all the pieces together.
5. Testing - A wide selection of testing on the product takes place, such as Quality Assurance, Unit, Intregration, System and User Acceptance Testing. This ensures any documented issues to be fixed and resolved. This can cause a repeat of the Implementation phase due to debugging.
6. Release - Release or deployment of completed product. At this stage, product is deemed as fully functioning to an open and live environment. Sometimes the Minimal Viable Product (MVP) can be deployed to prove full stability, followed by a full release depending on stability outcome.
7. Maintenance - The final phase, full of monitoring and optimising to improve and enhance the completed product. This is demonstrated through patch updates and latest versions of software and hardware.
There are alternative illustrations of the Waterfall model. These include 2 extra phases called Evaluation and Disposition that take place after the original iteration. They tend to be used more during game development. Evaluation outlines the successfulness of the product after its time of deployment, measuring whether or not the original goals and criteria have been achieved on a commercial scale. This allows a beneficial analysis on the success and failure. Learning from any mistakes will assist through other projects to carry out in an improved and prepared manner. Disposal is the end road for a product. When does it stop? How do we move on? depending on the results from its performance and duration, this is the stage that will cover what is the best course of action, whether to continue or shut the product down.
Ideally, Waterfall should be used for small-scale projects that have a particular documentation, fixed criteria, well-implied technology and an orthodox timeline. The use of scheduling and deadlines can facilitate departmentalization, as well as managerial control and a clearly-outlined focus in key milestones (Sarah Lewis, 2019) .
________________________________________________________________________
Scrum
For starters SCRUM is not an ancronym, but an interative and incremental framework, using principles of Agile software development to encourage teamwork (Gunther Verheyen, 2014). It's also classed as a heuristic, allowing constant learning and adjustment to changing factors. Scrum makes an effective framework when used for Agile project management due to its ability to be broken down into smaller elements to construct an MVP.
This implies an efficient, compliant and adjustable method for development. Scrum gets broken down into chunks or blocks, also known as Sprints. Sprints are fixed periods of time where a set of tasks take place. Most Sprints last between 1-4 weeks depending on the final result and modifications towards the final product. Every deliverable is recursive and assists in a more-efficient deployment, ensuring customer feedbacks are also constant. Below is an illustration of the Scrum method.
________________________________________________________________________
Scrum Model
Figure 3: Scrum Model (Scrum.org, 2020)
________________________________________________________________________
Scrum is built upon the "Three Pillars of Empiricism" working together through a fact, experience and evidence-based approach. It applies an empiricial process where progression is establiished on the observation of reality instead of false fabricated methods. Below is an illustration of the three pillars.
Figure 3: Three Pillars of Empiricism/Scrum (Hiren Doshi, 2016)
________________________________________________________________________
Three Pillars of Empiricism Breakdown
1. Transparency - The first pillar acts as the presenter of all the facts as they are. Every member being involved from consumers, to top bosses and even solo contributors have full transparency, meaning full honesty and open communication between eachother on a strongly collective level.
2. Inspection - The second pillar is an all-out inspection team. Also known as the "Scrum Team". This can take place for the product itself, people, processes and constant improvements. For instance, project team openly communicate between the customer at the end of each Sprint for valuable and responsive feedback. Say the customer throws a change in the criteria over inspection, the team does not protest and merely makes neccessary adaptations to the new customer needs.
3. Adaptation - The final pillar is about constant improvements. The ability to adapt to new customer needs that are highlighted from the inspection. A regular question that appears is "Are they performing better than they did yesterday?". Organisations that focus on profit, their company values will be portrayed by the profit it makes from the developed product. The adaptions will in due course achieve one of the choices they considered to implement with Agile. Choices such as this could be the increased income of investment through a value-based delivery, as well as improvement of customer and employee satisfaction.
________________________________________________________________________
Scrums Roles and Responsibilities
Scrum Master -The Master in Scrum Methodology Implementation. Not neccessarily a manager, but more of a guidance coach or influential leader. Their role is to seperate any difficulties that team members may encounter, securing a smooth workflow across the project. Enabling a close and cooperative approach across each role and function to address any disobediance affecting the practices of Scrum.
Product Owner - Product owners of Scrum are responsible for maximizing return of investment (ROI) as well as the writer of user stories and acceptance criteria. They do this by identifying the features of the product, prioritising them into a list and continuously refining the list by importance ready for the next Sprint. They have the authority to cancel Sprints that are leaning towards useless or redundant.
Delivery Team - The Delivery team consists of a small group, usually betweeen 3-9 as any more than that would not be classed as Scrum. They all originate from multiple departments who oversee the completion of their own tasks. These teams tend to work with a self-organised approach, helping one another closely to achieve the same goal, a successful and productive completion of Sprints.
Spirint - Mentioned briefly, Sprints are an event in Scrum that are fixed periods of time which can last between 1-4 weeks, depending on the delivery of valuable increments. Each event from the planning to restrospective take place during the Sprint. Sometimes reconsideration between the Product Owner and developers can occur over the Sprints scope, forming the decision of Scrums empirical nature.
Spring Backlog - The backlog of Sprints is a list of items, User Stories or potential bug fixes, chosen by the developers for implementation in the latest Sprint cycle. The backlog will predict the type of functionality, as well as the criteria to meet that functionality. Sometimes Sprint backlogs can be flexible, tending to evolve as the Sprint continues. Regardless, the fundamental goal of the Sprint cannot be compromised.
Sprint Planning - Sprint Planning is where the scope in the lastest Sprint is discussed by the developers. Usually lasting 8 hours to identify the work shown from the Product Backlog and outline by importance, what must be carried out next and how that can be planned into the Sprint Backlog. Every member of Scrum at the end of each meeting, must make it clear on what deliverables can be met in that Sprint, as well as how the Increment can be delivered.
Sprint Retrospective - The Restrospective side of Sprints is where the whole Scrum team comes together to discuss and highlight what performed well and what performed within a Sprint, project etc. This Restrospective lasts around 3 hours, concluding ths sprint by what went accordingly and what can be improved upon in further Sprints. This allows a core team focus in certain areas, enhancing their performance.
Sprint Review - Taking place at the end of each Sprint, the Scrum team meet for an informal session, entailing the inspection of the Increment. The development team will demonstrate the items from backlog which are listed as "Completed" to the stakeholders, as well as other team members for peer review and feedback. The Product Owner then takes over to disclose whether or not to release the Increment, which usually follows in the majority of instances. The review lasts around 4 hours to finalise all the development within that Sprint.
Product Backlog - The Product Owners primary maintenance list. This vital list containts the products, features, criteria, improvements and mends interpreting as Sprint Backlog input. Primarily it is the Scrum teams agenda. This backlog is repeatedly being re-arranged and monitored by the Product Owner due to the growth and change in the market and outdated components can be discarded. as well as issues resolving in their own methods.
Increment - Also known as a Sprint Goal, is the usable ending Product from a Sprint. It defines a reached goal of "Done" in that Sprint, completed and precious work from the Developers. The more teams in Scrum developing the product, the more mutual decisons must be made to comply that the product is declared complete, fabricating an Increment.
Daily Scrum - This Scrum event is a daily short meeting, taking up to a recommended 15 minute period for all Scrum teams to dicuss their opinions, ensuring they are all in complete agreement with one another on where they are heading with their Sprint goal. The meetings are kept at a daily occurence to maintain consistent communication and effective team collaboration.
________________________________________________________________________
Personal Experience using Scrum
I have had my fair share using the Scum methodology in mixture of solo and group projects. Whilst at University, I was taught a Unit named SWEGMT, meaning Software Engineering for Games, Methods and Tools. The task was to be organised into specific Scrum teams, carrying out and seeing thrugh the development of a horror game. The task was split into two sections to cover A Waterfall Methodology approach, followed by the remainder of the project using the Agile methods of Scrum. We as a team of 4 arranged a meeting over a weekly period, lasting up to 15 minutes. Even though this is more of a Sprint Review than a Daily Scrum, the majority of our meetings covered where each individuals progress was, ensuring we were meeting the correct sprint goals within the given timeframe.
This also gave us the opportunity to validate each others opinions whether we were all on the same page or differing certain views on where the project was going. I wouldn't class this experience as the full defintion of Scrum, merely a construct of elements using an interative process similar to Scrum. In the latter of my studies, I worked on a bigger project named "Tales of Orelia", consisting of a 20-man studio. I took the role of a Lead Designer who was responsible for a weekly review with the design department, outlining their workload for the coming week (Sprint) and kept them on track throughout development .This ensured an effective level of communication and strong team performance. These reviews would then be sent off by myself and other leads to the Senior Producer, as well as what would have been our Scrum Master.
________________________________________________________________________
Scrum adaptation to my own Independent Learning
I aim to apply the Scrum Methodology towards my Indie Games Development studies, by following this set of goals throughout the course:
1. Critical Reflective Journal - Use my CRJ as the backbone of my personal development journey, showcasing my efforts and achievements.
2. Team Collaboration - Collaborate with other students on a regular basis, whether it be the IGD or UXD course internally through study pod sessions and externally using Discord for social catch-ups (essentially a non-intentional Scrum).
3. Time Management - Dedicate precious reading time, familiarizing myself with the latest topics and getting a firm headstart on on the reqiuired workload. This will apply firm prioritising of tasks by importance and urgency.
________________________________________________________________________
Kanban
I have never heard of Kanban until now. It is a highly praised framework, developed by japanese engineer Taiichi Ohnoin the 1940s. It's main functionality was for a simple planning system, aiming to control and manage the work , cataloguing every stage of production. Ideally, Kanban controls the set of activities, also known as a "Value Chain" between the supplier and end-consumer. This tackles and avoids any disruption of supplies or merchandise overstock at certain stages of manufacturing. Kanban requires a continuous surveilance, reducing any potential obstacles that causes slowness during production.
The method itself was finally brought to the table of Software Development in 2004, making it a "process to gradually improve whatever you do" (Digité, 2021). Development teams have adopted a way for Kanban to implement the principles of Agile. This has been done by providing teams a set of principles to aid in visualizing work, delivering products and gaining constant customer feedback to an effective degree. The flexibility of Kanban allows any alternate process or methodology a boost that will gradually improve the flow and productivity of a project. The term Kanban also refers to a "Signal Card" representing as a pull system for work items.
Kanban has a multitide of boards to demonstrate how the process functions. One famous board structure being the "Heijunka Board" This type of board represents the pull systems of Kanban, using cards to show the capacity and workflow across a value stream. Using Heijunka boards adopts another methodology known as "Lean". Below is an illustration of a Heijunka Board.
________________________________________________________________________
Figure 4: Heijunka Board (Clinton Keith, 2008)
The layout of a Heijunka Board is basically a Scrum Task board, in a simplified way showing a 3-4 stage value stream. This is expanded to use Kanban by adding further steps to represent a 6 stage value stream, communciating the workflow in a clearer manner. Once some principles of Lean are added, it will be much easier to comprehend cycle time, meaning the amount of time it will take to complete a certain card on the board. This introduces the splitting of levels into smaller sections called "zones", making them easier to monitor as they progress through each stage. Following this card setup achieves transparency and therefore, creating a Kanban system.
Looking back at the structure of Kanban, I did use a similar structure during my studies when I used HacknPlan, a project management tool used for game development. Below is my illustration of the Kanban method I made using HacknPlan.
________________________________________________________________________
Figure 5: Kanban Method in HacknPlan (Kyle Cornwell, 2021)
From this example, you can see a clearly transparent structure following the Kanban methodology. These cards/tasks can be catagorised by urgency and importance depending on their purpose. I can reflect on the current progress that is taking place during week 1, being this current blog to finish up, as well as my choice of study pod group. Once these tasks are done, I can with ease drag them to completed and close week 1 and move into week 2: Creativity. This way, I can record and monitor my progress without any hastle and untidiness whilst attending to my other commitments, keeping a consistent workflow. I aim to keep using Hacknplan, as well as Kanbans process throughout this module and potentially others, depending on the type of projects I am involved in.
________________________________________________________________________
Incremental
The mother of all Methodologies. Incremental method is a combination of Agile practises and the Waterfall model. Incorporating the best of both applies when dealing with a product that has both hardware and software. it enables a project to have a shortened design, analysis and planning phase, letting you define the project structure for specific deadline deliveries. It also enhances the collaboration between the two types of teams. It must be taken into accout that teams have been trained in the use of a hybrid methodology, to have an understanding of its simplicity and advantages in developing this way.
Both methodologies must compromise and work together to ensure a smooth relationship. For example, Waterfall must drop set expecations to enable further flexibility on the Agile side. Agile's share is to take creativity to a restricted level, working towards a precise deadline, alongside cost forecasting and a detailed use of risk assessment. The main aim for the Hybrid is to hold on to the tracking depency and clarity of Waterfall, whilst embracing the strenghts of Agile and provide tough flexibility and transparancy, that are demanded to the adaptation of rapidly changing criteria. Below is an illustration of the Incremental Method.
Figure 6: Incremental Method Model (Synoptek, 2016)
________________________________________________________________________
References:
Agile Alliance, 2021. 12 Principles Behind the Agile Manifesto. [Online] Available at: https://www.agilealliance.org/agile101/12-principles-behind-the-agile-manifesto/ [Last Accessed 23/03/2021]
Eva Johnson, 2013. Agile-Waterfall Hybrid: Smart Approach or Terrible Solution? [Online] Available at: https://content.intland.com/blog/agile/agile-waterfall-hybrid-smart-approach-or-terrible-solution [Last Accessed 23/06/2021]
Tutorials Point, 2021. SDLC - Waterfall Model. [Online] Available at: https://www.tutorialspoint.com/sdlc/sdlc_waterfall_model.htm [Last Accessed 23/06/2021]
Mind Tools, 2018. SMART Goals: How to Make Your Goals Achievable. [Online] Available at: https://www.mindtools.com/pages/article/smart-goals.htm [Last Accessed 23/06/2021]
Software Testing, 2021. Software Testing Methodologies For Robust Software Delivery. [Online] Available at: https://www.softwaretestinghelp.com/software-development-testing-methodologies/ [Last Accessed 23/06/2021]
Sarah Lewis, 2019. Waterfall Model. [Online] Available at: https://searchsoftwarequality.techtarget.com/definition/waterfall-model [Last Accessed 23/06/2021]
Gunther Verheyen, 2014. Scrum is not an acronym. [Online] Available at: https://guntherverheyen.com/2014/01/09/scrum-is-not-an-acronym/ [Last Accessed 23/06/2021]
Hiren Doshi, 2016. The Three Pillars of Empiricism (Scrum). [Online] Available at: https://www.scrum.org/resources/blog/three-pillars-empiricism-scrum [Last Accessed 23/06/2021]
Atlassian, 2021. What is Scrum? [Online] Available at: https://www.atlassian.com/agile/scrum [Last Accessed 23/06/2021]
LazyTankStudios, 2019. Tales of Orelia. [Online] Available at: https://lazytankstudios.itch.io/tales-of-orelia [Last Accessed 23/06/2021]
Mind Tools, 2017. Porter's Value Chain. [Online] Available at: https://www.mindtools.com/pages/article/newSTR_66.htm [Last Accessed 23/06/2021]
Digité, 2021. What is Kanban? [Online] Available at: https://www.digite.com/kanban/what-is-kanban/ [Last Accessed 23/06/2021]
Kanbanize, 2021. What Is Lean Management? Definition & Benefits. [Online] Available at: https://kanbanize.com/lean-management/what-is-lean-management [Last Accessed 23/06/2021]
Clinton Keith, 2008. Beyond Scrum: Lean and Kanban for Game Developers. [Online] Available at: https://www.gamasutra.com/view/feature/3847/beyond_scrum_lean_and_kanban_for_.php?print=1 [Last Accessed 23/06/2021]
Chris Estevez, 2015. HacknPlan. [Online] Available At: https://hacknplan.com/ [Last Accessed 23/06/2021]
Synoptek, 2016. The Agile-Waterfall Hybrid Software Development Methodology. [Online] Available at: https://synoptek.com/insights/it-blogs/agile-waterfall-hybrid-wine-cheese-software-development/ [Last Accessed 23/06/2021]
Comments