Lisa, Vin, and Derek in their comments on Agile, Architects, and Programs were concerned about how an architect might lead the test architecture work. They have good reason to be concerned. I hadn't expressed how I see architecture working in an agile program, and they haven't been to my talks, where I have discussed it. This mind meld stuff doesn't work yet in blogging. Sorry, folks. I'll try to be more specific.
I am not talking about an external architect, who leads from an ivory tower and does not get his or her hands dirty. Read my most recent Gantthead.com column, Agile Architecture and Program Myths. External architects do not add value to an agile project or an agile program. Derek, while I agree with you in principle, have you worked on a complex product or system with a few hundred people? If you have and you have not had architects to guide the development, how did you succeed? I'm talking about guidance, not policing. I suspect we agree more than we disagree, but I'll leave that decision to you.
First, the architect is responsible for the business value of the architecture, not for telling people what to do. An architect can do this in many ways:
- Balancing the short-term goals with the overall system integrity, risk, expediency, technical debt, anything else that you would trade off short term goals against.
- The ability to sustain development against technical debt. For test systems, this is the age-old problem of testing vs. automating the tests and how you automate the tests. I'm a huge fan of automate enough and refactor your way into what you need, because you may not know what you need until you see how the system under development evolves.
- Writing acceptance criteria for system qualities and quality scenarios.
- Leading the definition of how a complex system is structured, organized, and implemented. Landing zones can help guide this effort.
- Working with the team in a hands-on way. No seagull architects. No PowerPoint architects. No prophets. No police. Agile architects develop code and develop tests.
- Architects work with the entire project team, not just the challenging or interesting parts. In fact, if there are rote parts or boring parts, maybe that's where the architect is needed most to automate something so humans don't have to do it. In my workshops and in my executive briefings, I tell managers they should put their most talented people, aka architects, on the things that prevent them from easily moving to agile. For complex programs, those are most often the build system and test automation. I suggest they use the architects for several iterations to make significant progress on those problems, and get to some version of done.
There's a reason I don't call a program architect a “chief” architect. I don't want to have the notion of hierarchy. I firmly believe that the architect is beholden to the program, to the business results, not to the organization's hierarchy. That's somewhat naive on my part, but using the word “chief” reinforces the hierarchy.
Architects lead by doing. Sometimes they do the hard work to pay down technical debt that's been accumulating for years. Sometimes they do the hard work of seeing how the features are evolving into an eventual framework, or two or three. And, when you have 200 or 300 or 400 people on a program, all over the world, working in 2-week iterations, I still think you need people who are exploring just ahead of feature teams, so that the feature teams are free to develop features. I hope some of you agree with me.
There is a difference between agile on small projects of 1-3 teams and agile of 4-8 teams, and agile of 9 teams and more. Part of it is the communication paths. See my post of Why Team Size Matters for the issue of communication paths. Part of it is that coordinating the design and architecture among very large programs is a non-trivial task. It's partly managerial in nature. It's partly technical in nature. It's not a problem that can be solved with hierarchy and maintain agility. And it is a difficult problem to solve. If you have solved it in your organization, I would love to hear from you.
Johanna, I for one agree with you when you say that some people need to look ahead. Anyone who thinks that specialist architects are not required does not study nature enough. Nature has been specialising life forms all around us. Specialist architects are required and to discount that in a reasonably complex project is naive at best.
Having said that architects who are just drawing and making power point presentations are useless. Architects need to lead. In my experience best architects tend to do merciless refactoring. They prototype concepts before the feature teams are ready to start the implementations. If an architect does not involve with these things, IMO making them architects would be a wrong decision.
PS: Out of topic, but your name is so scandinavian!
(Personal: My family’s history is German and Polish. I think 🙂 Certainly Eastern European. If we ever meet, you will see I inherited the short genes.)
How does the Agile Architect’s time get accounted for in sprinting? I assume the architect should not be outside the system. I assume she should be a member of one of the sprint teams. Our current process falls back to your Feature-itis article. We only estimate the cost of features. Any architectural work is assumed to be accounted for in the feature estimates. So we have oddities like this: a list of 15 messages to be implemented where message #1 is 10 days work to cover the structures needed for this class. All the others are 1 day.
The other way this happens is what the developers have started calling, “Pointless Work.” That’s work we need to do but it’s not a Feature so it doesn’t have any points assigned to it.
Are there better ways to account for time spent on architecture?
Larry, is there a way to break down the work to smaller chunks rather than the 10 days? I suspect you are doing some exploration, some testing, some checking with other people, other stuff, that you are stuffing into the big “class” called architecture. I would break it down so it’s easier to explain it. (Back to my inch-pebble approach, so it’s easier to understand.) Then you can understand it. Dan Rawsthorne calls this “chores.” I think Chris Sterling calls it something else, but I have to look it up.
I would disagree slightly.
In organazations greater than 50, I don’t see a singular architect doing much
Code or tests, except where required to illustrate or educate more junior people.
Rather I look to the singular architect to:
1) act as editor in chief for architecture decisions on the team.
2). Guide the individual architects that do the actual work (these guys are embedded in the scrums, and write code, basically conforming to what you say in the post)
3) helping establish new products that are based
On the architecture. This means understanding re-use, establishing a vision for how the architecture slowly evolves as new products come and go.
4). Help the business people understand and take advantage of the architecture for new system features, third party integrations, and new product lines.
We find with large software this singular (editor in chief) model for the architect works well (if you have the right person doing the job)
In more static environment where there is less cross scrum
Coordination, possibly such a role is less useful.
In our industry (large embedded systems) a lot of our features impact 2 or more scrums (although we try to slice as vertical as possible)
Mike
Michael, with my program manager hat on (program of 50 people), one architect seems like a large risk. I would think you would need more. Maybe that’s why you have the editor-in-chief model.
Typically about 20% of the org will serve in the capacity of architect at any given time.
Out architects implement and influence their internal design as well as create system wide solutions.
One of our greatest failures was an architect who took a particularly non agile approach to a system design. The editor in chief didn’t catch it. it was really bad (a good learning experience)
My point regarding the article is that it is easy to confuse “developers who architect” with the “singular architect”. On small projects they can be the same, even if there are a few people architecting.
For large projects I believe the leadership portion of the role would be separate from the technical part. And I would not make this a manager role. Our architect is an individual contributor, extremely technical, but also very experienced and able to converse with business people and management with ease.
The problem isnt that he can’t write tests, do code and the like, it is just that the scope of the project is such that it isnt an effective use of his time. He is better off mentoring other architects when required.
Mike
> is there a way to break down the [architectural work] into smaller chunks rather than the 10 days?
We have started doing that but it turns into “pointless work.” Mgmt only wants to track velocity of value-to-the-customer. By their definition, that’s end user features and only end user features. If it’s not a feature, it can’t have any points.
10 days for one message is our way of pushing back to say that this feature has hidden costs.
I understand the objective – that we want to stay focussed on customer value and not spend time creating grand but irrelevant architecture. However our current methodology seems a bit disfuctional.
Pingback: Agile Architecture | Development Block