Agile Architecture

Where Scrum provides velocity, architecture is the compass and gives direction to the development team. Without architecture, a Scrum team can drift off course and quickly drift off the target.

When we design and build software, we tend to focus on technical aspects of the architecture and not enough on the organization that has to build it. This can lead to all sorts of problems. We have a lot of influence on each other in an agile team and overlooking this can lead to a one-sided and inappropriate design. By including the social aspect more in the architectural decisions, a joint design approach is created.

This change places particularly high demands on the social and communicative

skills within the team. When working together it is sometimes necessary to maintain status and power

let go.

Value people

Strive for sustainable development, at a pace that can be sustained indefinitely by the development team, organization, customer and stakeholders. Work together as a team and learn from each other. Understand that one person doesn't know everything and everyone brings their own expertise to add value to architecture. Be respectful to each other and promote every opportunity to learn from each other.

Communicate

Work as closely as possible with all stakeholders, including customers and other developers. Encourage rapid feedback by collaborating on models and documents. Remember that the best way to convey information is a face-to-face conversation, supported by, for example, a whiteboard. Shared development of a model, on a whiteboard, will provide excellent feedback and support.

Less is more

Minimize complexity. Simplicity reduces the amount of work that needs to be done by the team. The simplest solution is usually the best solution for the customer. More complex solutions will be more difficult and more expensive to maintain. Don't be afraid to throw things away if they have served their purpose for the team and are no longer useful.

Embrace change: plan it, arrange it!

Plan for change. A customer's requirements are constantly changing due to different circumstances, experiences and/or new insight. Understand the likely directions of change by looking ahead using techniques, such as analyzing scenarios, and looking back at past change experiences.

If a particular change keeps coming back, try to find ways to make those changes easier to make and undo. Make recurring changes without unnecessarily changing documents, source code and/or data structures.

Choose the right solution

The team must know the stakeholders, including their goals, needs and constraints. Stakeholders are those who use and pay for the system, but also who develop, deploy, maintain and operate the system.

Have courage in the architectural decisions. Listen to the arguments, but don't let one stakeholder or interest dominate the decision-making process.

Deliver quality

Focus on quality, but measure quality by the value and usefulness of customer deliveries, not process compliance.

• Plan and design for testing. Some agile methodologies (particularly eXtreme Programming) state that tests are performed before the first line is coded.

• Test concepts. In order to test the architecture and mitigate risks, it is good practice to first develop a prototype. Develop major customizations when the architecture is proven.

• Where possible, deliver products regularly and roll them out often. A regular delivery cycle makes it possible to learn and adjust the architecture in a timely manner.

• Make sure interfaces are clear and well defined. This applies to physical interfaces to other systems as well as to human interfaces.

• Adapt the process to the organization. Help each other to regularly look at how it can become more effective and adjust methods and behavior if necessary.

Modeling and documenting in an agile way

Being agile in modeling and documentation is a key in doing agile architecture. Make sure that the model is created with a purpose and that the model is created in small steps. Use the simplest tools so that modeling is possible with everyone on the team. Apply modeling standards and discard temporary models when they no longer serve a purpose for the team.

Finally, Agile Architecture in practice

The eleventh principle behind the Agile Manifesto states that "The best architectures, requirements and designs come from self-organizing teams". Many people have struggled with the idea of finding a good Agile approach to designing solid architecture, such as Alistair Cockburn and his "walking skeleton" for example.

One particularly important practice that successful teams adopt is prototyping prior to a target sprint. Continuous exploration of the architecture allows the team to better focus on making the architecture flexible enough. A flexible architecture helps to support the realization of future customer needs.

Agile architecture helps teams to find a practical balance between not too much up-front architecture on the one hand and insufficient architecture on the other.

Know more?

Agile in Focus has a lot of experience in setting up an agile architecture for large and small organizations. At Agile in Focus we are committed to help your development organization to be competitive in a rapidly changing market. We can advise you on this.