Scaling Agile and Scrum

Understand Scrum is simple. If you don’t know what Scrum is and is not, there is a 17-page definition called Scrum Guide. If you like to know what is agile, go to the four values and 12 principles of the Agile Manifesto. The agile community mostly agrees on both. As scaling increases the complexity, there is no common agreement on how to scale agile and scrum. The good news is that there are many frameworks to choose from. A broad menu of options, and in agile we love options and there is no one way how to do things. So far so good. Some options are easier to apply, some harder, some less agile, some more. But remember Agile is not your goal, it’s just the way how to achieve your strategic goals. So at the end of the day, it doesn’t matter. The less agile ways are not necessarily a bad option for given circumstances. Some companies go faster, some slower on their agile journey.

To give you a few examples:

If you have a totally fixed mindset, no collaboration, hierarchical organization, even frameworks like SaFe can be useful. You might not become agile using them, but at least you start moving and changing. As any SaFe implementation didn’t create any magical success, companies keep looking and sooner or later find a better way of working and scaling.

If you have limited experience with self-organization, but like to be modern, cool, aka agile, the Spotify so-called model is a good choice for you. All that awesome terminology of tribes, squads, and guilds makes the job and at least some parts experience a certain level of agility. And step by step, as your mindset becomes more agile you can move towards a more agile way of working and implement LeSS as ING recently did.

A super-simplified tagline for each framework:

SaFe (Scaled Agile Framework) is scaling ‘fake’ Scrum with traditional mindset practices. A good start if you are stuck and need to get moving no matter in the direction, or if all you need is a stamp that you are agile without any change of mindset. It’s easy to implement, and it’s safe as most of the roles are just renamed, not really changed.

Scrum@Scale is mentally very close to SaFe, no real change will happen at the organizational level which remains very hierarchical. Scrum at the team level is rather technical (it’s all about practices), ScrumMaster somewhere between team assistant and manager. At a glance, it looks agile, but the lack of understanding of the self-organization concept will eventually kill any good intent and implementations will fail to bring any expected results.

Spotify is not really a model, but an inspirational story. Nevertheless, ING makes it so popular so every other bank is applying it. The cool terminology helps to spread the message around, and there is a chance that by applying it companies learn what is this agile really about. It’s also a good opportunity to descale your organization a bit and remove several layers of traditional management in exchange for the more flat structure of the above-mentioned tribes and squads.

LeSS (Large-Scale Scrum) is Scrum. It’s the most agile way of how to scale. Similarly to Scrum, it’s simple to understand, hard to apply as you need to have courage, be ready to collaborate, increase transparency, remove silos, and redesign the organization. Do more with less. The good news is that it works. Don’t expect it to be a one-time change. Agile is a journey, and implementing LeSS is very agile so you are going to be on your journey for a while. You can get inspired by the case-studies.

We Don’t Need Another Method

Let’s start with a bit of context. We apply Agile not because it’s a new cool method 🙂 but because it’s a good answer to the complexity of the nowadays world. We change because the traditional ways of working are failing, as they expect reasonable stability and lower complexity which allow to analyze the situation, plan what needs to be done and then do it. In the nowadays world the complexity, uncertainty, volatility, and ambiguity is so high that you can’t even do that and need to fundamentally change the way you work into the more iterative feedback-driven way, simply be more change responsive, adaptive, agile. 18 years from the Agile Manifesto is a long time. Spend a minute looking back to 2001. How the business looked like, what had you been doing? In 2001 the variety of frameworks, methods, and practices was not that diverse. Agile was at the beginning.

Today, we are in a very different space. Agile is not anymore a new way of working, it’s a major trend companies are taking. What is missing in most of the organizations is not lack of practices and frameworks but a very simple thing. Mindset. Just apply them. We don’t need another method. We have plenty already. Everything was said and yet, companies are still not agile just by changing their processes and tools. There are so many practices yet people are still looking for best practices and easy to follow checklists. I understand that it would have been so nice, just to say the magic formula and all the issues are gone. But unfortunately, there is no such thing as best practice in the complex world. All we have in a complex world are options. Some are easy to do, some harder. Some might be a good idea to do at the beginning of your journey, some are great when you are experienced already. Some are great at one context and create a disaster in another. Some are leading towards what you need to achieve, some are not. Frameworks are good as they give you enough freedom to experiment and find your own way but also some boundaries. Practices are great as they give you inspiration. And there is plenty to choose from. So just choose some to start and inspect and adapt from that. They are neither good nor bad, they are context, meaning culture and environment-specific. And if your company is not “agile enough” according to your expectations and needs, it’s not because you are missing some magical framework, method or tool. We don’t need another frameworks, method, or practice, there are plenty out there already. All we need is to start using them fully, as intended. Start being agile, stop doing agile. Experiment with different practices and stop looking for the Holy Grail method which would save us. Agile is about collaboration, early value delivery, and finding your own way through experiments and feedback, learn from failures. Simply being adaptive.

Scrum Guide Update

A few days back there was a new update to the Scrum Guide – the definition of Scrum. So what’s new? Not much, which is a good think. Most of the changes were minor, correcting, clarifying and updating the text so it’s clearer. Few interesting updates:

The trend of using Agile and Scrum out of IT was addressed explicitly:

Scrum has been used to develop software, hardware, embedded software, networks of interacting function, autonomous vehicles, schools, government, marketing, managing the operation of organizations and almost everything we use in our daily lives, as individuals and societies.”

Nothing new, for us, but it can make a difference to the people new to Scrum.

I specifically like the update in the Daily Scrum section where the three questions were only made as one option. Finally, right.

“The structure of the meeting is set by the Development Team and can be conducted in different ways if it focuses on progress toward the Sprint Goal. Some Development Teams will use questions, some will be more discussion based.”

So there is a chance people stop using it as individual status meeting and use it to inspect and adapt their plan ow they are going to achieve the Sprint Goal.

The only change I don’t understand as it is to my opinion going against the philosophy of Scrum as a framework, not a process is the Sprint Backlog section:

“To ensure continuous improvement, it (Sprint Backlog) includes at least one high priority way in which the team works, identified in the previous Retrospective meeting.”

So here we are, pushing one practice which may be good for the teams who are at the beginning of their Agile journey and don’t improve as part of their DNA to everyone. I can imagine many other ways how to improve then making it part of Sprint Backlog and soften the line between delivering value and “other important tasks which need to be done”.

I like Scrum as it is not much prescriptive and I hope such weird changes will not increase as they will eventually be the end of Scrum as a flexible framework…