As we are almost finishing our journey through the 12 principles, we hit the second last. The one agile principle that is so at heart at what I consider the main issue with modern vs “traditional” software development. The agile principle 11 puts together emergence of requirements and self-organization of teams.
“The best architectures, requirements, and designs emerge from self-organizing teams.”
If you’d rather watch a video than read, check out my Youtube video on Agile Principle #11:
It’s funny to mention the word tradition to a discipline that is not even 100 years old, but software development started under assumptions that since 21+ years ago we discovered were not true.
The agile principle 11 challenges the assumptions that:
- Specialization breeds better work.
- Someone must control and someone must execute.
- Once it’s done, it’s over, never to be touched again.
Let’s look into each.
Specialization DOES NOT breed better work necessarily
Back in the day people would show up overspecialized, work in their corners. Technology, roles, accountabilities were rather specialized for software development.
The assumption was that each on their corner, doing their best work, we later “only” need to integrate it all. Until we realized that when we put together the work of each person (specialized per function or per technology) and the final product would not make sense, have tons of bug, or take too long to be integrated, because nobody thought about interfaces the same way.
That’s when we discovered that specialization DOES NOT breed better work necessarily. In fact, I would recommend to not allow specialization without collaboration.
Consider misunderstanding of the principle on technical excellence. Specialization is a great thing when we can join forces for the final result. So if you are a database genius and I’m the best java developer you’ve ever seen, we should work together because we want our ideas for the solution to align, not to diverge.
Another facet of this is that today we know generalists can also do a fantastic job when put together to give a solution to a problem. In fact, one of the skills that everybody needs in the team, for them to be able to deliver under constant change and challenging circumstances is the ability to communicate and work together. Today’s problem rarely can be solved by one mind, however specialized. And even if they could… what happens to your teams and organization when you rely on one single person all the time?
So, what agile did was turn this assumption into its head and say if you do have specialists you bring the specialists into the team and everybody discusses the solution together. Because ultimately, they will own and support the solution together.
The problem is not specialization. It’s single accountability and isolation and silos.
Which brings us to the next point.
It’s about empowering teams, not about someone controlling vs someone executing
Agile is about empowering teams to make decisions about their work and encouraging collective accountability and ownership in the project or product.
That means we’re past this approach where:
- People hand off work to each other like a “spec deliverer” giving work to a “coder” giving work to a “tester”.
- Specific people are sole decision-makers, having an individual accountability, while asking others to execute on it and deliver “great work”.
Great work comes from autonomy and from understanding multiple sides of the problem. The best solutions emerge from great discussions, not from an architect thinking in the corner.
Think about it: if you alone are held accountable you definitely will try and control the whole outcome. Which will remove any autonomy from the team. Which will make work really frustrating from the team’s point of view. I can’t see any signs of motivated individuals in this scenario.
The sole owner will try and control things because it’s their sole head that will be a target in case things go south. It’s a natural instinct.
An anomaly I still see a lot today now that we talk a lot about value and customer centricity is to consider that new departments are created as the new thinker and there is a department of execution. People who misunderstand the double diamond approach in design thinking for example think it’s all about the new generation of analysts and UI/UX thinking alone, without the developers. They group do the discovery alone. Then later give work to the development team in what is called delivery.
That’s clearly a misunderstanding of the concept. It’s still creating silos where the “customer centric people” are thinking alone and offering solutions that only later the developers will need to figure out how to make happen.
It’s new clothes on an old approach: those who think and those who execute.
In those scenarios, managers and directors are still puzzled that they developers cannot speak client language or be customer centric. Tell me about it!
Any idea where the team is not working empowered and in unison definitely not indicative of business and technology working together and joining forces to deliver value frequently.
And we know the best solutions come from smart people invested in what they are doing.
Nobody needs an “analysis” department
I had to add this section to zero-in on the conversation about the role of an analyst. Analyst is a role from the past. Hear me out before you scream. It’s not a critic of analysts.
Most analysts I know can bang an SQL script and think about solutions.
Most developers I know can talk to clients.
Anyone can write specifications and documents, whether they like it or not.
Everybody can test, whether they like it or not.
So what you have in your hands is a team member. Everybody is an analyst and developer. You get to pick the nomenclature, but everybody contributes to the thinking and designing and executing of the product.
Having those specialized departments to provide analysts versus devs and having the analysts as the only ones who speak to the client creates a telephone game. Analysts talk to user, then analyst talks to dev. Things get lost in translation.
While you might want to adopt steps in the process that show up like analysis -> dev -> test, steps in the process do not create a specialized role in the software development world.
And did you know you can do a pairing between and “analyst” and a “dev” and have them do pair programming all the way through?
Yes, it’s totally possible. I have examples in my own happy career and if you are skeptical, you should go and learn about Joy Inc.
Architecture and design will evolve, it’s not a once-and-Done thing
The final assumption that we know is wrong is this one, that you let your specialized people sit in a corner and think because it will then be the best ever design or architecture for the solution and it will be then done.
Software is never done in today’s world. You have the current version, that’s it. Many more versions may come, especially if you are counting on the success of your product. New features and new requirements will arise and the whole architecture will evolve.
Let it emerge from the team.
They must understand their clients.
They must understand the pain and the elegance in their solution.
Here’s a hard reality to swallow that if you don’t believe it might indicate your team has serious technical skills issues or you have serious trust issues:
A software team that cannot change the architecture and design of their own product on daily basis is not able to deliver valuable software.
From refactoring to more serious changes, your product’s architecture can only be robust if it’s constantly being revisited and enhanced.
Who does that?
You got it: an autonomous, competent, self-organizing team.
Final words
It has been in my experience that the agile principle 11 is a hard one to execute when traditions about roles and departments are anchored in specialization and when there is no culture of collaboration in the organization.
How do you know if there is no collaboration? Well, handing off work to a peer is not collaborating!
Be mindful that in such places there are politics involved, because breaking down those silos might mean power shifts in the organization. Be aware it may not be a simple discussion about the benefits of agile.
Consider the assumptions we broke down in this post. Consider how you can have that conversation with the teams, as their way of working significantly changes. And consider how to talk to managers and directors, because they might be the ones who might default to the “old ways” and demand something to be executed in a way they want because of the certain power structures.
Ultimately, help everybody, managers and their teams, understand that the agile principle 11 can catapult their results. They just need to define boundaries for the team autonomy so that they can make decisions on their own when appropriate and seek help outside of the team when it’s not.
Self-organization is not a beast. But it cannot be obtained without collective agreement.
What are your thoughts on the agile principle 11 and how to put it in practice?
