Disciplined Agile

A Disciplined Agile Enterprise (DAE) is able to sense and respond swiftly to changes in the marketplace. It does this through an organizational culture and structure that facilitates change within the context of the situation that it faces. Such organizations require a learning mindset in the mainstream business and underlying lean and agile processes to drive innovation.

The DAE layer is one of the four layers of the Disciplined Agile (DA) tool kit, overviewed in Figure 1.  These layers are: Foundation, Disciplined DevOps, Value Streams, and Disciplined Agile Enterprise (DAE).  This blog focuses on the DAE layer.

Figure 1. The layers of the DA tool kit.

The Disciplined Agile Enterprise (DAE) layer encompasses the capabilities required to guide your organization, to coordinate the teams/groups within your organization, and to support the value streams offered by it.  Figure 2 summarizes the DA tool kit and Figure 3 overviews the process blades that are specific to the DAE layer.  Several process blades of the DAE layer - Research & Development, Business Operations, Strategy, Governance, Marketing, Continuous Improvement, and Sales  - are shared with the value streams layer. The are "shared" in that the scope of these process blades may focus on both the entire organization and specifically on individual value streams.  For example, a financial institution may execute an organization-wide marketing strategy as well as specific strategies for their retail and corporate value streams.

Figure 2. The Disciplined Agile (DA) tool kit.

Figure 3. The process blades specific to the DAE layer.

Expanding upon the value streams layer, the DAE layer adds the following blades:

• Asset management
• Enterprise architecture
• Finance
• Information technology
• Legal
• People management
• Transformation
• Vendor management

Asset management

The asset management process blade addresses the purposeful creation (or rescue), management, support, and governance of organizational assets.  This includes financial, inventory, contractual, risk management, and strategic decisions of these organizational assets. 

Enterprise architecture

The enterprise architecture (EA) process blade overviews how a Disciplined Agile EA team will work. An agile enterprise architecture is flexible, easily extended, and easily evolved collection of structures and processes upon which your organization is built. The act of agile enterprise architecture is the collaborative and evolutionary exploration and potential capture of an organization’s architectural ecosystem in a context-sensitive manner. The implications are that enterprise architects must be willing to work in a collaborative and flexible manner and that delivery teams must be willing to work closely with enterprise architects.

Finance

The finance process blade addresses a collection of potentially competing goals, such as ensuring cash flow within your organization, ensuring your money is being spent well, taxes are minimized, spending is properly tracked and recorded, and legal financial reporting is being performed properly. All of this will be performed in a manner that is compliant with applicable financial regulations, such as Financial Accounting Standards Board (FASB) and International Accounting Standards Board (IASB) guidelines.

Information technology

The information technology (IT) process blade encapsulates the activities required to provide IT capabilities to the rest of the organization.  This includes managing information technologies, data resources, applications, and IT infrastructure.

Legal

The aim of the Legal process blade is to ensure that your organization works within the parameters of the law of any and all legal territories in which you operate. Your legal team will work closely with your vendor management people on (Agile) contracts; with your people management team to ensure that their strategies reflect the local statutes and to help educate staff in legal concerns; with your marketing team to guide what they’re legally able to promise; with your strategy team to ensure the direction they're taking the organization is legally viable; and with governance to understand the legal implications of applicable regulations.

People management

The aim of the people management process blade is to attract and retain great people who work on awesome teams.  People management goes by many names, including human resource (HR) management, human relations (HR) management, talent management, staff management, people operations, and work force management to name a few. This process blade addresses strategies for forming teams; helping people to manage their careers; training, coaching, and educating people; human resource planning within your organization; managing movement of people within your organization; reward structures; and governing people management efforts.

Transformation

The transformation process blade captures advice for how to redefine, and then reengineer, your organization.  This includes understand the current context, identifying the desired future, identifying how to measure the success of the transformation, identifying a likely strategy for moving towards the desired state, and then executing on that strategy.  Throughout a transformation you will constantly gauge your progress and the desired target state and adjust according.  This process blade leverages the advice of PMI's Brightline Initiative.

Vendor management

The aim of the vendor management process blade, sometimes called supplier management, is to help obtain and then manage offerings (products, services, and intellectual property) from other organizations. To do this your vendor management team will collaborate with other parts of the organization to help them understand their needs (if any), identify potential vendors that can fulfill those needs, work with legal to develop appropriate contracts, address vendor-related risks, help monitor and manage vendors, and eventually close out any contracts. 

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:

1. How Do You Explore Your Initial Architecture Strategy?
2. How Do You Bring Architecture Skills Into the Team?
3. How Do You Evolve Your Architecture?

How Do You Explore Your Initial Architecture Strategy?

Each group was given one of three initial architecture strategies to discuss:

1. No modeling
2. Lightweight modeling
3. Heavy modeling

No modeling

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.

Lightweight modeling

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).

Heavy modeling

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:

1. No architect
2. Part-time architect
3. Modeler architect
4. Developer architect
5. Architecture owner

No architect

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.

Part-time architect

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.

Modeler architect

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. 

Developer architect

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.

Architecture owner

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:

• Guides/facilitates the team through architectural strategy and related work
• Mentors/coaches team members in architecture thinking and skills
• Work with our corporate architecture team as needed to ensure that our team is following, to the extent appropriate, the overall architectural vision
• Is an active developer on the team when they are not performing their other responsibilities

How Do You Evolve Your Architecture?

Each group was given one of four architecture evolution strategies to explore:

1. Architectural Guidance
2. Architecture Spikes
3. Walking Skeletons
4. Just-in-time (JIT) Model Storming

Architectural Guidance

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:

• Technologies we’re moving towards
• Technologies we’re moving away from
• Technologies that we mustn’t use
• Previously identified architecture experiments to run (important in multi-team environments to coordinate learning efforts)
• Results from architecture spikes performed by other teams

Architecture Spikes

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).

Walking Skeletons

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…”.

Parting Thoughts

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.  

Further Reading

• Architecture Owner
• Identify Initial Architecture Strategy
• Enterprise Architecture
• Agile Architecture Strategies

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:

1. Guide teams in reuse.  An important activity for reuse engineers is to provide guidance to delivery teams regarding what is available for reuse, how to go about accessing and applying the reusable artifacts, and educating teams in why reuse is important to both the team and to your organization.   Very often a team’s architecture owner will collaborate with the reuse engineering team to bring a reuse engineer into the team at the right time.
2. Obtain assets.  Reuse engineers will obtain reusable assets from a variety of sources, including from the marketplace and from internal delivery teams.  Based on the various organizational roadmaps, and the needs of the delivery teams that they’re working with, the reuse engineering team will often work with delivery teams to identify and obtain the appropriate assets from the marketplace.  The goal is to find assets that fit the needs of individual teams in a way that aligns with the direction of the organization.  Furthermore, reuse engineers tend to monitor what delivery teams are doing, often by working closely with the organization’s enterprise architecture team and the architecture owners on delivery teams, to help them identify potentially reusable assets.  When a team believes it has built something that is potentially reusable by others, or when the reuse engineers believe they have done so, then the reuse engineers will work with the team to understand and harvest that asset.
3. Publish reusable assets.  An asset is potentially reusable when it is of high quality, it is appropriately documented, one or more examples exist of how to use it, and it is findable by others.  The publishing process ensures that all of these criteria are true.  The reuse engineers will do the work to publish the asset, refactoring and documenting it as needed and harvesting any usage examples if available (and creating some when not).  After doing so, they will save the asset and its related supporting artifacts into your organization’s reuse repository, announcing the availability of the new asset after doing so. Note that reuse repositories, also called asset managers, have fallen out of favor in the past few years due to the complexity of the available products on the market and the propensity of organizations to use products like Git or Microsoft SharePoint as repositories.
4. Configure asset for specific use.  Reuse engineers will often work with a team to help them to configure an asset for specific use.  The goal is to make it as easy as possible for others to reuse existing assets, thereby increasing the chance of rate of successful reuse within your organization.
5. Integrate reusable assets into a solution.  Reuse engineers will often work with delivery teams to integrate a reusable asset into their solution, once again to make it as easy as possible for teams to reuse existing assets.  Interestingly, an important aspect of harvesting an asset for reuse is to help the source team to integrate the improved version of the asset back into their solution.  This helps to increase the likelihood that teams will offer up potential assets for harvesting and publishing.
6. Evolve reusable assets.  Assets need to evolve over time to reflect changing requirements and implementation technologies.  The implication is that the owners of the assets, often the reuse engineering team, will need to evolve their assets, publish new versions, and deprecate old versions.  This is work that must be funded and supported properly.

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:

1. Planned upgrades. Development teams need to know what aspects of your infrastructure will be evolving and when. Upgrades that are soon to occur have been assigned dates as these changes are very likely going to impact several development teams.
2. Experiments. From an agile point of view the most interesting thing is the list of experiments that the enterprise architects are overseeing. These experiments usually occur within one or more of the development teams underway in this company. In this case the EAs are coordinating and guiding the experiments, ensuring that the teams focus on experiments that reflect the overall direction of the organization. In some cases you may choose to have an explicit proof of concept (PoC) project to validate a new technology, a common approach for major infrastructure components or expensive packages. Either way, by planning for explicit experimentation you bring greater discipline to your learning and architectural evolution efforts.
3. Reusable infrastructure. This company has a reuse engineering effort underway where common architectural components, in this case microservices, are built and then made available to development teams. Once again, the closer to being released the reusable components are the more likely it is to have a target date for their release.
4. Retirements. An aspect of technology roadmaps that are often forgotten are the plan to retire existing systems and infrastructure components. An important part of paying down technical debt within organizations is the consolidation of your IT infrastructure – reducing the number of technologies that you’re using, removing redundant systems, and so on. Such retirement efforts can take months and even years. We see in Figure 1 that SQLServer is currently being retired from service, development teams are migrating to approved database technologies, and that it is slated to be completed by February 5^th. In this case the enterprise license for SQLServer ends in April 2017 so they’re hoping to be completely off of it two months before that.

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.