Scrum, SAFe and Co., with their sprints, backlogs and masters, are now well known to us. It’s time to explore some of the latest developments.
A typical setup
Let’s start with a look back at history.
The initial ideas leading to agile software development came from Extreme Programming (XP), Scrum and some others that were mostly forgotten since. Ideas from Lean were added as well.
A second cluster of ideas emerged from the need to organise multiple teams, including LeSS, SAFE, Nexus, and Scrum@Scale, as well as Flight Levels, which has a different focus.
There were also movements like DevOps and GROWS Method that focused more on the developers than mainly managing work.
Scrum quickly became the de facto standard, leading to many teams’ setup to look very similar:
With this typical setup, typical problems come along.
Stable teams lead to two problems. The first is that when work outgrows a single team, scaling is needed. In my opinion, scaling remains a largely unsolved problem, resulting in numerous inefficiencies. The second problem is that a team is often too small to have all the necessary skills.
A backlog leads to up-front work – items are defined a long time before they are worked on. These items then lie around, introducing wait times, and when they are picked up again, we often can’t remember them well, leading to repeated work of gathering information or remaking decisions.
Sprints provide the team with a cadence, which most teams need initially, but they can later hinder the ability to react promptly to new insights or issues. Again, leading to wait times and rework.
Product Owners can quickly become knowledge and decision-making bottlenecks if they don’t enable the team to achieve a certain level of autonomy.
Scrum Masters are not the issue, but when teams delegate all responsibility for improvements to them, the improvement rate will probably be very low.
What we actually want
When we develop software, we want to deliver value early and frequently to get feedback as fast and frequently as possible. Frequently means up to several times a day. Fast means hours, not weeks. This allows for the quick and focused development of the product needed. In addition, we want our product to be of high quality by making good decisions and applying good practices.
Let’s start with some ideas to get us there.
Team
Dynamic Reteaming
With dynamic reteaming, we aim to assemble the best possible team for every task. What a task is is widely different from company to company. Some companies reteam daily, while others do so when a new, bigger task is started.
The goal is to assemble a team with all the necessary skills and capacity that is not slowed by external dependencies. Reteaming is obviously limited by the pool of employees of the company and by other currently running teams. But it can lead to better, more autonomous teams that can deliver faster.
(Almost) no hand-offs
A major efficiency killer is hand-offs – when work is passed from one person to another. Hand-offs often result in wait times due to the unavailability of the other person and knowledge loss because we can’t communicate everything we know.
We solve this problem by having one person take care of the task from start to end. Of course, other team members support the “caretaker”. This way, the caretaker ensures that the task is continuously worked on (reducing wait times) and knowledge is retained.
Makers Manager Schedule
Developers need long blocks of uninterrupted work to be effective and efficient. Every meeting – or other disturbance of concentration – leads to needed recovery time. Managers who mainly work through a sequence of meetings need to respect that. So the idea is to cluster the meetings and leave as much time uninterrupted.
In our case, we have our planning meeting on Monday morning and a developer “let’s look back at the week and do something together” workshop on Friday morning. This gives us a lot of uninterrupted space. And the best thing is that if you need an ad-hoc meeting, everybody is free to join because there are so few meetings in our calendars.
This also helps greatly with Dynamic Collaboration.
Dynamic Collaboration
We choose our collaboration mode based on our current task. If I need some undisturbed thinking, I work solo. Or maybe the task is easy, and I don’t want to waste anybody else’s time.
When I need a sparring partner to challenge my ideas, to review some code or for classic pair programming, then we work as a pair. We often pair a developer with a domain expert as well.
When we need the whole knowledge or skills of all the team members, we work together as a team on the task. This is also the fastest way to inform everybody if needed.
And because most of our week is without meetings, we can dynamically switch ad-hoc between these modes.
Team owns Impediments
Our team owns its impediments and does not delegate them to a Scrum Master or agile Coach. In my experience, teams that drive their improvements themselves find more possibilities for improvement and implement them more quickly than teams that delegate these to a Scrum Master. That doesn’t mean a Scrum Master is useless. A Scrum Master should be the trigger for many improvements and assist, but the team should ultimately own the improvements.
Work organisation
Work organisation is about how we organise the things we want to do.
We strive for collective product ownership. Similar to collective code ownership, where every developer can modify any code, collective product ownership allows every team member to make product decisions. Of course, not everybody makes any kind of decision, but the goal is to enable all team members to decide as much as possible on their own. In order for this to work, the team members need a lot of domain knowledge and a good self-assessment of their skills. As a result, the Product Owner knowledge and decision bottleneck is eliminated, allowing for quicker, better, and more diverse decision-making.
We organise our work as a sequence of “smallest possible values”. Every smallest possible value provides value to at least a single user or customer and cannot be split into things smaller that still offer value. Working with “smallest possible values” allows for fast delivery, feedback, and adaptation.
A user story is typically much bigger and involves several smallest possible values to build a coherent whole.
When working with “smallest possible values”, adapting constantly to the feedback gathered, a backlog containing a lot of future work makes little sense. We aim to minimise up-front work and instead focus on feedback and adaptation. This also prevents start-stop-restart caused by adding items to the backlog (start) that lie there a long time (stop) and need to be restarted once we reach that position in the backlog (restart). Instead of a big backlog, we have a heap of unsorted wishes that we may come back to in the future – dump it there without thinking too much about it – and a short list of “smallest possible values” that we want to implement as soon as possible.
Workflow – or how we tackle our todos
Instant Adaptation
When we have a new insight or a new issue hits us, we want to react instantly. We don’t want to wait for a Daily Scrum or even worse, the next Sprint. Both would introduce wait times. You can do that inside Scrum, but it doesn’t feel good, especially once feedback is your main driver.
Choose approach per Task
We also choose how we want to tackle a task based on the task. Quick wins are handled differently from tasks spanning maybe even several months (e.g. architectural refactorings). Simple tasks are also handled differently from more complicated, potentially riskier ones. Most teams I’ve seen aren’t very deliberate about how they tackle different kinds of tasks.
Model in Code
We don’t believe in putting much energy into intermediate artefacts. That’s why we prefer to collaborate directly on code, not specifications. Here is an example from our expenses sub-system:
I sat down with a domain expert and modelled how we want to represent expenses and what we should be able to do with them. The result was compilable code, not only a specification that would still need translation into code. This is also great for future extensions or changes.
To be fair, one needs a programming language that allows modelling in a simple way. One reason why we chose F#.
Modelling in code is a good transition into some more technical topics
Technical Stuff
Evolutionary Architecture
Evolutionary architecture is about the potential paths the architecture of a software system could take towards a desired, probably vague goal. The different paths show the options we currently have – different concepts, different technologies. For every architectural decision, we can evaluate how it would affect the still possible paths.
Residuality Theory
Designing an architecture, simulating random stressors, and improving upon your insights is the essence of residuality theory. It leads to more resilient architecture even for stressors not initially simulated.
Fractal-Vertical Slices-Hybrid
Your organisation is only as agile as the software that is running your business. Most teams I’ve seen use a way too simplistic approach to organising their codebase for simple understanding and easy changes. We use a hybrid of fractal architecture that is focused on minimising cognitive load and vertical slices for easy changeability. More info: Onion, Hexagonal, Clean or Fractal Architecture? All of them, and more!! – planetgeek.ch
Deploying vs. Releasing
Distinguishing between deploying and releasing simplifies the interaction point between development and the users of the system. Deployment (putting a new version on some servers) can be optimised for developers. Relasing (giving users access to new features) can be optimised for users and for feedback by, for example, release only to some few beta users first.
Functional Programming
It took us a long time to recognise it, but 5 years ago we switched to a programming language that supports functional programming properly. Our experience since is that our code is much easier to maintain, and we can model our business domain much more simply. Both support our agility greatly.
The CareTaker Model
In 2023 I was asked how we work, and I summarise it in this blog post: The caretaker model – our way of working – planetgeek.ch
It shows some of the above ideas in more detail.
Conclusion
This article is not meant to tell you how you should work. I hope that it gives you some ideas about what you could experiment with in your team. So, keep experimenting!
To conclude, an overview of the ideas in this article:
So long, and thanks for the fish your attention.
