Architects & Scrum: 4. What is the role of the architect in Scrum?

In my last blog I presented an illustration which shows the two primary aspects of the architects’ role. On one side they play a role in strengthening the heartbeat. On the other side, they play a role in envisioning the future.
The focus in this blog is on the solution architect or application architect. The way the Enterprise architect deals with Scrum will be explored more in detail in a later blog.
What is the role of the architect?
Last blog I presented the illustration as shown below. In this blog I will focus on the parts of this illustration in which the solution architect / application architect plays a role
Product backlog
Traditionally, architects have been the chief designers in software development. Projects often start with an extensive project architecture document, in which the solution has been written down using many words and lots of paper. In today’s Scrum practice, the focus is on the most prioritized epics and user stories in the product backlog. Epics and user stories are usually short. Teams take epics and user stories from the backlog and design the best solution for them. So what is the role of architects at this stage?
In fact, architects have a very important role during this stage, especially in larger organizations with many software systems. They discuss the requirements with the organization and make the first global design decisions for each epic on the product backlog in line with the overall architecture. In large organizations with multi-layered SOA architectures, the number of software components used can be very high. Ten to twenty agile teams working on new features is not an exception. Architects make the first global design decisions because they are the ones who oversee the whole picture. Questions have to be answered, such as ”do we need extra components?”, ”do we adjust existing components?” and “in which layer of the architecture do we want to implement the change?” These decisions are not made by architects alone. They discuss them with product owners to determine their real needs, and they discuss them with the agile teams to determine how the software really works.
The design decisions made at this stage are normally written down on no more than one-half page. If this is not the case, then the architects could lose themselves in details. These details will be discussed in the teams. The architects can also make an initial estimation of the complexity of the solution, which can be used when epics are picked up by the teams.
Architects help to narrow the cone of uncertainty. The cone of uncertainty describes the evolution of uncertainty during a project. At the beginning of a project, comparatively little is known about the product or work results, so estimates have a high level of uncertainty. Architects help the product owner reduce the level of uncertainty, making it easier for the product owner to set priorities and for teams to focus on the specific solution within their areas of expertise.
Agile teamwork
Architects are present daily on agile teams. They have to discuss the upcoming epics/user stories in the next sprints. Additionally, daily design decisions are made together with the teams on a lower level. This provides feedback to the architects about the positive and negative sides of the global design decisions they have made. Architects without experience in the teams will lose contact with the real world.
Architects also have an important role in monitoring the architectural principles through all layers of the architecture. This means, for example, that they have to know whether all business rules are implemented within the business layer or whether customer information is always stored in the CRM component. Being on the team can help architects make architectural principles more practical; the architectural principles evolve from a practical standpoint.
The architectural principles also include more technical aspects, such as the use of middleware and hardware. Ideally, the “definition of done” within a team includes the deployment to production. In this respect, the DEVOPS movement has recently become stronger. The architects can provide guidance in performance issues or security issues. This brings these aspects of software development closer to software developers and analysts.
Cooperation in teams between developers, testers, performance specialists, hardware specialists and others will help to create and capture new ideas. These new ideas might not always be implemented directly. New ideas can also impact other teams, or software redesign may require extra time or expertise that is not available to the team, which means the team cannot implement the ideas. So how can architects deal with these ideas?
 
Dealing with design ideas
Architects who are helping to groom the product backlog and who are working in agile teams are often very busy with daily problems. But there is a second, equally important part to their role: to envision the future. They step out of the daily problem-solving activities to evaluate the big picture. What new ideas are desirable and possible? How does current progress influence the overall architecture? This thinking results in what we call design ideas.
First of all, new design ideas can emerge from grooming the product backlog and working in the teams. Ideas for new components or ideas to change existing components emerge. The focus in agile teams is often on the speed of delivery, so the business can adapt quickly to changes in its environment. Although this is a major strength of Scrum, it also makes architectural deficiencies very likely. Software redesign is not done properly because of lack of time, or is not done at all. It is important that these shortcomings are acknowledged and written down as design ideas for future sprints. A design idea with a valid business case of its own should also be placed on the product backlog.
Design ideas arise not only from software architecture; technical and business areas are also a rich source of design ideas. Virtualization of the hardware can save a lot of money and reduce complexity. Regulatory compliance demands more control over traceability. These types of ideas are often executed by the IT department, without a direct connection to business goals. However, these design ideas should be linked to business requirements and find their way to the product backlog. If necessary, new agile teams — guided by product owners with help from the architects — can be formed to handle the implementation of these ideas.
New ideas also emerge from the strategic alignment of the business and IT. This is the domain of enterprise architecture and IT strategy. IT can become a critical success factor for the business and a catalyst for future business change. Enterprise architects or chief information officers are closely related to and cooperate with organization management. Their goal is to see how IT can be employed as an important production factor in the organization. Enterprise architects translate strategic choices into new design ideas. These design ideas will also find their way to the product backlog.
Traditionally, architects decide on the architecture and on the conformance of software to the enterprise architecture. But a transparent assessment of the real business value is rarely made. Conformance is king. This dynamic has changed in the new reality of Scrum. We employ a different approach for translating enterprise architectural requirements into concrete software artifacts. The main purpose of design ideas is to select the right ideas or architectural features to implement, based on actual value. The first step is to organize design ideas in a backlog. Architects use that backlog while collaborating with product owners in evolving the product backlog. This collaboration is based on a partnership aiming towards business value, now and in the future.
Business value does not necessarily equal cost savings. It is also found in continuity planning (e.g. when the number of servers needs to be increased to preserve system stability) or in software adaptability. The choice of which design ideas to implement is ultimately made by the product owner. Architects have an important role in explaining and promoting these ideas.
Balancing the work
In companies with a complex multi-system environment and multiple agile teams, architects should be very close to the product owner, helping to create maximum business value out of the requirements on the product backlog. By sketching the solution and the complexity, architects help the product owner to set even better priorities, and help the support teams with the outcome of these global design discussions. Also, new design ideas will be discussed with the product owner and possibly placed on the product backlog. An effective relationship between the product owner and the architects can create more business value with less effort.
If we follow Chandler’s principles, the adoption of Scrum should include an alignment of structure, process, and strategy — or it will fail. At best, it results in a sub-optimization within the overall enterprise. In this white paper we explored the alignment of Scrum with the architectural processes and showed how the role of architects within an agile context takes shape in order to create more business value.
Agile architects focus on the most important outcomes of their work. They go back to basics and chose their tools deliberately. By focusing less on documentation and much more on communication, they can become an important accelerator for sprint teams and help the organization to build business value by fostering new design ideas.
But architects not only focus on daily business activities and on strengthening the heartbeat of the Scrum teams. The second pillar of their work is envisioning the future and clarifying the enterprise architecture. All architects therefore should claim time for this and communicate the benefits for business and IT.
Agile architects do not live in ivory towers. They are pragmatic and involved in daily business, while not forgetting their role in envisioning the future.