|Insuring Architecture needs fit into an Agile Development Practice.|
There is a related question. When should architects and development teams target "good enough" solutions, ones that may introduce deliberate technical debt, versus others where it is worth the investment to "develop right the first time" and produce reusable, scalable solutions.
A disciplined agile practice using some of the techniques described in this blog on estimating story stubs and sizing stories does help provide a framework to make these architecture trade offs explicit business decisions.
Agile Practice Fundamentals
First, the team needs to be performing light weight estimates off of the desired features. This provides a mechanism for technical leads to define solutions before all the requirements are developed. The Business Analyst or Product Owner should participate in this process to create assumptions that will become business rules if they align with business needs.
Second, the team must be disciplined in itemizing technical debt in the backlog. Without this discipline, any compromises on architecture will be forgotten and teams may have a harder time getting fixes prioritized.
Then, there needs to be a second process of story writing and sizing. When stories are detailed, there is a second opportunity for the leads and architects to solution and resolve architecture gaps.
Finally, there needs to be participation from the Product Owner. They need to be able to provide a high level feature road map that goes out at least several sprints out. The process of breaking features down, estimating, story writing and sizing can't happen easily in the sprint prior to development. Once a feature is prioritized, it needs to go through these planning steps which can have variable efforts and duration depending on complexity. Product owners can still shift priorities, but they have more information on cost/complexity as a feature is planned.
Fitting in Architecture Needs into a Disciplined Agile Practice
- Governance - Does your product owner prioritize technical debt or architecture needs? Strong product owners realize the need to balance feature development and technology needs, but you may be working with product owner that doesn't show this discipline. It helps to define some governance such as defining a percent of velocity applied either per sprint or per release that need to dedicated to technical debt, stewardship, or architectural needs.
- Leverage the backlog - Architecture needs should be listed and prioritized in the backlog. This will force architects to sell their ideas or make business cases for them if these need to be developed and addressed.
- Estimate Multiple Scenarios - When features are estimated, consider estimating multiple solutions or development scenarios. In doing so, at least one scenario should represent the "good enough" solution, another that is architecturally "done right" and any number of hybrid or alternative scenarios. Leads and architects have to be judicious in selecting the number of scenarios because there is a cost to thinking through and estimating too many. Scenarios that are "good enough" should itemize potential technical debt and highlight risks/concerns while others that have better architecture should itemize potential benefits.
- Estimate Review Responsibility - Development organizations should decide who is on point for developing estimates and how scenarios and estimates will be reviewed. The specifics on how this is done will be different for each organization depending on its size (how many teams working together), how roles are defined, and the size/complexity of the feature requested. It's important that the person or team reviewing challenge assumptions and make sure that complete solutions are not missing details or are over-engineered. In organizations that have architects, they should own this responsibility.
- Develop architectural values and principles - What I've described here is very systematic and process driven, but may not work all the time for smaller teams on aggressive time schedules. Teams need some basic guidelines, values, or principles that will help them make appropriate architecture decisions without a lot of overhead. These can't be hard rules and should be defined with some flexibility. But it should help architects make quick decisions on how to implement something, or how not to implement. Some of my principles including balancing value, innovation and research and simple agile product development,
If you like this post, let me know and I will write a follow up.