Let’s say you start an agile project. You identify the requirements, write them down as user stories, define your releases, setup the infrastructure. Are you ready to start sprinting?
Before we can answer, let’s try adding in more context. I see two different situations:
1. You have one team that will build an application starting from scratch
2. You have five teams who start to work in parallel. The application integrates with ten different existing applications
In the first case, you can usually start immediately. Only rarely have you to consider things like: increased performance in parts of the system or increased security that requires special coding guidelines. Experienced developers will take these into consideration naturally, without someone telling them. If developers pair, guidelines will emerge from this interaction. Components will emerge by extracting common parts of the code into separate libraries or services. Problem solved.
In the second case, you are facing different challenges. Every decision that involves more than two teams can take forever. Decisions made by one team might not be ideal for the whole system. Ideally, everyone will know the whole system and can decide for it, but we know that is not happening in reality. No matter if you structure your teams as feature teams or component team, you will have some long conversations for certain types of decisions. You have to answer more questions. How do you keep consistency in code? How do you ensure performance, security, availability, scalability? Some decisions need to be made that affect more than a sprint and more than a team.
There is more. Often during a longer project with multiple teams, you have to balance short term with long term needs. Should we spend one more day to extract one service now, or should we wait until we find that the user facing application has low availability due to that service? We knew we need high availability for the application for months, how comes we could not we see that extracting the service is important? Or is it more important to deliver? Can the Product Owners (we have multiple teams, so probably multiple POs) make this decision? How? Or should we leave this decision to one team? All the teams?
Depending who you ask these questions, you will get different answers. Some XP practitioners say that architecture will emerge. Scrum says you need to figure it out. Kanban builds upon an existing system, so it is again up to you to find solutions. None of these answers is satisfying.
If you ask experienced software architects, such as Rebecca Wirfs-Brock or Simon Brown, they will tell you that you need to think ahead. One of my conversations with Rebecca inspired her to write an excellent blog post that you might find interesting in this debate.
My experience has shown that we need to think ahead. Like any plan, the initial architecture will change but it is important to have something to change. When I start developing a product for a customer, I believe my job is to make a few decisions that will help with three important things:
- Manage risks
- Reduce costs
- Help development to go smooth
I go through an analysis process that lasts between two hours and two days:
- Identify the actors of the system
- Learn more about the actors: what do they need to do? Who will they interact with?
- Identify risks. Start with the scalability, availability, security and performance risks. Then find what can go wrong in the real world that can break or stretch the system. Define appropriate responses in the form of landing zones.
- Break the system into components, services and applications so that the risks are taken into account. Do not go into technical details, like what library, framework or server will be used.
- Identify the assumptions.
- Review and fix errors. Check the assumptions with the customer.
- Choose appropriate technologies (programming language, database server, message queuing system etc.). If we have multiple options (relational database or NoSQL? Java or Microsoft? Oracle or MySql?), decide how to choose between them. You can and should defer all decisions that do not have an immediate impact. If I can start developing without a database, or change it later on without problems, I will start coding. But someone needs to take the necessary steps to make the choice, and it has to go in the backlog.
- Ask what we do not know. How can we find out? Another few items in the backlog.
- Create the walking skeleton.
- Start coding and designing using TDD/BDD
It is worth repeating that you do not need to do these steps, except maybe identifying risks, if you are building a simple mobile or web app with a five people team. But if you have ever worked in an environment where 30 different teams build a product together using Scrum and the product has to work with existing services, protocols and devices, you will see the value in doing more upfront work. (By the way, I did work with four teams out of the 30 described above, and software architects were very important for the development).
Once we start coding, I always keep an eye on the architecture. I have learned from Marty Cagan’s book on product management (he is the former eBay product manager and has worked with agile teams), that three voices are important for the success of any product, before and during the development:
- One speaks for the business
- One speaks for the users
- One speaks for the architecture
I did my best to expose developers to these ideas in the past month, by running three “Architectural Kata” sessions in UK, at SoCraTes UK, at the Cambridge Software Craft Community and at the London Software Craft Community. The attendance and feedback was overwhelmingly good. I am waiting now to see what they took into their daily work and how it influenced their thinking. Agile and Lean Software Development need software architecture. We do not need ivory tower architects, but hands-on practitioners able to have meaningful conversations inside teams working in complex contexts. We have many more questions to answer, but we would not learn more unless developers understand what architecture is about, practice it and take ideas to their work.
If you want to learn more, here is other blog post about architectural kata.
If you need improving your knowledge about Agile Architecture, we can help with:
- An assessment on your organizational practices
- Attending our Refactoring workshop, also available in-company
- Attending our “Agile Architecture: An Incremental Approach workshop with Rebecca Wirfs-Brock
- Attending our User Stories for Agile Requirements workshop, also available in-company
Want to learn something else? Let me know and we will create a customized package for your needs.
