What is Agile?
Let’s get something straight – Agile is not Scrum, it’s also not a methodology, and it doesn’t consist of a bunch of people working without a scope or a budget.
The term “Agile” has many definitions, but the first frameworks and methodologies that support it appeared before Agile was a thing. The frameworks and methodologies first appeared as a response to a strict, document-driven, heavily processes-oriented approach (do you remember the waterfall approach from our last post?). Well, the Agile methods & frameworks were born because of that. They presented themselves as flexible and lightweight, putting people before processes and welcoming change [1].
Agile practitioners emphasise that more than a set of procedures or techniques is needed to achieve effective team performance. Still, a particular way of thinking from the individual and the entire team is also required. The so-called – “Agile mindset” [2].
The roots of Agile lay in the software industry, but nowadays, it is used in many more projects and initiatives. Its explicit focus on business value is a key characteristic of any agile approach [3].
That clarified several methods, methodologies, and frameworks that define themselves as Agile, and one of the most popular ones is Scrum.
Scrum
Framework that organises cross-functional people into teams. Each team has the necessary capabilities to deliver a piece of functionality from idea to delivery within a specific period of time – a sprint.
The Sprint – The sprints in Scrum can last from one week to a month and are organised one after the other to ensure a consistent project cadence. They allow stakeholders to evaluate the products at the end of each Sprint. That way, the product can be inspected in early stages of development.
Roles:
- Scrum Master – Helps the team to perform to its highest level. They are the ones who protect the team from any internal or external distractions and the ones who remove any impediment (blocker) that the team might encounter. They are also responsible for ensuring that the Scrum team and Product owner stay within the Scrum framework.
- Some of the activities a Scrum master performs are, for example, ensuring the team understands every story within a sprint or helping the Product Owner to find techniques for effective product backlog management.
- Product Owner– It’s the holder of the Product value. He or she will define what is the product and translate them into stories and acceptance criteria that the team can understand. The Product Owner knows the client and the market, and it’s the owner of the product backlog; the product owner needs to ensure stakeholder feedback is incorporated. The product owner has the power to stop a sprint and is responsible for a product’s return on investment (ROI).
- Scrum Team (Development Team) – This is a cross-functional, small and self-organising team that defines “how” to accomplish the work set by the Product Owner. The members of the scrum team have the necessary skills to complete the work, and no-one (not even the Scrum Master) should tell the development team how to turn the product backlog into increments. An ideal size for the scrum team is between 3 to 9 persons (not including the Scrum Master or Product owner). There are no titles, rankings or sub-teams on the development team, and the team is accountable for the work being performed.
Artefacts:
- Product Backlog – This is an ordered (prioritised) list of everything that needs to be done in a product. It is an always-evolving list.
- Sprint Backlog – It’s everything that the team commits to doing within a sprint. Once it is decided, no one but the same development team can add to the sprint backlog.
Events:
Scrum defines four events (sometimes called ceremonies) that occur inside each Sprint: Sprint Planning, Daily Scrum, Sprint Review, and Sprint Retrospective.
- Sprint Planning – During the Sprint planning, the Product owner describes the objective of the Sprint and answers questions from the development team about execution and acceptance criteria. The Scrum team will discuss the high-priority work for the Sprint and will define the Sprint goal. The scrum master will facilitate the meeting, and only the development team has the final say in how much of the high-priority work can be accomplished within a sprint.
- Daily Scrum -It’s a 15-minute (or less) daily meeting where the team discusses its progress on the sprint goal. Common questions during the daily Scrum are: what did you do yesterday? What do you plan to do today? Are there any blockers? Are we still on track to meet the sprint goal?
- Sprint Review – During this meeting, the Scrum Team invites stakeholders to discuss what was completed during the Sprint and usually includes a demo. The main purpose of the Sprint review is to inspect and adapt the capability provided by the discussion. The backlog can be adapted based on this feedback.
- Sprint Retrospective – Sprint Retrospectives focus on the process. During a sprint retrospective, the Scrum Team will discuss what went right during a sprint (should continue doing) and any areas of improvement. Outcomes of this meeting include tangible plans to improve their own processes, tools and relationships.
The Sprint reviews meetings focus on the product, and the sprint retrospectives focus on the process.
When do I use Scrum?
I particularly like to use it when the goal is to develop a new product, and the stakeholders still need to define all the particularities (scope) of the product. By delivering small parts of the product (increments), the client (or stakeholders) will be able to define if the team is going in the right direction. Likewise, I like to use Scrum when the team has never developed a product like that before and there is no a previous experience with the challenges we might face along the way. Again, by defining small parts of the product, the risk of the team not understanding the requirements or finishing the goals of Sprint may be reduced.
When I don’t use Scrum?
There is not a size-fits-all approach, and even if Scrum is great, I don’t use Scrum in projects where there is a clear scope for all stakeholders (it is not too complex & not much to discover) and the team has a vast experience developing them (is not novel). For instance, if there is a new project within an agency to implement a simple website for the governmental agency, where there is not need to discover many requirements and the team has implemented several websites before, using Scrum might be a waste of resources.
References:
- https://agilemanifesto.org
- Miler, J.; Gaida, P. (2019). Proceedings of the Federated Conference on DOI: 10.15439/2019F198 Computer Science and Information Systems pp. 841–849 ISSN 2300-5963 ACSIS, Vol. 18
- Racheva, Zornitza & Daneva, Maya & Sikkel, Klaas. (2009). Value Creation by Agile Projects: Methodology or Mystery?. Geophysical and Astrophysical Fluid Dynamics – GEOPHYS ASTROPHYS FLUID DYNAM. 32. 141-155. 10.1007/978-3-642-02152-7_12.
- https://www.scrumalliance.org/about-scrum/overview
