Part 1: The Employee Formerly Known As Architect
Every system has an architecture, but it is not necessarily designed by an architect. This post sketches a reference model for agile organizations without the role of Architect. Next posts in this series will provide best practices on how to improve architecture within this architect-less agile reference model.
Classic IT Architects do not fit in agile organizations
Agile organizations seem hostile environments to classic architects. The DONE-teams are encouraged to Do The Simplest Thing That Could Possibly Work (DTSTTCPW) and avoid Big Design Up Front (BDUF). In addition, teams are encouraged to be self-organizing and make their own decisions.
With a classic architectural mind frame, it is easy to feel left out in an agile organization. If you keep writing Project Start Architecture documents, it seems like the documents are never read. Or worse: you never get the chance to write the document properly, because the DONE-team has already started developing.
Architecture remains important
This blog post is the start of a series introducing best practices for architecture in an agile organization. In this new organization, there is a good chance that nobody has the title Architect anymore. Yet, the architecture of the system remains of vital importance to your long-term success.
The process for creating and maintaining architecture in an agile organization is different! Architecture becomes a team responsibility. So how can you make sure the teams make the right decisions?
Introducing an agile organization model
This first post introduces a reference model of a typical agile organization. The following parts in this series will build on this reference model to introduce the technical roles in all phases of the software lifecycle.
Getting it DONE
Agile is a container term for a number of processes: SCRUM, eXtreme Programming, RUP, DSDM and possibly others. The most popular agile process is SCRUM. This series assumes a SCRUM process extended with principles and practices from the eXtreme Programming community.
Figure 1 provides an overview of the SCRUM process. In the To Do column, there is a backlog with User Stories that are iteratively implemented into Potentially Shippable Software (DONE) in 2-3 weeks sprints. During sprints, there are daily standup meetings facilitating team communication on progress and impediments.
SCRUM is a lightweight process. It provides a helpful structure, mind set and best practices for a single development team. However, it does not help you on how to create user stories, manage architecture and scale over multiple teams. It also does not tell you how to bake a cheese omelet, for that matter.
In a larger organization, you probably need user stories, architecture and multiple teams. And probably, at some point you need cheese omelets too. So, rather than switching to a heavyweight process that covers all of these, you should extend SCRUM with additional processes and best practices for the challenges at hand.
You can choose the additions that fit with your organization.
Getting it READY
In order to write user stories before a sprint starts, you can introduce iterations preceding the SCRUM sprints to get stories READY. Figure 2 illustrates the model of an agile organization and how the READY team relates to the DONE team.
In a READY team, product owners cooperate with stakeholders, analysts and consultants in order to write specific user stories for the next sprint.
A product owner may serve multiple DONE-teams. However, in a larger organization, there may also be multiple READY-teams. For good communication, it is important to communicate over teams. A Scrum of Scrums is one of the solutions to facilitate this kind of communication.
Getting it PRIORITIZED
It takes time to write good user stories. If the READY team is unable to deliver stories before the next sprint, a DONE-team cannot start developing on time. How do you know which stories to write first? For this, you need to have a good understanding of priorities.
Priorities depend on your company goals. In most companies, the demand for new software features is larger than the capacity of people to realize the software. So, choices need to be made.
The reference agile organization model recognizes a Chief Product Owner who decides the priorities of new initiatives before user stories are written.
In order to decide on priorities, even before writing the final user stories, you need high-level analysis and communication. For this purpose, there is a Getting it PRIORITIZED phase.
Getting it in PRODUCTION
The only valuable software is software in production. Traditionally, SCRUM aims to deliver Potentially Shippable Software. In the ideal case, the DONE team goes one step further. The definition of done should be: DONE = LIVE.
At some point, there is a transition of software from development into production. And in production, software needs to be maintained.
In an agile organization, the transition needs to be as smooth as possible. And transitions need to be made as often as possible because the more often you do it, the easier it gets. Best practices to support this are described in the Getting it in PRODUCTION phase.
So, where is the architect?
Over the four phases, you have met product owners, chief product owners, developers and operators. But none of the phases bothered to mention an architect. So, where is the architect?
Remember the introduction of this blog post? It said: “In this new organization, there is a good chance that nobody has the title Architect anymore.” The good news is that the introduction also said: “Every system has an architecture, but it is not necessarily designed by an architect.”
Stay tuned for the next episode of How to Kill the Architecture Department
The next posts will explain the new roles for The Employee Formerly Known As Architect in the agile organization. Each phase has its own architectural role. Below is a sneak preview of one of the new roles. Keep reading following parts of this series and find out what the other roles are.
What are the responsibilities of a Technical Product Owner? And how do these compare to the responsibilities of an Architect in a classic organization? Please share your opinion by commenting below!
To be continued in two weeks!
common in the java coding world. It is, however, applied to the unit-test level only: one writes a unit test that shows a particular feature is not (properly) implemented yet. The test result is “red”. Then one writes the code that “fixes” the test, so now the test succeeds and shows “green”. Finally, one looks at the code and “refactors” the code to ensure aspects like maintainability and readability are met. This software development approach is known as “test driven development” and is sometimes also referred to as “red-green-refactor”. 
