Tag: framework

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…