The agile manifesto is now already 20 years old, and still, when we talk about agility, a lot of people don’t really know what it is. Why is that? Maybe because being agile is such a broad concept that you can’t really narrow it down to a simple explanation? Or maybe because working in an agile environment can mean different things depending on the way the company handles its agility. Let’s give you some insights into the creation of an agile mindset and into the scrum way of working.
The Agile Manifesto
The agile manifesto is 20 years old, but the philosophy behind it is way older. In 2001 the manifesto for agile software development was written down:
"We are uncovering better ways of developing
software by doing it and helping others do it.
Through this work we have come to value:
- Individuals and interactions over processes and tools
- Working software over comprehensive documentation
- Customer collaboration over contract negotiation
- Responding to change over following a plan
That is, while there is value in the items on
the right, we value the items on the left more."
A few simple sentences, yet very progressive at that time. Coming from a time where it took months, years, or sometimes even decades to develop a digital product that, most of the time, didn’t even answer the customer’s needs, this manifesto was revolutionary. Since the previous setup, called the waterfall way of working, only worked backward for both developers and the customers, it was time for a change. From now on developers will collaborate with the customer, open communication will be important and regular feedback rounds will be set up. All to make sure customers end up with the product they really need instead of the product they thought they needed.
Let's talk numbers
This new way of working and the outcome was investigated by the Standish Group, which examined the success and failure rates of the agile way of working against the waterfall way of working.
“The results for all projects show that agile projects enjoy a 60% greater chance of success than non-agile projects. Looking deeper, we find that “waterfall” projects are three times more likely to fail than agile projects.”
Although this manifesto is already 20 years old, there are still a lot of companies that don't manage to implement agility into their day-to-day work. Being agile is a mindset, Scrum is a way of working, a framework with rules and roles to make it easier to hold on to this mindset. There are other frameworks, like Kanban, Safe, Less, … but at icapps, we choose Scrum as our preferable framework.
The benefits of a Scrum framework
We already explained the agile mindset, but how do you manage to keep the agility alive in your company? Well, working in a Scrum framework helps you to keep the goal sharp and the scope clear.
The benefits of a Scrum framework:
A standard framework with worldwide adoption
Proven technology
A clear handhold for employees, junior or senior
Approved and used by customers, increases their buy-in
Short feedback loops, for the developers but also for the customer
Less likely to go over budget
No unnecessary features developed
At the end of every sprint, we create value
The basics of a Scrum way of working
To divide the project into smaller blocks, and to make it possible to receive regular feedback from the customer, the scrum way of working divides one big pile of work, the product backlog, into smaller blocks, called sprints. A sprint runs from 2 weeks to 1 month, in every sprint, the tasks are clearly defined in the sprint planning and openly communicated to the customer. In every sprint, the development team creates a piece of software, called the sprint increment which will be discussed with the customer after the sprint, during the sprint review. In this sprint review, the development team can show their work to the customer via a demo and the customer has the chance to give their feedback on the spot and to share their expectations. After every sprint, the Scrum master organizes a sprint retrospective with the team so they take their key learning into the next sprint. That way the team improves their way of working every sprint, which is both interesting for the team and the customer. This cycle keeps on repeating itself until the product is completely built.
As we said, when working on a product in the Scrum framework, it's important to start from a product backlog. This backlog contains all the big building blocks (or themes) we initially want to include in the digital product. We say initially because the backlog is emergent. If we would analyze everything upfront, we would be wasting a lot of time analyzing parts that will eventually never be built. So, it's more efficient to adjust our backlog according to the insights we gain within every sprint and every sprint review.
This however does not mean that we don't plan upfront what we want to achieve. Remember the famous quote: Plans are useless, but planning is indispensable (Eisenhower). Plan ahead, but be prepared to leave the plan if you encounter new crucial information and act/replan accordingly.
Pro tips to become agile
Start with making your work visible (what is blocked? What are you working on?), and be transparent toward each other
Kill your darlings, it’s not productive nor recommended to suggest 10+ improvements per sprint retrospective, rather focus on 1 or 2 improvements for the next sprint
Don’t panic when it doesn’t go as planned, an agile mindset doesn’t land in only one sprint; it’s a work in progress
In the next blog post, we'll discuss how to become a successful Scrum master and we'll show you the journey our colleague, Annelies went on. Want to start learning more about Scrum? In this blog post, we discuss 5 books to read about Scrum.
Need any help with the implementation of an agile mindset and scrum way of working, don’t hesitate to reach out!
