The role of an Architect in Agile Part 2

What should an architect be responsible for?

An architect or team of architects should be responsible for: 

• Assisting in gathering and analysing requirements.
• Sell and negotiate technical constraints and aspects to stakeholders.
• Articulate the end goal architectural vision designed to encapsulate change.
• Communicate with diagrams the intended architecture and implementation plan.
• Prove (or disprove) technologies and techniques (prototyping).
• Own the definition of integration points and service interfaces.
• Establish processes to ensure predictable outcomes and quality in the SDLC.
• Oversee delivery of software in accordance with the intended architecture (reviews).
• Acceptable quality levels (coding standards, code metrics and performance parameters).

The architect is primarily responsible for creating a big picture of how a system should be assembled, integrated and where extension points are for probable business additions. This should include mostly diagrams, lists and pseudo-code, because developers don't read. The key is to keep it simple, just enough for the targeted team.

Controversially IDesign's "The Method" argues that the architect should also project manage. The explanation was simple, who else knows best how things integrate and their dependencies?

During implementation the job isn't done. Architecture is also governance of ensuring all these things have happened. An architect should oversee a feature from inception to implementation to final load and concurrency testing.  A Scrum team should only be working on one feature at a time (this is a founding principle of agile - focus and don't context switch).  This allows an architect to potentially oversee two features across two teams at the same time. Its also worth considering the architect joining the team as a development resource, if resources permit.

Any respectable Scrum coach will tell you that Scrum does not mandate no design. It simply states do what is required. If that means design can be done inside the same sprint as implementation, do it, although that is highly unlikely and I wouldn't advise it.  The best plan is to complete the necessary design work prior to initiating a stream of work with the Scrum team. The trick is don't do too much. Too much will vary depending on strength of experience in the team, and how effective they are at communicating. The more inexperienced the team the more design work needed.

Having architecture artifacts up front before starting a piece of work, and for grooming sessions, means it is highly visible and scrutised. This inevitably improves the design, and reduces unknowns.

Who's the boss?

Answer: The client. The Product Owner (PO) represents and speaks for the client. That is not to say the architect shouldn't have direct contact with the client, the PO is there to help you with this. Embracing change is the key to a successful software product. Often more valuable information comes to light during the project. Expect change. However, an inexperienced PO will change their mind more often than necessary. This can be addressed with a little more architecture work, this will keep the PO's reasoning honest. Any whiff of analysis paralysis means you either dump the feature/use-case or dumb it down and start the Scrum process with basic a implementation only. Unfortunately a PO that changes their mind too often results in poor qualilty software that costs more than it should to maintain or extend.

A good PO will work with their architect during the sprint review to ensure the quality metrics are adaquate and all agreed standards have been met.  Although the architect is technical, they are definitely in the Product Owner camp. The PO should lean on their architect for technical advice and verification of the product delivered.  The PO should fail the sprint if the architect can prove that the implementation doesn't comply with the design, or standards have not been met.

IDesign's "The Method" advocates the architect head up the project team and be the one to call the shots and sign-off the final product. This is a very tough sell to the establishment today, but it could be the future.

Some tips on how an architect can go about their job?

(Thanks to IDesign's Michael Montgomery for the inspiration for this list).

• Formalise and document your requirements gathering approach.
• Formalise document templates to store the gathered information. 
• Don't gather information using sticky notes! Save it digitally using defined consistent templates.
• No gold-plating. Everything is “just enough” based on known and likely use-cases, team composition, and hand-off-point.
• Iterate on everything, including requirements, getting “just enough” before the Design Phase begins. Gather - Refine - Review/Assess, Gather - Refine - Review/Assess, until your ready to start implementation.
• Continually reinforce to the BA's and PO's that they bring the ‘when, what, why, who’, but never the how.
• Developers don’t read. Format use cases as ‘pseudo-code’ (i.e. numbered/bulleted ‘lists’) and diagrams.
• Never use the term ‘spec’. Call it the ‘requirements lists’ or 'acceptance criteria'.
• With the advent of UX, separate functional (UX/UI) from back-end service operational (SOA) requirements lists. Treat back end services as a different product to a client UI. They will have their own lifetimes driven by the same use cases.
• UX is different from UI is different from SOA is different from Framework. Each may need its own requirements treatment, depending on the size and complexity of the system.
• Developers don’t do UX (although they may think they can - don't believe them).
• The UX guys must involve stakeholders early and often. This will need to be quite mature before implementation can begin.
• For user driven applications (which is most), it’s well-crafted UX workflows that produce clearly defined use cases that produce succinct SOA. If you can get the UX guys ‘out in front of the ball’, you put yourself in a sweet spot. This particularly holds true in composite UX.

Conclusion

Given a choice, I would prefer to use IDesign's "The Method". My problem with it has been convincing employers and stakeholders, even though it's a new approach, it's a proven one. Others with superhuman sales and negotiation skills may have more success than I. Working in with Scrum, its roles, and other established roles has been a given for me; and I'm betting you too. However, I believe this is completely realistic in a hybrid model. The role of an architect is absolutely essential, but the role and its skills are far more than a senior developer's.  An architect's number one skill, is their communication skills.  In my opinion as an industry we need to formalise roles, and the architect role is paramount and akin to the building industry's architect in responsibility but more similar to a head-chef in activities.

References and more information

Scott Ambler on User Stories
Scott Ambler on Architecture in Agile
IDesign.Net
http://www.idesign.net/articles/agile_and_the_architect.htm
Able Architecture Part 1: 
Able Architecture Part 2: