10 Suggestions for the Architect of an Agile Team

Reminds me of Simon Brown's Coding the Architecture talks. I especially like that the Architect should write code.

...a '4 week iteration process'? Daily 'continuous' builds? Days of code freeze? Doesn't sound very agile to me.

I'd also be curious to know if he's tried dispensing with all those different teams entirely and evaluated productivity while incrementally building back up.

I prefer building a set of teams up based on iteration feedback rather than mandate all of these specialisations. There have been projects where all that was needed was two pairs of devs. For example, if you don't see very many production defects (i.e the automated build is catching everything), it may be more effective to just dispense with a testing team. Similarly if your build and deployment is automated, you shouldn't need a release team.

That is so correct, you have to be in the trenches to understand how it works. This is also one of the basic Toyota principles. Just adding a few more points to the list on the basis of our article published on Agile Journal.

Most points from far away look quite valid. Most of the points are perfect. Taking a detailed perspective I worry a bit about the self-organization of those teams though.

I used to have a lot of goals related to my architect job. But personally I think an architect has hardly more then those:

• change minds of the teams to take responsibility of the higher level (interfaces, department communication) of their own


• empower the teams to be able to decide on their own what you as an architect used to decide (make yourself useless)


• be a part of one team and take an architects role (as opposed to making the job of an architect)


• support the other teams with your knowledge

+ 1 -- Architects should write code.

The team is responsible for design decisions, not the architect.

Yes, this is what an architect should work.

As for the Agile fans: the product has to be done. An architect is a software engineer. He does not do things in an 'agile' or 'waterfall' way. He gets things done, he solves problems.

So, it does not matter as long as the product is good on both a user and a technical standpoint. Because this what will matter.

A four-week sprint is hardly very agile. On a team of any size you'd be able to get a huge amount done in that time, opening up the project to the risk of changing requirements, something that goes against the very grain of agile development.

I agree with the write code part, but I think the comment about the presenter not being able to write code as well as a regular developer is a mistake. The architect of the system should be someone who is an above average developer who helps pull the team up technically. Leading the team technically requires respect, and fostering something like point 7, a culture of quality, would be very difficult if the architect could not code as well as a regular developer.

It seems your definition of agile is different to mine then. A process that produces releasable software every 4 weeks (as opposed to months or years) counts as agile in my book, and we do continuous builds as well as daily builds. Note that I've also worked on projects with 1 and 2 week iterations which have worked well for different constraints. For this talk I was talking primarily about experiences in one relatively large team, and we found the longer iterations and the separation of responsibilities worked very well. But I make the point in the talk that my goal was not to say that this version of agile is better than alternatives, but I describe it to give context to the rest of the talk.

I don't want to get hung up on buzzwords, but your (Paul's) response underscores the fact that the process described in the article isn't an "agile" process. With an "agile" process, if the nature of the solution is such that architectural decisions are significant (e.g., the solution is not based on a well-known reference architecture), then someone with the qualifications to function in the Architect role would be included on the team, and the team would have collective ownership/responsibility for the architecture. Paul's choice of words suggests the Architect is not part of the team, but is a separate person who has individual ownership/responsibility for the solution architecture.

There's more than one way to solve a problem, and the process described here is one of them. I don't understand why people want to label it "agile," though. I wonder if some of the confusion about "agile" stems from the tendency in our line of work to associate everything "good" with whatever buzzword is popular at the moment. If this process is "agile," then Chuckie was a real boy.

Architects should write code - but when needed. Not full-time. Architects should write code to train, coach, mentor & demonstrate and prototyping the solutions architecture for the given problem. They should also spend time reviewing the code, design, quality etc. too to check whether the intended solution architecture and design is going according to all QoS, NFR, meeting the business requirements, and finally delivering the business value etc.

If they spend all their writing the code and become a full time programmer in the project & team then nobody will have the big picture of the project.

There lot of other technical things which need to be reviewed time-to-time as the project progressing.

Oh! boy in these days the word 'agile' is used for and prefixed and suffixed in company names, process names, product names, article names, conference talk names etc. everywhere!

People started using it for everything. If they think that if they are special in matter they just attach the agile to that to make and look it a special means to them is Agile !!! :)

Oh! boy in these days the word 'agile' is used for ....

How would you differentiate a Team Manager or a Senior Developer from this description. In his view you cannot as for him its someone in between. But whats forgotten here is Architecture it self. Who owns it. Who guides it. And who keeps it moving to the right direction. The role of an architect does not finish after the architecture is created but it actually starts after exactly that activity. Just as a developer is the owner of his code so in the same is the architect.
And most importantly the master piece word AGILE does not mean flexibility only. it does have some roots common to meaning "responding to change" but not submitting to it either. Thus the work *very flexible* rings so many bells.

Hope that helps Tom Hollander and the likes there of. :-)

Abel, thanks for the suggestions of how to lead a successful Agile team. Agile methodologies are so effective and only require a few key changes, as you suggest here. One thing I would like to add to your list, however, is deployment automation because it helps bridge the gap between development and operations teams and simplifies operations teams’ work. Rather than constantly being forced to play catch-up with a backlog of deliverables, employees can focus on the more important tasks at hand. Without deployment automation, companies only really achieve partial agile, since the increased productivity and deliverables get held up when it’s time to deploy them. Would you agree?

The article contains advice for the architect. It does not try to cover the entire development/QA/release process. Continuous integration and deployment automation are important, of course.
Your comment would have more value if you had used your real name. Using the name of a product/company as an indirect ad is not appreciated among our readers.

Hi,
I won't enter the Agile discussion here. But I wanted to point that I feel any time somebody adds an architect to the team, is accused of not using an agile process, like if you spoil agile by adding an architect!.
Architects are not a decease. We are a valuable team player (the ones that work on team, not the ones that live in the ivory tower, whose BTW should not be called architects), just as valuable as any coder. We simply do different things to complete the development process, which is not only coding.

William Martinez Pomares

Stefan,

I like your arguments, and to me they make a lot of sense. However, I must say that they, as you mentioned, work in a team with senior developers. I am currently working in a team with a mixture of junior and senior developers, and I think Tom's recommendations would work better.

I do not think one size fits all: the team structure and roles really depend on the composition and culture. Some practices/structures work really good in one team while they totally fail in another. To be Agile practically, you should first go through a few iterations and then based on the outcome decide how to arrange the team. Agile is about inspection and adaptation, after all :o)

Cheers,
Mehdi

It is the system architecture that gives the quality attributes of the system. Thus, if you are an architect, you are focused on the system's qualities, not the functions. This is a different mindset than that of a senior developer. Orthogonal, I would say.

On point 1: you do not do upfront design. You choose a database because persistence is a requirement and it is that requirement that has reached top of the list.

2. A vertical slice does not prove a thing other than you know how to build the system. If that was the point, fine, but that is one quality only.

3. The most important about requirements are that the quality attributes (e.g. performance) is understood and how the current system architecture will cope with it.

4 and 5 agree.

6. You will burn out if you are everywhere. Change the organisation to avoid being stuck in meetings or you will certainly not do 4 and 5.

7. For sure quality is important but to have a code review before each check in - I can't imagine that be fruitful. Pair programming is the cure against the urge for code reviews. They are out. Also, establish what you mean with code quality together in the team or you will not get any of it.

8. You are agile, right? Means that you have to refactor the architecture. Change some structures, move some interfaces, swap out a technology. Without fear.

9. We the team, is the shield and the scrum master is the button of the shield.

10. Yes. Strike a balance and admit that your documents are not the worthy the Nobel prize of literature. But more, it is about communication, remember? Use the walls and put it in everyone's sight every day.

Sorry, but this list is more like "senior developer" with some "project leader" thrown in.