It is said that Scrum is easy to understand but difficult to master. However, to me, it appears that Scrum is already difficult to understand since there are many ways to interpret, teach, apply and well… misconceptualise Scrum. I’m not even sure if I truly understand Scrum. Yet, here I am going to tell you about the disadvantages. I see in the typical interpretations of Scrum and how to overcome them.
Using Scrum creates an illusion that you’re agile
Scrum is so widespread that it’s a typical misconception to think that you need Scrum to be agile. Furthermore, people may think that simply doing Scrum makes you agile. Myself, I believe that Scrum can be a good way to start discovering agile but strictly following any rigid framework actually goes against the first value in the Manifesto for Agile Software Development: individuals and interactions over processes and tools.
That said, I don’t think the Agile Manifesto represents the contemporary agile discourse after 20 years of being published. Yet, I think most of its thoughts are still valuable. There is no single definition for agile so I’ll pitch in my definition:
Agile is a practice of delivering maximum value early and continuously by
a) enabling faster and cheaper learning cycles,
b) increasing autonomy and
c) cultivating collaboration within the team and with the stakeholders (especially users/customers).
As I said, Scrum can be a good starting point for a software product team figuring out how to organise their work. After all, Scrum offers some framework for agile – for short learning cycles, team autonomy and collaboration. Most importantly, Scrum incorporates retrospectives (team reflection) which enable the team to inspect and adapt its ways of working.
However, strictly following Scrum can become an impediment as the team matures. If you just follow Scrum, you most likely aren’t agile. Below, I’ll explain why.
If you want to have sprints that you won’t need to replan during the sprint, you have to have clear specifications for all the backlog items, the latest at the sprint planning. This can lead to design and discovery work (such as user research or data analysis) to happen outside sprints – before the backlog items are added to the sprint backlog. And that often leads to extensive up-front design and discovery work, resulting in longer lead times. This makes learning slower and can even reduce collaboration within the team – making the team less agile.
The whole point of agile is to be able to change plans when we learn something new. Sprints can give nice structure for teamwork but don’t leave some of the team capabilities (design, data analysis) outside the sprints and feel free to replan the sprint whenever there is a need for that.
Furthermore, why wait until the sprint review to collaborate with the stakeholders? An agile team should be collaborating with the stakeholders throughout the sprint. Sprint reviews can of course be a good place to bring together all the stakeholders to share thoughts with each other and with the team.
Product Owner (PO) role is often taught/interpreted so that the PO is simply some sort of a backlog dictator and a knowledge broker between the team and the stakeholders. Instead, an agile team should be autonomous and make product decisions (including backlog prioritisation) as a team in collaboration with the stakeholders. That enables a much faster learning cycle.
Similar applies to Scrum Master. I think it’s a weird thought that the Scrum Master should be removing impediments, protecting the team and facilitating the teamwork. Somebody should do that but if the team is self-organising, they should decide as a team how to do that and not just leave it to the Scrum Master.
Yet, these roles can be a good starting point and it can be useful that some people take more responsibility in product management and team facilitation. Just apply the roles in an agile way!
Be warned: If you interpret Scrum strictly, you might interpret that these suggestions would break Scrum so much that the team process can no longer be considered Scrum. Worry not! Following Scrum should not be your objective in the beginning with! You want to be agile. You want to deliver maximum value early and continuously through quick and cheap learning cycles, enabling autonomy and cultivating collaboration.
PS. Simply breaking Scrum is not the point either. Breaking Scrum without understanding agile and Scrum might cause you to end up with ScrumBut and losing even the advantages of Scrum.
You might be interested in also reading these blog posts:
In this latest series of blogs, we’ll open-up the Good Growth methodology and the associated tools and practices. The purpose of these articles is to open-source the Good Growth framework in the hope that we enable others in the adoption and scaling of sustainable thinking and doing in their own digitalisation projects.
Sustainability is fast becoming the next big business transformation. According to the 2021 IPCC report, much of the groundwork needs to be done within this decade to safeguard our future from catatrosphic global heating above 1.5 degrees. Companies need to demonstrate that carbon emissions targets are in order, Environmental, Social Governance (ESG) legislation is adhered to, and expectation from a new breed of conscious consumer is met. Company operations and brand image align and “greenwashing” becomes a thing of the past. Much of this transformation is enabled through digitalisation. From value chain transparency to systemic impact modeling, IOT smart sensing to data-driven business intelligence. There is a lot of work to do.
With that in mind, we’ll need to join forces and work together. We believe that sustainability is everyone’s responsibility, and the sharing of practical tools and methods can only be a positive thing in helping to accelerate the sustainability transition that we are all a part of. Gofore’s Good Growth methodology and toolkit is open-source. We are more than happy for you to try it, use it, redesign it, improve it. Go for it!
The Good Growth Lenses
Let’s start with the foundation that underpins the Good Growth way of thinking. This is the reference that you return to, a way to steer projects toward success and concrete measurable sustainability impact. A sense checking tool that team stakeholders can adopt as their shared way of thinking. In essence, it’s the map that helps you navigate toward your desired destination.
The traditional way of thinking when designing and developing consumer digital services is to make sure of two things that are in essence, the measure of success.
How well does your digital service:
1. Help the user achieve their goal in the most intuitive and simple way possible. In addition, engaging them enough so that they return often and even recommend to others?
2. Deliver from the strategic business perspective and generate the right kind of economic value for the service provider?
So that’s quite easy right? I’m simplifying of course, but just for the sake of clarity, that pretty much covers most commercial consumer services. On the public sector side, it’s a different picture, but it’s not that much different. The economic aspects just become a little more hidden and the social improvement aspects more prominent.
With our Good Growth lenses there are three measures of success that we consider when we design and develop digital services.
1. People – Improve the lives of individuals and the communities they belong to.
2. Nature – Reduce any potential harm to the environment, and if possible, eradicate it all together.
3. Business – Develop good business for everyone involved. Stakeholder capitalism as opposed to shareholder capitalism.
These three Good Growth lenses when applied to your project, will help you to question your goal and intentions, ensuring the outcome scores well against the GG lenses.
Practical application of the GG lenses:
Print these lenses out and stick them to the wall (or Miro board). Hold a team session to go through each lens and ask yourself:
- How well are we doing on each lens, what are the main sustainability issues?
- Where are the opportunities for improvement?
- What’s our plan of action?
Be transparent about your current state and be OK with what you cannot achieve. For example, if your digital service is harmful in some way to the environment, make sure the team is aware and try your best to design a solution. If not now, then make it a backlog improvement for the future roadmap. The most important thing is full transparency and big picture awareness of the total impact of the digital service that you are about to launch into the world.
From this GG lens mapping, figure out the most important aspects to address and prioritise based on your team knowledge and basic gut feel. If you can bring in a sustainability expert to add validation to your mapping, all the better.
Next step is to ideate “Jobs To Do”. What actions need to take place in order to address the issues? Who do you need to speak to? Who do you need to get onboard? Service ecosystems are in most cases made up of a collection of actors (real people) who contribute to the service delivery, owning and working with some part of the value chain with their own agenda and set of priorities. Working together with these stakeholders is key to solving sustainability problems. Defining shared vision and win-win scenarios for all is the only way that you will convince people outside your immediate team to play ball.
So, to summarise, getting started with Good Growth could be as easy as bringing these 3 lenses into your project and introducing them to your team. Taking the time to map issues and align them together on the big picture. Work out Jobs To Do and make the connections to people in the wider value chain. Start to work together to design out sustainability issues.
It’s of course by no means easy, but solving the biggest challenge facing humanity was never going to be a walk in the park.
In the next blog we’ll dive into the Good Growth process, one that aims to unify multiple stakeholders and scales Good Growth thinking and doing.
2021 IPCC report in full:
Link to Good Growth:
If you would like to try out Good Growth in your project – let’s talk!