Architects & Scrum: 2. The agile values

Niklas Odding

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.

Comments (5)

  1. Architects & Scrum: 2. The agile principles - Reply

    January 26, 2011 at 4:01 pm

    [...] Scrum. In this blog I will look in more detail to the Agile Manifesto and the agile principles.... [full post] Niklas Odding Xebia Blog 0 0 0 0 0 [26 Jan 2011 [...]

  2. [...] This post was mentioned on Twitter by Xebia Nederland, Alltop Agile. Alltop Agile said: Xebia Blog: Architects & Scrum: 2. The agile principles http://bit.ly/dTfXNk [...]

  3. Elias - Reply

    January 27, 2011 at 7:31 pm

    I basically knew about virtually all of this, but having said that, I still considered it had been practical. Good work!

  4. Tarun Sapra - Reply

    January 28, 2011 at 10:06 am

    Nicely written, specially liked the part 'Working software over comprehensive documentation' , most waterfall Architects spend so much time on documentation without writing any code thus in Agile it's of high importance for an Architect to participate in code.

  5. Sander Hautvast - Reply

    February 2, 2011 at 10:43 am

    Responding to change over following a plan:
    I guess, working close to the developers is a neccessary step, but is it sufficient? James Coplien for instance mentions separating the dynamic from the static parts of the application.
    Another worry I have is what Coplien calls an architecture as fixed as hardened cement. What if the (enterprise) architecture over the years has become a rigid colossus that nobody dares to shake up? Coplien hits a painful point, saying that refactoring is hardly ever done but locally (in a single application). Such an architecture limits being able to respond to change. Yet I find no solution for this in his book (Lean Architecture).
    These fixed architectures may very well be the result of those distant architects. What are your thoughts?

Add a Comment