21

Agile focuses on developing workable codes from small user stories. Pair programming encourage developers to pair up, actively engage with one another to come up with the best solution for the problem. Design and code are actively reviewed, refined, until it reaches a state where everyone is confident that the software is maintainable and robust for the customers.

Agile transforms the command and control mechanism, where architects dictate what the design should be, into a democratic process that gives everyone the autonomy for designing the system. This leads to the question, is a software architect still relevant in Agile? Does Agile slowly transform the role of an architect into something else?

| improve this question | |
  • While this is an interesting question with some good answers, it isn't really framed from a project management perspective--although there's a great team-composition issue buried in there somewhere. Voting to close, because editing the question heavily would invalidate too many thoughtful answers. – Todd A. Jacobs♦ Jan 15 '13 at 16:27
7

Great question and definitely something that doesn't seem to be addressed very well in the standard material that is out there. I won't pretend to have all the answers as we are still struggling with this ourselves, but there is definitely still the need for an architect role in an agile environment. It is almost definitely different than the typical role in a more waterfall approach, but still there. It seems that, in an agile environment, the architect role gets much more involved in the backlog grooming portion. They are a prime candidate to do rapid prototyping and other research to help with breaking large user stories down into smaller ones that will fit into a sprint. Being a product owner, there are many times that I have a user story that is too large to fit into a sprint but isn't clear from a business perspective how to break it down. This is where it seems to be very beneficial to get the delivery team involved to help. During team backlog grooming meetings there will be discussion about potential ways to approach the problem and many times more research on these alternatives or some prototyping will need to be performed before a decision can be made. This seems to be where the architect role fits best in agile.

In a multi-team environment where there is a lot of shared code, this could be enough load to warrant a dedicated architect working with the product owner team to help provide this sort of feedback ensuring consistency across the teams. In any case, as always, the goal of the prototyping and research is to gain just enough knowledge to be able to make a decision and move forward. Any code from that effort should be discarded and the knowledge shared in another way. This could be some light weight documentation, it could be some simple diagrams, it could simply be a conversation. Generally speaking, if it was complicated enough to warrant the research, it is probably complicated enough to warrant some level of documentation, as long as that isn't used as a hand-off and accompanies a discussion.

| improve this answer | |
  • 2
    Agile is about doing something minimal that can work, so it does make sense for asking the architect to do rapid prototyping instead of creating thick design documents that may not work. Thank you for the answer =) – zfranciscus Jun 14 '11 at 7:03
4

Yes, architecture is vital and Yes to your entire - and very well stated - second paragraph, it changes the relationships and the role.

When a software architect tries to pull rank or maintain status over a good agile team, the team gets frustrated, even annoyed. The architect may feel threatened by the team wanting to do architecture, not have it thrown over the wall to them. They may be more capable than he. One way forwards is for the architect to trust that better architectures really will emerge from a team effort and do architecture with the team. Her/his role then moves more to consultancy than delivery of architecture.

  • Concerning the technical architecture

All systems have architecture. The tools, frameworks and previous projects may do 80% of the architecture without you realising, but ignorance is not bliss. Rapid, agile delivery is sustainable not just for a few sprints but over months even years if and only if the right kind of architecture underpins the design.

Systems don't get rewritten because of failing functionally. They are rewritten because of failure in the software qualities (NFRs) - performance or security or maintainability or other." In other words, because of architectural failure. (I think the quote's from Bass, Clements,Kazman, "Software Architecture in Practise").

  • How should architecture evolve in the light of Agile?

is still an open and lengthy question. Here are 3 people's efforts:

  1. http://www.slideshare.net/makabee/aduf-adaptable-design-up-front

  2. https://leanpub.com/software-architecture-for-developers

  3. http://www.slideshare.net/ChrisCarroll2/presentations (mine)

| improve this answer | |
  • Slideshare is good for this - browsing round slideshare for agile architecture will pretty much give you the 'state of the art' at the moment – Chris F Carroll Oct 17 '13 at 17:08
2

I think Software Architecture involves planning the Components working together. Agile projects need planing too, without this I can't see a successful end.

I think in Agile way, this planning doesn't need to generate excessive documents. But planning the architecture is still necessary.

| improve this answer | |
1

The question, I believe, is really two fold. How does the concept of architecture fit into agile and is there a need for a dedicated or assigned role to perform the work.

I strongly believe that for complex projects, architecture planning and definition is critical for long term success. There are cross functional aspects, like performance, that are difficult to add afterwards in an iterative fashion with a sprint by sprint only view.

The role of architect seems to vary company to company, but common responsibilities are usually much deeper than defining the architecture of a single project. They insure best practices are being followed, consistency between projects, insuring a project fits within the bigger picture within an organization and so forth.

So does an architect need to exist ? Depends on your company/business. If you have a complex infrastructure with a lot of projects that need to coexist and be supported over the long term, an architect or architectural team is probably needed. If you are a small company with a limited number of development projects, maybe there is much less of a need.

Just like any other specialty skill on a team, is there enough work to justify a dedicated resource or just spread out the work and live without the focus of a specialist.

| improve this answer | |
0

I think this could also be phrased as "does design fit into Agile?"

As you develop a product, the architecture, design and implementation change each release. How much depends on the needs of the project and the ability of the team to understand the scope of the overall solution. You only build an architectural component or change the design based on needs, not "what ifs" So, while you may have planned to have an abstracted, data driven business rule component as part of your architecture, you don't build it till you need it. That way, if the scope changes, or not adding that in provides enough value to ship, then you have the option to ship.

In my experience, Agile project benefit -much- more from having strong, very experienced architects as part of the project so they can make more informed decisions about "when" things are needed and "what can be cut to make things simpler but still functional" Also, having developers with strong inherent design skills and experience can work with the uncertainty around the changing and ever morphing design in an Agile project.

Having a "single architect" make the decision drops away. Some teams discuss "is this needed yet" and having some experienced folks provide context and some inexperienced folks to challenge implicit assumptions seems to provide a good mix.

So, I don't think it transforms SW Architecture as a discipline or a practice :-)

| improve this answer | |
0

I believe that design is still essential, regardless of the mechanism used to deliver the solution. There must be boundaries, especially in terms of defining the extent of a solution, and particularly around interfaces, integration, and simply avoiding straying into the space that other projects are attempting to cover - otherwise a strong PM / product manager could take the development in a direction that is completely wrong for the organisation or enterprise that is needing the solution.

A simple example may clarify what I mean. Consider a company that has a well designed, integrated, management reporting system based on a recognised tool, that works with industry standard databases. Within that company there is a small development that uses a different database, different data standards, and duplicates some of the functionality of other enterprise applications (including some management information). Not a problem... for the project team. But it is a problem for the organisation, as it now has multiple versions of the "truth", and no-one knows for sure which one is right, because they will never be perfectly aligned. Why has this happened? - because there was no-one validating the design or setting parameters for the developers to remain within.

So yes, software architecture is very relevant in Agile, especially in integrated, complex, enterprise-sized environments. But I would also argue for proper design in any development, as there is always merit in keeping at least one eye on the prize that you're shooting for, as well as creating the code for your next iteration.

| improve this answer | |

Not the answer you're looking for? Browse other questions tagged or ask your own question.