Architects & Scrum: 2. The agile values

This blog is the second of a series of blogs in which I will examine the role of architects in Scrum. Last week I started with the forgotten questions of Scrum. In this blog I will look in more detail to the Agile Manifesto and the agile values.
Architects and the agile values
Most of the literature concerning the role of architects in an agile context focuses on the Agile flow itself and how architects can avoid disturbing that flow. Mike Cohn, in his book “succeeding with agile” makes the distinction between coding & non-coding architects. In where he states that the coding architects will have less trouble finding their new role in de Agile development process.
An architect within a team has to be able to code himself. He is a team member, who has more experience in structuring the application being build compared to other team members.  By using that experience he can add value to the team.  Scrum has no particular role for non-coding architects. The question rises if this is totally true.
The role of architects in an agile environment should at least follow the agile values from the agile manifesto. Examining these values leads to guide lines that architects need to follow in able to be of optimal value for the organization.

1. Individuals and interactions over processes and tools
   The first agile value states that we are dealing with people and the way they communicate. Processes and tools can be helpful in certain situations, but should never become overemphasized. Obligatory thick architecture documents at the start of a project or the lengthy review procedures of documents, are examples where processes and tools have gotten too much attention. In a Scrum environment this is out of the question. Therefor Architects have to change their focus from written to oral communication. They have to communicate in person as much as they can with all of the stakeholders in the organization. Architects need to be able to communicate equally  well with the product owner as with individual members of the teams. Communication has to be two-way, enabling the architect be fed with ideas from others. Architectural frameworks like TOGAF can be used, but only if it helps the architect to get the message across. The method can never prescribe the activities the architects should do.
2. Working software over comprehensive documentation
   Architects in the past have been doing this from a distant perspective from the builders. Communicating through extensive design documents proofed to be not the most effective one.  Although architects themselves can be very proud of the documents they produced, this will not work within an environment with Scrum. Implementing Scrum in an organization urges the architects to focus much more on the communicative part of their job.An architect has to focus more on drawing sketches. He has to talk about the sketches to all the stakeholders. Adjust the sketches to remarks that customers en suppliers make.  Adjust the sketches to ideas given by the development team. But also the sketches to the impediments found during implementation, which makes them more in line with the real world.  Using sketches helps the architect to create a common view about the design of the software with all stakeholders, which helps to raise the quality of the software developed.
3. Customer collaboration over contract negotiation
   Architects have a big role to play in aligning IT and business. In companies with a complex multi-system environment, and multiple agile teams, the architects should be very close to the product owner, helping him to create maximal business value out of the requirements on the product backlog. By sketching the solution and giving insight in the complexity of this solution, the architect can help the product owner in settings its priorities even better, and support teams with the outcome of these global design discussions. An effective relationship between the product owner and the architect can create more business value with less effort.
4. Responding to change over following a plan
   The architect has to be able to respond to daily change. The best way to experience daily difficulties which can lead to changes, is to be close to the development team. The architect should be there to be consulted about all kind of practical design issues. The architect has to adjust his own sketches of the future continuously. The architect should be able to let go of some of his ideas if they are very difficult to execute.

Following these agile principles the architect has to communicate & interact more than ever with all stakeholders. In his communication he should make use of sketches instead of large documents. His working desk should be close to the teams and he should daily talk to the product owner. Most of this is focused on “strengthening the heartbeat” of the Scrum teams. He can add more quality to the software and speed up teams by smart designs.
However in my opinion there is missing something. So what is the missing ingredient what could make architects really successful?  In next week blog I give you my answers to that.