[ Agile Manifesto — Principle 11 ]
Greetings fellow Agilistas! In this article, we’re going to explore the Agile Manifesto’s 11th principle: “The best architectures, requirements, and designs emerge from self-organizing teams.”
The Magic of “Emerge”
In the 11th Agile principle, the word “emerge” holds a profound meaning.
“Emerge” signifies a departure from the traditional “plan-everything-upfront” approach. Instead, Agile embraces the idea that architecture, requirements, and designs are not fully known or specified upfront. Rather, they gradually take shape as the project unfolds.
The All-Upfront Pitfalls
The all-upfront approach might seem logical on the surface, as it aims to define every detail before any work starts. It is all too human to crave for certainty and wanting to have everything answered. And there are highly talented professionals out there who want the requirements to be perfect before committing to start.
However, this all-upfront approach has several drawbacks:
1. Limited Adaptability:
The all-upfront plan assumes you can anticipate all future changes and challenges. Or, that nothing will change the plan once it’s signed-off by high ranking managers. Spoiler alert: reality loves throwing curveballs.
2. Slower Time-to-Market:
Extensive upfront planning consumes time and resources, delaying the delivery of value to customers. In the good old waterfall days, value was delivered at the very end of the project.
3. Wasted Effort:
If requirements change, all the planning and design work done upfront may go to waste, leading to costly rework.
Emerging Architecture, Requirements, and Design
Emerging Architecture:
An emerging architecture is one that evolves over time as the development team gains a deeper understanding of the project’s requirements and challenges. Instead of defining every architectural detail upfront, Agile teams create a flexible foundation that can adapt to changing needs.
In traditional software development, you might spend months (or even years) painstakingly crafting a detailed architectural plan before writing a single line of code. It’s like building a house with an elaborate blueprint, and you hope everything fits perfectly when you finally start construction.
Does this mean we are skipping planning altogether? No. You still need a rough idea of where you’re heading, but you don’t need to map out every little detail before setting sail. Instead of locking yourself into a rigid architectural design, Agile encourages you to start small and iterate as you go along. The beauty of an emerging architecture is that it keeps you agile (pun intended). It acknowledges that, in the real world, requirements change, and unforeseen challenges pop up faster than you can say “waterfall methodology.”
Speaking of changing requirements …
Emerging Requirements:
Emerging requirements are the features, functionalities, or specifications that might not have been crystal clear at the project’s start but gradually reveal themselves as you move forward. Emerging requirements acknowledge that not all user needs and business goals can be predicted at the project’s outset. Instead, you welcome the fact that requirements can evolve. Have you ever had a “Oh, we didn’t think of that before, but it sure would be cool!” moment? There you go.
Agile teams prioritize a subset of requirements initially, adding and refining them as they receive feedback and insights from stakeholders and users.
Again, this does not mean, starting with no requirements. You kick things off with a vision, a first basic idea of what the customer wants and the corresponding initial requirements. But you don’t etch them in stone or nail down every single detail from the get-go.
And also this does not mean that requirements should change all the time and that you should not blindly follow every customer request. That’s where your product vision and product goal will serve as a guiding star.
Emerging Design:
Emerging design means that the initial design of a system or feature is a starting point, not a final product. As the team works on the project, they refine and enhance the design based on ongoing feedback, testing, and insights.
Self-organizing Teams
Self-organizing teams is a HUGE topic, and also hugely important. I try to give you a glimpse into what this means:
Agile encourages teams to be self-organizing. It means they have the autonomy to make choices regarding how they work, plan, and execute tasks. Instead of being micromanaged, team members collaborate, make decisions, and take ownership of their work.
We know from studies — and maybe also from ourselves — that we are much more committed to a task, if we have a say in how to do it.
“Control leads to compliance; autonomy leads to engagement.”
In an agile (i.e. fast evolving) world, we cannot rely on people being compliant and thus nearsighted.
In an agile world, we need effective solutions; and we believe the most effective solutions evolve naturally when teams are empowered. Rather than having solutions imposed from above, self-organizing teams are expected to craft the best architectural designs and requirements for the project through collaboration and continuous improvement.
Relation to Scrum
- Self-organizing teams decide how to tackle the Sprint Backlog. This autonomy allows them to choose the best approach and design, which often results in higher efficiency and better product outcomes.
- Scrum teams are encouraged to inspect and adapt. They regularly reflect on their processes, architectural choices, and designs, striving for continuous improvement.
Benefits Galore
Now that we’ve clarified the principle and its relation to Scrum, let’s explore how adhering to it benefits both the development team and the broader organization:
Enhanced Ownership and Accountability: When teams have a say in architectural decisions, they feel a stronger sense of ownership over the project. This leads to greater accountability for the outcome. Team members are more likely to go the extra mile when they have a direct stake in the project’s success.
Faster Adaptation to Change: Self-organizing teams are agile by nature. They adapt quickly to changing requirements, market shifts, and unexpected challenges. Instead of waiting for top-down directives, they pivot and adjust on the fly.
Unleashing Creativity: Empowering teams to make architectural and design choices encourages creativity. Team members can experiment, innovate, and propose solutions they’re passionate about, leading to more imaginative and effective outcomes.
Improved Collaboration and Communication: Self-organizing teams foster better collaboration and communication. When team members actively participate in decision-making, they naturally share information and insights, leading to a more informed and cohesive team.
Higher Job Satisfaction: Teams that self-organize often report higher job satisfaction. They experience a sense of purpose and autonomy, which contributes to a positive work environment and lower turnover rates.
Streamlined Decision-Making: Decentralized decision-making allows for quicker, more efficient choices. Teams can address issues promptly without waiting for approvals or escalations, which can save precious time in project delivery.
Better Risk Management: Self-organizing teams are more attuned to project risks. They proactively identify and mitigate issues, ensuring that potential problems are addressed before they become major roadblocks.
Boosting Innovation: Empowered teams often come up with groundbreaking ideas. By encouraging self-organization, organizations tap into the full creative potential of their teams, leading to innovation and competitive advantage.
Higher Quality Products: When teams are free to design and develop in the way they see fit, the result is often a higher-quality product. They can focus on delivering value and addressing technical debt without external interference.
Organizational advantage: Organizations that embrace the 11th Agile principle not only benefit at the team level but also at an organizational level. They can adapt to market changes and customer feedback faster, maintaining a competitive edge.
In Conclusion
The 11th Agile principle champions the concept of “emergence,” where architecture, requirements, and designs evolve gradually rather than being fully known upfront. Embracing this principle empowers self-organizing teams, fosters adaptability and creativity.
Links
- Drive: The Surprising Truth About What Motivates Us, Daniel H. Pink
- View or comment on this article on Medium.com
THE poster to always have the Agile Manifesto right in front of you. Or simply, to visually enhance a dull workplace.
We are here to coach you and your team. We’ve got a range of awesome trainings for you to pick from.
