On August 8th I facilitated a workshop at Agile 2018 that focused on agile architecture. I promised everyone, we had over 150 people in the workshop, that I would post the pictures of their strategy canvases online so that they could have copies of it. So here’s my promised blog!
How architecture fits into agile ways of working (WoW) has been an important topic from the very beginning. As with all other aspects of agile, the Disciplined Agile (DA) toolkit provides you with choices – because every team is unique and faces a unique situation, they need to choose their WoW to reflect this (we like to say that context counts). To enable teams to effectively choose their WoW they need to know what choices they have available to them (we also believe that choice is good) and what the trade-offs of those choices are (because there’s no such thing as a best practice).
So in this workshop we worked through twelve agile architecture strategies. Granted, there’s a lot more than this, but we only had 75 minutes so I lead everyone through some of the key strategies. This blog overviews each strategy and then shares the strategy canvases that the class developed. Our approach was to assign each strategy to several tables and then ask each group to discuss the advantages of the strategy, the disadvantages, and when you would use it. There are pictures below of each strategy canvas – it’s important to note that I don’t agree with all of the sticky notes, but for the most part it’s solid stuff. Our upcoming book, trending to arrive in October 2018, explores these strategies (and more).
During the workshop we explored three fundamental questions:
How Do You Explore Your Initial Architecture Strategy?
Each group was given one of three initial architecture strategies to discuss:
At the beginning of our project/endeavor we will perform no architecture modeling or exploration at all. We believe that all aspects of the architecture will emerge over time during Construction.
At the beginning of our project/endeavor we will invest a bit of time, potentially several hours or even a few days, to perform some lightweight agile architecture modeling. We believe that we should think through the high-level architectural issues now but that the design details will emerge over time. Our “models” will be created using inclusive modeling tools such as whiteboards, paper or sticky notes. We’re likely to create one or more high-level sketches, each of which explores an architectural view (such as the technical architecture, the data architecture, the communications architecture, and so on).
At the beginning of our project/endeavor we will invest a fair bit of time, potentially several weeks or even a few months, to work through the architecture of our solution. We believe that we need to think through most, if not all, aspects of the architecture in detail before we can safely proceed with Construction. Our models may be either visual (i.e. UML component diagrams, Free-form architecture diagrams, Data Models, …) or textual (e.g. white papers) in nature. Our visual models will be supported by sufficient documentation to capture the details overviewed by the diagrams. Our models will be captured with software-based diagramming tools (e.g. Visio, OmniGraffle), documentation tools (e.g. Word processors or Wikis), or modeling tools (e.g. Enterprise Architect).
How Do You Bring Architecture Skills Into the Team?
Each group was given one of five architecture skills/roles strategies to explore:
On our project/endeavor we do not have anyone on the team responsible for architecture work nor do we have anyone with sufficient architecture skills to do so. Luckily we are a group of smart, experienced developers and we believe that we will be able to evolve the architecture of our solution through teamwork and experimentation.
On our project/endeavor we have someone on our team acting as a part-time architect. This person is very experienced and is a member of our corporate architecture team, supporting several solution delivery teams including our own. The part-time architect guides our team in architecture decisions, providing advice, educating us in any existing corporate architecture guidance, and reviewing any work that we do on our own.
On our project/endeavor we have someone with deep architecture experience and skills. In the past they were a developer but over time they worked their way out of that role to become an architect. Their job is to work through the architectural strategy for the team, describe that architecture strategy to us, and develop and maintain sufficient architecture models and documentation throughout the lifecycle. Although they are technically adept and well versed in the domain, they do not have technical experience with some of the platforms and technologies that the team is likely to work with.
On our project/endeavor we have someone who is a full-time member of our team who has deep architecture experience as well as development skills. They are responsible for formulating the architecture strategy for the team although will often work with other team members to get their input into architecture decisions. When they are not doing architecture work they are an active developer on the team.
On our project/endeavor we have someone in the role of Architecture Owner (AO). This is a full-time team member who has architecture experience, is well versed in our corporate architecture guidance/strategies, and also has development skills. The AO:
How Do You Evolve Your Architecture?
Each group was given one of four architecture evolution strategies to explore:
One of the approaches that our team uses to evolve our architecture is refer to our organization’s existing architectural guidance. We typically do this by talking with someone on our team familiar with that guidance, such as an Architecture Owner (AO). This person may decide to look up the current version of the architecture guidance as needed (hopefully this is captured in an agile, lightweight manner). Such architecture guidance may include:
One of the approaches that our team uses to evolve our architecture is to run architecture spikes (or simply called spikes). Whenever we run into an architectural issue, such as how a technology works within our environment or how a combination of technologies work together, we write a bit of code to explore the issue. This is typically throwaway prototyping code because we want to quickly experiment to gather sufficient data to make a better-informed decision. Spikes typically take a few hours to a few days. A spike can be thought of as a very small proof of concept (PoC).
One of the approaches that our team uses to evolve our architecture is to develop a walking skeleton, also known as a working skeleton or steel frame, of our solution early in Construction. We do this by focusing on a small collection of requirements early in the lifecycle that implement sufficient functionality to address our highest-risk items so as to show that our architectural strategy works in practice. Once the walking skeleton is in place we spend the rest of Construction putting the functional flesh onto it.
Just-in-time (JIT) Model Storming
One of the approaches that our team uses to evolve our architecture is to explore requirement and design details at the last most responsible moment. We do this via light-weight agile modeling (sketching, sticky notes, …). Model storming sessions are often impromptu and last for several minutes, often starting with a request along the lines of “Hey, can you help me work through this…”.
After the workshop I received a lot of great feedback from attendees. It really resonated with people and seemed to provide them with a lot of value. I was glad to hear that. So, in the spirit of blatant self promotion, I wanted to let people know that the Disciplined Agile Consortium offers training in Agile Architecture, including:
Furthermore, feel free to reach out to me at Disciplined-Agile.com if you’d like some help bringing agile architecture or more broadly Disciplined Agile (DA) strategies into your organization.
Reuse engineering is an important, and arguably advanced, aspect of the Disciplined Agile toolkit. The challenge is that reuse engineering requires significant discipline and organizational maturity to be successful, hence we tend to run into far more talk about reuse than action. Having said that, many organizations have been very successful with reuse. The following diagram overviews the internal workflow of a reuse engineering team, capturing key activities (the blue bubbles) that the team performs. This blog posting explores what reuse engineers do in practice.
Let’s work through the primary activities performed by reuse engineers:
If your organization is serious about reuse engineering then they will explicitly fund a reuse engineering team and enable them to work in the manner that we’ve described here. For more information, you will find the article Reuse Engineering to be of value.
The basic idea with rolling wave planning is that you plan things that are near in time to you in detail and things that are distant in time at a higher level. The thinking is that the longer away in time that something is the greater the chance that it will change during that time, therefore any investment in thinking through the details is likely wasted. You still want to plan at a high level to both guide your current decisions and to set people’s expectations as to what is likely to come.
Rolling wave planning is implemented in several places of the DA toolkit. First, as you can see in Figure 1 below, it is an option of the Level of Detail decision point of the Develop Initial Release Plan process goal. A rolling wave approach to release planning has the advantages of more accurate and flexible planning although can be a bit disconcerting to traditional managers who are used to annual planning strategies.
Figure 1. The Develop Initial Release Plan goal diagram.
The Portfolio Management process blade supports rolling wave budgeting as an option for its Manage the Budget decision point. This is depicted in Figure 2. The advantages are greater flexibility and greater likelihood of investing your IT funding more effectively, albeit at the loss of the false predictability provided by an annual budgeting strategy.
Figure 2. The goal diagram for the Portfolio Management process blade.
The Program Management process blade supports rolling wave planning of a program itself, as you seen in Figure 3. Planning and coordination are critical on a large program, and rolling wave planning offers the advantages greater flexibility, the ability to think important cross-team issues through, and the ability to react to changing stakeholder needs. The primary disadvantage is that it can be disconcerting for traditionalists who are used to thinking every thing through from the beginning.
Figure 3. The goal diagram for the Program Management process blade.
As you can see in Figure 4, rolling wave strategies can be applied in Product Management to evolve the business vision/roadmap. A continuous, rolling wave approach is critical to your success because the market place changes so quickly – these days, few organizations can tolerate an annual approach to business planning and in the case of companies with external customers an ad-hoc approach can prove to be too unpredictable for them.
Figure 4. The goal diagram for the Product Management process blade.
Previously we saw that rolling wave strategies can be applied to evolve your technology roadmap, as indicated in the goal diagram for Enterprise Architecture in Figure 5. The advantages of this approach are that your roadmap evolved in sync with both changes in technology and with your organization’s rate of experimentation and learning. The main disadvantage is that your technology roadmap is effectively a moving target.
Figure 5. The goal diagram for the Enterprise Architecture process blade.
As you can see, rolling wave strategies are an integral part of the Disciplined Agile (DA) toolkit. In fact, in most situations they prove to be the most effective and flexible strategies available to you. The advantages of rolling wave planning tend to greatly outweigh the disadvantages. More on this next time.
For a long time now we’ve been applying what’s often called rolling wave planning with our clients. Rolling wave planning is applied in several areas of the Disciplined Agile (DA) toolkit, including release planning by a delivery team, technology roadmapping, and product roadmapping to name a few. This article explores how to apply rolling wave planning in a pragmatic manner to technology roadmaps.
An important aspect of your enterprise architecture efforts is to provide architectural guidance, both business and technical guidance, to your organization. One of the key artifacts that enterprise architects will create is a technology roadmap that, as the name suggests, provides guidance as to the proper application of technologies within your organization. This roadmap will often supplement any “as is” and “to be” models that the enterprise architects create.
Technology roadmaps are often evolved following a rolling wave planning approach. Figure 1 depicts an example of a technology roadmap, the goal of which is to give technical direction to solution delivery teams so as to provide safety rails around technical experimentation.
Figure 1. A technology roadmap in September 2016.
Notice how this roadmap addresses several categories of technical issues:
What Should the Planning Horizon Be?
Technology roadmapping tends to have between a six month and three year planning horizon depending on what is being planned for. For example, experiments are typically planned out a few months in advance as they are often driven by the needs of development teams. Major upgrades are typically planned on a horizon of six months to a year as this reflects the rate of change of many technologies. Retirements might typically planned for years in advance, particularly when the retirement could impact multiple systems.
How to Capture Technology Roadmaps
Technology roadmaps are typically captured in text format as you see in Figure 1 above, although a timeline format (as we say with product roadmaps) are often used for executive presentations.
This sort of planning is only one of several things that your enterprise architecture team will do of course. In addition to actively guiding development teams and working with senior stakeholders, the enterprise architects are also maintaining current and to-be models and are hopefully producing code examples for how to work with new architectural components.
For a long time now we’ve been applying what’s often called rolling wave planning with our clients. Rolling wave planning is applied in several areas of the Disciplined Agile (DA) toolkit, including release planning by a delivery team, technology roadmapping, and product roadmapping to name a few. This blog overviews this important practice.
The basic idea is that you plan things that are near in time to you in detail and things that are distant in time at a higher level. The thinking is that the longer away in time that something is the greater the chance that it will change during that time, therefore any investment in thinking through the details is likely wasted. You still want to plan at a high level to both guide your current decisions and to set people’s expectations as to what is likely to come.
In Figure 1 below you see an overview of how rolling wave planning works and in Figure 2 an example of how a Disciplined Agile Delivery (DAD) team applies it for release planning. Upcoming work is planned in detail, the planning unit “X” is one month in the case of the delivery team. In order to do their work they need detailed user stories and supporting artifacts such as acceptance criteria and supporting models such as user interface (UI) sketches or data source analysis. They have this information for the work that they are doing right now as well as about one month’s of upcoming work. They don’t yet need details for work that is several months away in time. In this case for work that is two to three months in the future they only have user stories developed and work that is four to six months away epics. Work in what the team considers to be the distant future, in this case six or more months away, is described in very high-level terms such as epics or solution capabilities.
Figure 1. Rolling wave planning overview.
Figure 2. Rolling wave release planning on a solution delivery team.
Part of the work that the team is doing right now is to keep their plan up to date. For example, if they are working in two week iterations they will pull two weeks of work into the team. During the current iteration they will pull about two weeks of user stories from the near term category (the yellow box in Figure 2) into the very near term (the green box). They may also bring upcoming work into the near term category at this point too.
Rolling wave planning has its source in iterative software development such as the Rational Unified Process (RUP). It is a strategy that is commonly applied by agile software teams and the Project Management Institute (PMI)’s Project Management Book of Knowledge (PMBoK) supports it.
In future blog postings in this series we will work through examples of applying rolling wave planning in practice.