Agile software development, the principles. Principle 11: The best architectures, requirements, and designs emerge from self-organizing teams.

This is the eleventh of 12 posts about the principles of agile software development. Purpose is to go back to the start of the agile manifesto (http://agilemanifesto.org/principles.html) and discuss the implementation of the 12 principles in real life software engineering. Goals of agility are to go deliver software of higher quality, faster, with a higher acceptance to end-users and able to follow the changing business requirements to strive for competitive advantage.

The question is: is this going to work in practice or is this only based on a nice marketing and sales story.

Principle 11: The best architectures, requirements, and designs emerge from self-organizing teams.

For a long time the engineering expertise (and also software engineering) was based upon the condition that you worked with specialists. These specialists emerged from the principle of division of labour and made it possible for these specialists to focus their attention on their specialism and create the best solution within their field of expertise. The Interaction designer designed a user interface, the architect created a global systems model, developers created code and infrastructure specialists created the necessary environment to run the application on.

Everyone was specialized and delivered the best solution within their capabilities. However when all these components where put together, noting worked. It is an illusion that specialists can design and foresee everything beforehand.

Within agile projects the solution is to use a self organizing team to perform these tasks. This team may consist of specialist, but this is not a requirement. The requirement of this team is that they work together and self-organize all aspects of the systems to be delivered. This team is permitted to make errors and invent their solutions, provided that they deliver and evaluate frequently (retrospective) and learn from their successes (and errors).

Most traditional specialists like architect, infrastructure specialists and especially project managers (and also customers) will have problems with this approach. Their reaction on this approach is to warn for a result in chaos and anarchy. The team can lose all purpose and meaning without specialists and leaders. However the secret for successful self organization is taking your team serious. They are professionals (and not just a bunch of resources).
Does your team consist of workers (ants) that execute the design? Or does your team consist of intelligent and motivated people? Why should you not use this capacity and challenge your team? Trust your team to deliver a good design and to make good decisions.

Another strange thing of traditional development is the employment an analysis department. Why do we need specialized teams of analysts? These analysts gather requirements form senior users. We, as the team of developers, cannot see (or speak) to these users. Suppose we, as communicative unskilled developers, take too much of the precious time of these users 🙂 . Instead we play the “whisper game” where the requirements are being handed over via users, senior users, analysts, technical designers and finally developers.

Make users part of the team and let them gather the requirements together with the developers. This way the actual users of the system can specify those requirements that actually add value to their work.

How to handle (technical)designers? Make these designers part of the team and let them build parts of their designs themselves. Designs become practical, simple to implement and easy to maintain. The same is true for architecture. Let the architecture emerge from the team itself.
Can architecture emerge from the team itself? A software team that changes its architecture on a day to day basis is not able to deliver any valuable software. The way to manage this architectural freedom is to agree upon architectural boundaries with the agile team. These boundaries are the borders where the architecture can oscillate between. E.g. the boundaries are set by the development language (Java, .Net), type of database or the application of specific frameworks. The team agrees upon these boundaries and is able to change the architecture between these boundaries. You can visualize this evaluation of the architecture by a half-pipe and a marble rolling down this pipe. You can let the marble follow a rout form left to right but you are bound to the limits of the half-pipe. The same is applicable for the architecture. You can vary the architecture between the boundaries and let the team iterate to a better /optimal architectural solution.

Architecture boundaries

Conclusion:
The best ideas emerge from your own team. The team members must be able to cover all aspects of systems development. They must work together creating functional requirement, designs, architectures and implementation plan’s. You do not need specialist, but you need a team that is able to work together and is empowered to make decisions. You have to trust your team to make the right decisions via experimenting and learning from their own errors. Do not “trust” separate teams of specialist (architect, designers and analysts) to deliver better results without being a part of your team. The best solution will emerge from your own which is committed to deliver. Trust them to come-up with the best results.

Other posts about the AGILE Principles (soon to come):

1. Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
2. Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.
3. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
4. Business people and developers must work together daily throughout the project.
5. Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
6. The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
7. Working software is the primary measure of progress.
8. Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
9. Continuous attention to technical excellence and good design enhances agility.
10. Simplicity–the art of maximizing the amount of work not done–is essential.
11. The best architectures, requirements, and designs emerge from self-organizing teams.
12. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.