From the Mist

Scrum for architects: how scrum helps architects to create and sustain an enterprise-wide architecture process.

Slowly we are learning how to use the simple format of short standup sessions, called scrum, to help teams in sustaining impetus. A scrum session typically lasts only 10 minutes, with the participants standing. Discussions, opinions, or other ego-vehicles are not allowed, or the format just does not allow for it. Each participant summarises three aspects of her/his contribution to the team’s goals:

1. What is it I have been working on the past day?
2. What problems or hindrances did I encounter and how will I deal with them today, or how can anyone from the team help me with that?
3. What is my goal for the work I will be doing today?

This is a daily format, it is useless to do it less often, and equally counterproductive if the sessions are allowed to last longer.

Now let’s introduce the “architect scrum”. Organisations may be working on implementing an architecture process, in which the actors are architects or anyone playing the role of an architect. As I’ve written elsewhere, this role will be played by probably everyone within the enterprise. An architects’ role is played each time someone needs to make an “architectural decision” (any decision with transitive effects).

1. The person needs to be aware of decisions that are architectural: what is the characteristic of an architectural decision?
2. The decision needs to be documented or marked as such
3. The decision needs to go through the phases of:
   1. can I make this decision — yes: go ahead, no: consult peers, and make the decision if possible
   2. if option 1. did not resolve the issue: escalate to the next “higher” architecturally responsible person
   3. repeat the phases with that person

There is a bit more to it as we can read in the article referred to above, but this is sufficient in the context of this article.

So we see that architects move about in many levels of the enterprise, and if we have implemented an architecture process, these levels are bound in a controllable and sustainable process with roles and responsibilities clear and unambiguous.

However, these processes are “late bound”: they take place in the regular context of concrete decisions and the work that produces the need for those decisions. What a scrum session does for a development or project team, it can also do for the pool of architects, across projects and departments, across the entire enterprise.

What I want to propose here is daily Architect Scrum sessions. These sessions are, different from the standard scrum, not tightly bound to a project, but are bound to the enterprise. We want our architects to be aware of what is happening elsewhere, but also we want them to learn from each other as much as possible. The scrum sessions are not for learning, but for creating avenues for learning: we learn that an architect in another department is doing something interesting or challenging. I may be able to learn a lot from her, because I am on the verge of doing something similar. We can also create ad-hoc cooperation when another architect reports some issues he is wrestling with and I know a solution, or someone who may know the solution.

Architect Scrum promotes an “anarchistic” cooperative mode, which lends itself very well with the support of an architectural Wiki, serving as a non-structured vehicle for knowledge exchange.

What do you think? Do you have something similar?