Keeping It Simple
You’ve probably heard of the KISS acronym. It’s commonly used to describe the desire to avoid making things too complicated, especially valuable when it comes to software.
It stands for ‘Keep it simple, stupid’, memorable but easy to land the wrong way! Recently a tech lead I was working with said, let’s keep it stupidly simple, and I’m running with that version!
There are many tools and techniques to choose from in software delivery, but I’ve written before about how I’m not convinced agile frameworks are always helpful. (The frameworks, not the values and the principles!)
Frameworks are generic enough to work in many contexts, but not explicitly designed for yours. If you start with a framework, you are starting with a solution to a problem someone else once had, and it’s necessary to evolve from that starting place to arrive at a solution tailored to the challenges you face.
I believe that not only is it possible to arrive at good delivery practice without a framework, but at times, that's the most expedient way to find the simplest thing that could work for you.
As Simple as Possible
“ Everything should be made as simple as possible, but no simpler" – Albert Einstein
This is a paraphrase about scientific theory; there is a point at which simplicity cannot be increased without losing something necessary.
There are many more ways to make a rocket accidentally explode than successfully launch it into space. Success comes from reducing the chances of all that can go wrong actually happening.
Historically in software, the desire to reduce the chances of things going wrong ended in a heavyweight process. The result was counterintuitive, an illusion of risk reduction that increased risk.
We need ‘just enough’ processes and practices with enough meat on the bones to effectively reduce risk without adding unnecessary overhead. I.e., finding the point at which simplicity cannot be increased.
Starting with a framework can be an excellent way to achieve that; you get the bare bones and then add what you need for your context.
Frameworks are at their best when they facilitate learning about the most effective ways to work in your context, with a team buying into working with that framework.
Frameworks are at their worst when imposed, creating a standard everyone must follow regardless, defeating the object of using them to learn and adapt to context.
Starting from Scratch
The most recent team I worked with has a nicely honed, well-understood, and effective process. If you were to observe this team today, you would recognise practices from Kanban and XP and heavy use of Mob Programming.
You will see design sessions around a whiteboard, just-in-time gathering of user needs, releases on demand, multiple cadences and fast feedback loops, and a highly engaged, self-organising team who fully own their working methods.
This team deliberately decided not to use an agile framework. They started with barely any conversations about ways of working, except for the agreement to stop and discuss as soon as the need arose, identifying options and trying out the simplest thing that could work, not just selecting the cookie-cutter approach.
This approach created a path toward the most straightforward possible approach that could work for that team, solving only the problems the team actually encountered.
The Context
There are a few reasons such an approach worked for this team.
The balance of experience.
Some team members had been practising agile delivery since before it was called agile delivery. They had seen many ways of working problems and perhaps just as many ways to solve them. They quickly aligned around some basic principles, working in small batches, not having too much in progress at once, releasing frequently, and getting feedback as quickly as possible.
It was a new team
They did not have any incumbent challenges to which a framework would offer a solution. There was no chaos to tame, and given the alignment around ways of working principles, it was possible to accept the risk of creating that chaos by not having started with a framework.
It was a greenfield project
There was a clear vision and a need to start, but the team was not managing the BAU workload often associated with running a live product or service. This context could change once the software is in use, but for various constraints outside the team’s control, that would be a while away.
The baggage of past imposition
Like many teams I encounter, they had plenty they didn’t like about agile frameworks, which typically come from having been forced to use them in the past. Often, practices are enforced that are not part of a framework but are so frequently used with it that people don’t know the difference, and the framework is guilty by association. Whatever the rights or wrongs of that, the reluctance to use them was real.
How to Lead without a framework
You may feel like a fish out of water as a delivery leader, but here are some approaches that helped me.
Mentor
Instead of teaching a team to use a framework, you need to have experience with different ways to solve a particular problem and mentor the team by giving them the benefit of your experiences, offering options to choose from.
Coach
You will need to coach, to deepen team insight into their challenges, and enable them to find and hold themselves to their ways forward.
Feedback
You will need to observe, and use your experience, to deliver feedback to the team in a way that allows them to consider it and take agency over their actions in response. This will prevent them from getting blindsided by a gap they had not perceived.
Prepare
You will need to set up for success; having more potential questions to answer about ways of working means a greater chance of disagreement on the team. Therefore creating a trusting and psychologically safe space is maybe even more critical than usual.
Constantly debating ways of working and not being able to move forward is an obvious possible pitfall of this approach; awareness of that pitfall added to a general desire to work experimentally, to try things out, to not have to reach a consensus, to agree to try something out and see what happens.
Give Control
Doing these things will increase the team’s ownership and engagement in their ways of working and trust in you as a leader that you are facilitating and enabling them towards how they want to work.
Conclusion
I believe this team arrived at the simplest practical way to work; in other words, they kept it stupidly simple, but in doing so, they had freedom and control and felt engaged.
A third of the team were bikers! So that would be something they enjoyed, like the freedom of the open road.
While there are many reasons to choose an agile framework, there can be times like the one described above when you don’t need one. Frameworks facilitate learning and tame chaos. Do you need a framework if you don’t have either of those needs?
It’s a good thing to consider because if you find you do, at least you will know why you need a framework, and that might help you make the most of it rather than go through the motions.
Perhaps, as the principles behind effective ways of working are more commonly second nature and people become as experienced as the folks this team was blessed with, the need for agile frameworks will decrease.
As an industry, if the simple following of frameworks becomes less of a focus, our attention can move more towards outcomes, people, and leadership.
Given enough time, anyway.
Comments