When a disciplined agile project or product team starts one of the process goals which they will likely need to address is Identify Initial Technical Strategy. The idea is that the team should identify one or more architectural strategies which they believe are viable, based on their current understanding of the scope of the endeavor, and then choose one strategy to guide their initial construction efforts. The technical strategy is likely to evolve over time as the team learns throughout the project, but at the beginning of the project the team needs an initial direction in which to go.
This is an important goal for several reasons:
- You want to get going in the right direction. Your team needs to have at least a high level understanding of how they’re going to build (or configure) the solution, they just don’t start coding. This helps the team to avoid potential rework later in the lifecycle. It is critical in situations facing lots of technical complexity.
- You need to secure funding. In the vast majority of organizations, IT delivery teams are asked fundamental questions such as what are you trying to achieve, how long will it take, and how much will it cost. Having an understanding of your technical strategy is important input into answering those sorts of questions.
- You want to leverage organizational assets. Because disciplined agile teams are enterprise aware they work closely with enterprise professionals such as enterprise architects so that they can take advantage of any existing infrastructure, such as coding conventions, services, or data sources. They also want to ensure that their solution reflects the overall goals of their organization (often captured in technical or business roadmaps).
The process goal diagram for Identify Initial Technical Strategy is shown below. The rounded rectangle indicates the goal, the squared rectangles indicate process factors that you may need to consider, and the lists in the right hand column represent potential strategies or practices that you may choose to adopt to address those issues. The lists with an arrow to the left are ordered, indicating that in general the options at the top of the list are more preferable from an agile point of view than the options towards the bottom. The highlighted options (bolded and italicized) indicate default starting points for teams looking for a good place to start but who don’t want to invest a lot of time in process tailoring right now. Each of these practices/strategies has advantages and disadvantages, and none are perfect in all situations, which is why it is important to understand the options you have available to you.
Figure 1. Process goal diagram for Identify Initial Technical Strategy.
Let’s consider each process factor:
- Choose the level of detail. How much effort should you put into capturing your architectural strategy, if any at all. A small co-located team may find that a high-level overview captured using whiteboard sketches is sufficient. A team that is geographically distributed across several locations will find that it needs to at least take digital snapshots of the sketches and share them (perhaps via a wiki) or even capture the diagrams using a drawing tool such as Visio or OmniGraffle. They may also find that they need to define the details of the interfaces to major components and services, a strategy often referred to as design by contract. A team in a life-critical regulatory environment may choose to capture more details, even to the point of doing big design up front (BDUF).
- Explore technology architecture. Technical aspects of your architecture may be captured via free form layered architecture diagrams, network diagrams, or UML deployment diagrams amongst others.
- Explore business architecture. Business or domain aspects may be explored via conceptual domain models, high-level process models, and UML component diagrams amongst others.
- Explore user interface (UI) architecture. For end users, the UI is the system. The implication is that you had better architect it well, and more important ensure that it is usable/consumable. You may explore the user interface architecture via a UI flow diagram/wireframe model, low-fidelity UI prototypes, or high-fidelity UI prototypes.
- Consider the future. A critical thing is for your architecture to be able to accommodate change in the future. The lean strategy is to consider these changes, and make architectural choices that best enable you to accommodate the changes when and if you need to, but DO NOT overbuild your solution now. In short, think but wait to act. To do this you need to consider the potential changes that could occur, often via “what if” discussions. If you need to capture these potential changes you might decide to write change cases.
- Apply a modeling strategy(ies). How will your team go about formulating their architecture? Will they hold informal modeling sessions in an agile modeling space or formal modeling sessions Joint Application Design (JAD) strategy? Or both?
- Select an architecture strategy. Will they identify a single technical strategy or several options which they will hope to explore and eventually choose from (or combine ideas from)?
- Identify a delivery strategy. Will the team be building a solution from scratch? Will they be evolving an existing solution? Will they be evolving a purchased, commercial off the shelf (COTS) package? Combinations thereof?
I wanted to share two important observations about this goal. First, this goal, along with Explore Initial Scope, Coordinate Activities, and Move Closer to a Deployable Release seem to take the brunt of your process tailoring efforts when working at scale. It really does seem to be one of those Pareto situations where 20% addresses 80% of the work, more on this in a future blog posting. As you saw in the discussion of the process issues, the process tailoring decisions that you make regarding this goal will vary greatly based on the various scaling factors. Second, as with all process goal diagrams, the one above doesn’t provide an exhaustive list of options although it does provide a pretty good start.
I’m a firm believer that a team should tailor their strategy, including their team structure, their work environment, and their process, to reflect the situation that they find themselves in. When it comes to process tailoring, process goal diagrams not only help teams to identify the issues they need to consider they also summarize potential options available to them. Agile teams with a minimal bit of process guidance such as this are in a much better situation to tailor their approach that teams that are trying to figure it out on their own. The DA process decision framework provides this guidance.