Part 11 in a 12-part series. This post covers how emergence leads to better products.
Of all the agile principles Blake and I have covered, simplicity is the one I ponder the most. It’s my “most and least favorite”. Why?
Because of what it suggests in the process of creating products or services. Here’s a good question.
How do we simplify this release so that it has a value that our client or customer will appreciate?
The answer lies in the work not done. An outcome of not doing work allows for emergence because there is time to consider the point below:
The best architectures, requirements, and designs emerge from self-organizing teams.
Principles behind the Agile Manifesto
Consider when a painter says, “The canvas compelled me to paint this.” Or a sculpture states, “The rock spoke to me about its ideal form.” In essence, the artist allowed emergence and beauty was created.
Similarly, products emerge when teams are allowed time to ponder their options. What is notable is the authors mention “self-organizing”.
In a practical sense, a self-organizing team has experts in different technical and non-technical fields. Emergence can occur when there aren’t external influences or constraints on how the team choose to work.
Power of emergence
For example, when developing software, a business analyst may assist with reviewing a user interface design. Quality assurance testers may work side-by-side with developers. The possible combinations for how a team supports each other are potentially limitless.
Ideally, the entire team could be engaged in solving the problem at hand. Then they could work in pairs or triplets to bring working pieces together as a solution. The goal is to make sure the pieces fit together to create the whole.
Additionally, the structures supporting development come from the team instead of being imposed on the team. Architectures and designs flow from requirements as understood by the team working alongside the customer.
It serves not purpose to work independently of the customer. As well, it is counterproductive to impose structure on teams, as it stifles creative focus.
To summarize, the people closest to the work learn the right ways to complete the work as it emerges.
You can learn more about Agile Principles in Part 12 of this series: Reflecting to Improve.
Principle 1, Principle 2, Principle 3, Principle 4, Principle 5, Principle 6, Principle 7, Principle 8, Principle 9, Principle 10, Principle 11, Principle 12
