Identifying the Initial Technical Strategy on Disciplined Agile Teams
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 issues or 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 issue:
- Level of detail. How detailed do your architectural artifacts need to be? Will a few whiteboard sketches be sufficient? Do you need a detailed, electronic model? Will a simple statement, such as “We’re adopting the existing architecture from the previous release”, be sufficient? Your team should strive to capture just enough detail for the situation they find themselves in (Agile Modeling refers to this as just barely good enough artifacts).
- View types. Most teams find that they need to capture several views of their architecture, and this will vary based on the type of solution you’re working on. For example, an e-commerce system would likely benefit from a view that explores user interface (UI) flow between pages, whereas this view would be inappropriate for an infrastructure solution such as a collection of reusable web services. However, both these solutions may be explored by a view that explores technical deployment concerns. In the process goal diagram we list three categories of view but this is not carved in stone. Various architecture frameworks, such as Zachman and TOGAF to name just two, suggest their own collection of views. The key issue is to address the views that are appropriate for the situation you find yourself in.
- Modeling strategy. How formal will your approach to modeling be? Will you have formal Joint Application Design (JAD) modeling sessions for example, or informal agile modeling sessions around a shared sketching tool such as a whiteboard or paper? Will you work on a single architectural strategy or several strategies in parallel (hopefully narrowing down to a single strategy later in the lifecycle)
- Delivery strategy. Although we often talk about development of a new solution for stakeholders, many teams find themselves in the situation that they are updating an existing solution. Some teams find themselves working with a Commercial Off-the-Shelf (COTS) package, either configuring it or even extending it (modifying the code).
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 DAD process decision framework provides this guidance.