In the year 2018, it seems as though every organisation has “gone Agile,” which for the most part involves them simply sticking cards up on the wall and having a daily stand-up, then doing everything else exactly the same.
But what exactly is this Agile thing everyone keeps talking about? What’s the point of it? And isn’t Scrum that thing they do in rugby where they huddle around the ball and then kick it out of the pack?
Agile is a set of methods and practices based on the values and principles expressed in the Agile Manifesto. It empowers individuals or teams to take complex problems or challenges, break them down into smaller tasks and then delegate them to individuals in a team for completion — it is heavily predicated on collaboration, self-organisation and cross-functionality of teams.
The Difference Between Agile and Scrum
The term “Agile” refers to an overarching set of methodologies and practices, while Scrum is a specific framework under the umbrella of Agile – think of Agile as a particular workout plan and Scrum as a specific set of exercises you can do to implement this plan.
At Transpire, our experienced Scrum Masters and Project Managers are well versed in Agile methodologies – in fact, it’s our preferred approach on development projects.
This article will give you an insight into how we do things at Transpire…
When we set out to build an amazing product, there are key players that make up every Scrum Team:
The Scrum Master
The Scrum Master helps facilitate the Team to perform at their highest level. They protect the Team from internal and external distractions and also alleviate any blockers that are preventing them from delivering.
The Product Owner
The Product Owner is expected to do the best possible job of satisfying all stakeholders, maintaining the Backlog (see below), and ensuring that everyone knows the priorities and understands the vision and direction of the product. This person has the authority to say what goes into the final product.
The Development Team
Development Teams are self-organising and able to manage their own work. Generally, we’ll utilise cross-functional teams (iOS, Android, Web, QA, etc) that work collaboratively to deliver the product.
Once we’ve formed a Team for a project, the next crucial piece is to begin fleshing out the Backlog – arguably the most critical source of any Agile Team’s direction and daily activities.
The Backlog is, in essence, a list of broken down tasks and requirements that the final product needs the Team to complete. Most importantly, it must be prioritised – the most important items are shown at the top so that the Team knows what to deliver first.
That’s where the Product Owner comes into play – they are responsible for keeping the Backlog (and thus, the direction and vision of the Product) prioritised and up to date. If a new requirement comes into play, the Product Owner determines where it fits in to the Backlog. If the stakeholders have decided a particular feature is no longer required, the Product Owner must communicate that to the Team and re-prioritise it accordingly.
Think of it this way: if you were using Scrum to build a house, an item like “build a roof” would be near the top of my prioritised Backlog, because the house wouldn’t be complete without it. Whereas an item like “paint the door red” would be much lower – it may be important, but it’s not a requirement for the house to work.
Our Scrum Teams make use of various rituals throughout each Sprint – for the uninitiated, a Sprint is an increment of time (usually ranging from 2–4 weeks) during which a useable and potentially releasable product iteration is created. Whilst these rituals sound reminiscent of a cult of some sort, rest assured that they’re quite normal in Agile Development!
Daily Standup (or Daily Scrum)
The Team (with the Product Owner and Scrum Master) meet at the start of every day for a progress update – this is referred to as a “Standup”.
Each member of the team provides a brief update on what they worked on yesterday, what they’re working on today, and if there is anything blocking them from progressing forward.
Standups should generally only take about 15 minutes – any conversations that are straying off topic can be taken offline and discussed external to the Standup.
These Standups provide great transparency and are conducive to the collaboration of the team.
Ahead of an upcoming Sprint, the Team gets together and determines what items from the top of the Backlog can be pulled in and worked on.
Given the Team estimates effort for all items in the Backlog, their understanding of the work required should be solid. There isn’t an exact science to software estimation, however it does help form a starting point for time and resource requirements on a project.
Once a Project is underway, the team is able to form a baseline around complexity. This makes it easier for the team to unpack items in the Backlog to a more granular level, and provide estimates with far greater confidence. Complexity could increase or decrease based on discussions as the team delves deeper into each item.
It is then the Product Owner’s decision as to how to tackle the item in relation to the remaining priorities in the Backlog to ensure that we are constantly aligned with the overall vision of the product. Priority can be influenced by the estimation, as well as the perceived ‘value’ it adds to the business and end-user.
The Team pulls work from the product Backlog as there is capacity for it on a Sprint-by-Sprint basis.
Sprint Review (or Showcase)
Once a Sprint is complete, the Team will showcase any developed work to the Product Owner and the Stakeholders. This provides key decision makers with something tangible to indicate progress while also serving as a general wider-team status update, thus allowing for more frequent touch-points with clients and for us to instil confidence that we are delivering to expectations.
Typically during a Sprint Review, the Team will demonstrate the Product against the Stories that were pulled into the Sprint from the Backlog. The Product Owner can then confirm that the Acceptance Criteria has been met and thus “accept” or sign off on that particular Story. Again, transparency and visibility is key here.
Generally following a Sprint Review, the Team will hold a Retrospective – here, they openly discuss what went right, what went wrong, and how to improve moving forward.
This affords the Team the opportunity for continuous improvement and as a result, efficiency and throughput are generally increased.
Scrum preaches flexibility, transparency and efficiency – not only that, but the constant iterative approach taken towards a product and the inward-facing continuous improvement to the Team makes it particularly powerful.
Beyond the importance of iterations and improvements for the product, Scrum also focuses on improving the process with each new cycle.
During the Retrospective meeting, team members openly discuss areas where efficiency could be improved. Perhaps it’s a technical limitation causing issues. Or maybe one particular team member is overloaded with tasks. The Team diagnoses and decides how to fix these problems – in theory, the Team should be more efficient and produce more work with each new Sprint.
There is also room for improvement on a wider scale. As the Team works through longer timeframes, they’re able to get a better understanding of what is and isn’t working for them at an operational level.
Greater Team Efficiency
Looking at the entire product development process can be overwhelming. For a Waterfall Project (where each phase of a product’s life cycle takes place in sequence, so that progress flows steadily), the Team has to think ten steps ahead, thus making it hard to focus on the task at hand. The entire development process can suffer and cause reduced efficiency and focus, resulting in longer timelines.
By breaking the project into shorter, more manageable Sprints, and bigger pieces of functionality into smaller tasks, Scrum allows team members to give their entire attention and focus to the task at hand. This allows team members to their dedicate their entire focus to the tasks in the current Sprint, which will help things get done faster and more efficiently.
Feedback is Welcomed
By incrementally iterating both the product and our time, we allow for more frequent feedback. Scrum rituals promote transparency, communication and collaboration.
Scrum is built on iterative increments of a product. Rather than waiting until the project is 100% complete to deliver it to your users, you are able to deliver smaller, useable chunks of the project over time. This helps avoid wasted or duplicated efforts when requirements change.
By collecting feedback from users early on, you can help guide the development of the product to ensure you are meeting your users’ needs.
In order to better the world through digital experiences that matter, Transpire utilises Scrum in all of our projects, as it’s designed to optimise team efficiency and productivity, overall product quality, responsiveness to our valuable customers, and important transparency for key stakeholders.
Contact us to start a project where your business can also reap these far-reaching rewards.