Eventually Consistent HTTP with Statebox and Riak
Bob Ippolito explains how to solve concurrent update conflicts with Statebox, an open source library for automatic conflict resolution, running on top of Riak.
News
The content has been bookmarked!
There was an error bookmarking this content! Please retry.
10 Suggestions for the Architect of an Agile Team
Posted by Abel Avram on Sep 14, 2010
Tom Hollander, a Solutions Architect at Microsoft Australia, held a presentation entitled The Role of an Architect in an Agile Team at TechEd Australia where he discussed what he does as an architect leading an agile team.
When talking about the role of an architect, Hollander means a “solution architect’ or an application architect. He does not refer to an enterprise architect or a specialist one (specialized on a specific field like messaging or infrastructure).
Hollander’s team has a 4 week iteration process with a stabilization period – code freeze for a few days - at the end, practices daily stand-up meetings, continuous integrations with daily builds followed by automated tests, and is employing a number of roles:
- PjM – is the Project Manager, similar to a Scrum Master, making sure the team is following the process.
- PdM – is the Product Manager, also known as the Customer or the Product Owner, determining what the product is supposed to be
- Architect – a solution/application architect
- Dev – the development team
- Test – the test team
- UX – the User Experience team
- Release – the Build and Release role taking care of the building process
Hollander has come up with a top 10 list of things for a solution architect to be successful in an agile team:
- “Just enough” upfront design – except for very simple projects, a certain amount of upfront design – 1-2 weeks - is absolutely needed based on what type of application is - web app, smart client, mobile or batch –, what are the basic functionality requirements, a long term solution or an intermediary, temporary one. The purpose of the upfront design is to decide: what technology to use – for example, ASP.NET or MVC –, what type of application - a 2-tier, a 3-tier or a service-oriented application –, accessing the DB – stored procedures, Entity Framework, LINQ, DI. All that can be contained in a short document for reference.
- Start with a vertical slice – means starting with a small piece of functionality – a logon page, for example – which cuts as many vertical layers as possible in order to tie together all the technology pieces decided during the previous phase. This will demonstrate that the design decisions are correct and all pieces are working together, and will represent a pattern for developers to follow when developing the additional code. If the initial design decisions turn out to be inappropriate, now it is a good time to change them.
- Just-in-time design each iteration – At the middle of a 4-week iteration, the project manager, the product manager and the architect should meet to discuss the requirements to be addressed during the following iteration, to make sure they all agree on them, what is more important is put up in front, and everything is understood. That discussion goes on for a week in the background of the current iteration. The following week, the last of the current iteration, the architect reviews the requirements for the next iteration, making the necessary design decisions so the team can start working on them the following week. If the requirements are quite different from previous ones, then the architect does some prototyping, writing some code as a proof of concept, writing some diagrams and putting it all together in a 5-page document for reference. This is not meant to do detailed design decisions made for the developer, but rather to make sure the new requirements fit into the big picture.
- Trust your team… but be there for them – this has to do with the relationship architect-developer. The architect needs to make sure he does not overstep his role, making the developer’s job boring by taking all the fun of decision making. In the same time, the architect needs to be a mentor for the team, solving difficult problems that might bog down the developers. The architect should be in contact with every developer each day, knowing what they are doing and helping them if there is a coding problem. This is especially needed when dealing with developers that don’t like to ask for help and try to solve problems on their own with the price of spending an entire week with that. This kind of relationship also applies to the PjM and test/build/release team.
- Write code! – The architect should know what’s in the code in order to have a better idea on the impact of his decisions. He can also figure out when a refactoring is needed. A code writing architect has better credibility with the development team. That being said, Hollander does not believe in role dissolution. He still thinks an architect remains an architect, and he’s not necessarily as good at writing code as a regular developer.
- Be involved in everything – It is good for the architect to be involved in all meetings related to his project: design, development, code reviews, requirements planning, etc., because he can have a larger and more clear perspective on what is going on, and he can help the product manager to avoid making wrong decisions in an early stage by informing him/her on their possible outcome.
- Drive a culture of quality – A successful team, one that anyone would like to be part of is one built on a culture of quality: nobody cuts corners, nobody checks-in sloppy code, if there is a major flaw in the design it won’t pass unnoticed, all are honest and open, looking for the best outcome of the entire team. Hollander admits that it is hard to build such a team, but it is possible. Firstly, the architect should establish some rules in the beginning, rules are are not going to change over time because a developer happens to not like them. One example is the decision to write unit tests. Another is having a code review before each check-in, including the code submitted by the architect. If the code is not accepted by the reviewer, which can be anybody in the team, the code is not checked-in.
- Know when changes are required – The architect should be very flexible and ready to make design changes when they are required. It may be that an early solution is no longer appropriate, or new requirements demand a different approach.
- Shield the team from external randomization – While this is usually the job of a project manager/Scrum master, the architect can get involved in protecting the team from external requests that tend to divert the team’s focus and take time from actual work. One example could be various requests coming from the operations team wanting certain things to be done in a certain way, and their requests are not always reasonable or something that has to be implemented.
- Write docs … but only if someone needs to read them – Hollander is not the adept of documenting everything, nor one of writing no documentation. He thinks there is necessary to have a balance, writing the amount of documentation that is actually helpful and is read by someone. Documents are good to remember detailed design decisions like a data model. Iteration design decisions, while they are discussed with the team at the beginning of the iteration, it is recommended to be saved in a 5-pages document for the developers to go to if one of them does not remember what the architect said. This also helps new people working on the project long after the initial developers and architect moved to another project to understand why some of the decisions were made.
As a conclusion, Hollander said the architect should make sure he is part of the team in theory and in practice. The architect is not supposed to write all the code, only a small portion, he is not testing or deploying it, but he is rather making sure the entire process runs smoothly.
- This article is part of a featured topic series on Agile
- See more Agile content at: http://www.infoq.com/agile
- Other recent content items in this topic
RelatedVendorContent
Agile Development: A Manager's Roadmap for Success
A Guide to Branching and Merging Patterns
Related Sponsor
In today’s hyper-competitive world, later may be too late to adopt Agile development and this Roadmap for Success will help you get started. Download "Agile Development: A Manager's Roadmap for Success" now!
Not a bad list!
by
Martijn Verburg
Posted
Re: Not a bad list!
by
Vikas Hazrati
Posted
Re: Not a bad list!
by
Lorenzo Dee
Posted
Re: Not a bad list!
by
Ashok Guduru
Posted
Makes sense at a very high level but...
by
Sidu Ponnppa Chonira Kariappa
Posted
Re: Makes sense at a very high level but...
by
Tom Hollander
Posted
Probably too architect-centric, not very agile
by
Stefan Schubert
Posted
Re: Probably too architect-centric, not very agile
by
Paul Umbers
Posted
Re: Probably too architect-centric, not very agile
by
Dave Nicolette
Posted
Re: Probably too architect-centric, not very agile
by
Ashok Guduru
Posted
Re: Probably too architect-centric, not very agile
by
Erik van Ingen
Posted
Re: Probably too architect-centric, not very agile
by
William Martinez
Posted
Re: Probably too architect-centric, not very agile
by
Mehdi Khalili
Posted
Correct list
by
Adam Nemeth
Posted
I disagree with a number of points here
by
Ben Aston
Posted
I would Disagree.
by
Shaaf Shah
Posted
Addition to your list
by
XebiaLabs XebiaLabs
Posted
Re: Addition to your list
by
Abel Avram
Posted
Completly missed the difference in mindset
by
Per Lundholm
Posted
-
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
I disagree about the proposed amount of upfront-design, the just-in-time design meetings, the being-involved-everywhere and know-when-to-change-sth.
Why?
The team is responsible for design decisions, not the architect. Otherwise I would consider the architect to be an impediment as soon as he/she is not available for any reason. Furthermore the team usually has the product experts. It knows best how the product is connected to other products. I should know best and research technologies for the product. It should take responsibility for their product.
An architecture role in a team has to take a broader, higher-level view then the other team members (somebody with a qa role has a differerent view than a coder, too). He has to communicate to other architects to be able to connect views and such be able to evolve a bigger picture. This picture is important for the team to make critical decisions. So again he needs to communicate it.
I you really lay trust in your teams as you say, trust them to do your work as well. And just do those things on your own that do not fit in this one team.
A different thing is to say: But somebody in the team has to have the tech lead. Yeah, if you have no senior developers in your team, you can take on that role, too. But that has hardly something todo with the fact you're an architect.
The same goes for your team-shield thing. Even for your example, this is a Scrum Master responsibility. Yes you're right, the architect holds his stake here too. But only partly because of his higher pov. Most of that happes because architects like to get involved everywhere. I do, too :-) -
+ 1 -- Architects should write code.
-
The team is responsible for design decisions, not the architect.
I would disagree with this. The team may and should take part in the design but ultimately it is the architect who is RESPONSIBLE for those decisions, and quite often it is only the architect who has a high enough view of the project that they can make those decisions well. Where you have competing views from the team members it is also the architects role to play referee and make the final decision over which way to go. -
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 ....
I do agree that the word agile is sometimes misused. I do not agree with the suggestion that Hollander is misusing the word agile. From what I read in his article is that he has profound experience with agile. And I really like his article because the role of an architect in a team has not been discussed much in the agile world. He comes up with a lot of good advices. I am convinced that the role of an architect is needed (whether you call him architect or senior developer or not). -
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.
19 comments
Watch Thread Reply