Yipikiyay Blog
In essence we use a modified Agile Scrum as our main project delivery methodology. This means we map our discovery, design and development phases to time-bound and scope-bound slots called Sprints. At the end of which we deliver a design iteration and / or working portion of the software. These sprints are mapped onto a master production schedule, with key delivery dates aligned to show dependencies on other production tasks. We make use of a number of different tools to facilitate this from simple sticky notes through to software such as Trello.
For simplicity the above diagram shows each as a separate stage, however we aim to have cross-discipline teams working on sprints at the same same to promote collaboration. So for example during a design sprint we will have a developer creating an early prototype of some features, such as UI or transitions.
Our Discovery phase is intended to explore and establish all the variables as best we can for the project before we start. This begins with a Scope exercise, where we take large chunks of design or functionality called Epics, and capture those. These are captured in a common way where we focus on the user and the outcome we want to achieve. So for example, as an end user I want to login, which allows us to broadly understand that we want users to somehow log in to the system. At the appropriate time, which may be during the Discovery phase or later on, we break the Epics down into Stories which are aspects of functionality at a more detailed level. So in the login example, as an end user I want to be able to login using my existing Google email credentials, which give us enough detail to know that we need to integrate with the Google authentication system and in turn enough for a developer to hopefully estimate the amount of time needed to complete the task.
During this process we often identify risks that could cause issues to the project which we capture on a risk assessment and spend time assessing the impacts and likelihood of that risk manifesting and what steps we would need to take to mitigate it. Any development tasks that are risks, normally ones that we don't fully understand or have a solution immediately in mind, are called out as Spikes. Spikes are focussed on in a single sprint with the intention of explicitly mitigating the risks and arriving at a solution.
Before a sprint starts all epics and stories are added to a single list, from which we take prioritised stories and add them to the "to do" list known as the backlog. The prioritisation is done in collaboration between us and the client so everyone has full visibility on what is being proposed. Each story is estimated before being added to the backlog, meaning we know how many stories are likely to be completed during a sprint. Once the content of the sprints has been agreed the sprint can commence, with the overall goal being to fully complete all stories during that sprint, resulting in a fully functional set of features or completed visual design. At any point the contents of the sprint can be changed, in a collaborative decision with the client, however the overall amount of items in the sprint does not change in order to retain its integrity and the possibility of completion. As the sprints progress, the to do list becomes less and the complete functionality or design becomes more gradually moving the overall project to completion. This approach means there is always something being delivered at the end of the sprint, with the subsequent sprints building upon that.
During the sprint there are various activities that happen on a regular basis - the fundamentals of which are about making a collaborative and open team that thrives on communication. Every day the team meets in a stand-up where they discuss the output from yesterday, today's tasks and any blockers to progress. Those blockers are taken away with the intention of removing them to allow that task to proceed. At the end of the sprint, once all the development, design and / or testing is complete, the team gathers once more to review how the whole sprint went in what we know as a Retrospective. The intention is to assess and analyse how the sprint went, what was good, bad and ugly about it and how we could do better next time. By doing these things on every sprint we gradually get faster.
Having identified the scope of the project and any associated risks, we can star the Design and experience portion of the process, which focusses on the user flow, layout and broad visual appearance of the application. Our approach is focussed on user centered design, which puts the users' experience at the heart of all design decisions, ultimately ensuring the application is easy and effective to use.
We follow conventions from the GitFlow process for development. This ties in well to our Agile workflow approach as we can develop with a smaller scoped user story as the focus, release builds and test often, without causing friction as multiple developers work and merge in different areas of code concurrently. As a core part of this workflow, we approach writing new code using Test Driven Development (TDD) methodology. TDD is a process that means code functionality has unit tests written for it even before the full implementation is completed. Those tests remain part of the project throughout the development process and therefore any subsequent code changes can be verified not to have introduced issues, by the computer confirming all unit tests still pass. This drastically reduces the number of issues a human QA team need to catch and increases deliverable stability. We also use Jenkins as a Continuous Integration (CI) server to automate the jobs of running tests, compiling and deploying builds. This means we always have the latest builds available for QA to see at no extra effort/time costs to the rest of the team. We always produce stable, functional builds for review the end of each sprint. However due to these structures and automation in place in our workflow, it can often lead to inter-sprint builds being available. Which in turn allows us to test and catch problems sooner and ultimately economise the teams time transitioning from one sprint to another.
There's much written on Agile and Scrum above other software development processes, which this blog could never contain or attempt to emulate. But we know this process works and works well, to such an extent that we make quicker and higher quality deliveries. Clients get to see something quicker because each sprint delivers something concrete and each subsequent sprint builds upon that there is a constant delivery. This is hugely beneficial because clients can see what they are going to get quicker and in turn test that with their customers reducing the barriers to change and meaning tweaks and changes can be made much quicker and more effectively.
Until next time. Yipikiyay!
by Rob Mason.
Unlike most studios, we're proud to also play games frequently, so you can not only find us on mainstream social media , but also streaming on gamer specific channels.
Yipikiyay Ltd is an interactive studio of creative geeks, making Interactives, Apps, Games, VR & AR in Cheltenham & Gloucester, Gloucestershire.
Registered in England and Wales (11720195) at 28 Croft Gardens, Charlton Kings, Cheltenham, GL53 8LG. Contents ©Yipikiyay Ltd or their respective owners.