• It describes options for how you can ensure your release was, in fact, successful.

To effectively deploy your solution, you should consider several important questions:
• To what extent will you automate the deployment process?
• What strategy will you follow to release into production (this time)?
• What activities must you perform to release your solution?
• How will you validate that the release was successful

56
Lesson 8. Tailoring Your Practices: Ongoing
Description
As DASMs, we know the value of planning in helping our teams to be effective. This lesson
will help you gain a better understanding of planning and show you effective methods for
doing so. With planning knowledge and tools, you can deal with unexpected problems your
teams may encounter on the journey toward Disciplined Agility.

Objectives
Describe the Ongoing phase and why it is important.
• Define Ongoing phase
• Identify process goals associated with the Ongoing phase
Discuss how to use the DA tool kit to tailor your way of working within a select phase according
to context
• Rank and select process goals according to their relevance to the phase and the team’s
context
• Identify key practices for the team try using goal diagrams
Explain how to Learn Pragmatically (Lean principle)
• Define “standard work” and its use as a baseline for continuous improvement
• Explain the benefits of explicit workflow
• Describe how to use Kaizen loops and PDSA techniques for continuous improvement
• Define the options for cross-team learning: "community of practice" and "center of
excellence"

Agenda
1. Understanding Ongoing Process Goals
2. Ongoing Agile practices
a. Standard Work
b. Explicit Workflow Policies
c. Guided Continuous Improvement
3. How does an agile organization support cross-team learning?
a. Communities of Practice
b. Centers of Excellence

57
Lesson Notes

Ongoing Phase
The Ongoing phase includes those activities that occur continuously through the other three
phases.

Ongoing Process Phase Goals

There are six process goals associated with the Ongoing phase:
• Grow team members
• Coordinate activities
• Evolve WoW
• Address risk
• Leverage and enhance existing infrastructure
• Govern delivery team

Grow Team Members

The Grow Team Members process goal captures options for providing opportunities for people
to improve. This process goal is highly related to the People Management and Continuous
Improvement process blades which focus on helping people at the organization level. There are
several reasons why this goal is important:
1. People—and the way we work together—are key to success. Remember the agile value
of "Individuals and interactions over processes and tools?"
2. Motivated people are effective people. In Drive: The Surprising Truth About What
Motivates Us (2011), Daniel Pink argues people are motivated by autonomy, mastery
and purpose. This process goal focuses on providing opportunities for people to master
their craft.
3. Solution delivery is a team sport. Great teams are composed of people who want to
work and improve together.
This ongoing process goal describes how we will support our team members in their personal
and professional growth. To be effective, we need to consider three important questions:
• How will we help people improve their skill set?
• How will we provide feedback to team members to help them grow?
• How will we sustain the team over time to enable people to grow?

Coordinate Activities
The Coordinate Activities process goal provides options for coordinating both within a team and
with other teams within our organization. There are several reasons why this goal is important:
• Support effective collaboration. It is rare to be completely autonomous because we
often need to collaborate with others, hence the need to coordinate with one another.

58
 This will help to reduce and hopefully eliminate several sources of waste, particularly
wait time and rework.
• Support autonomy. In Drive: The Surprising Truth About What Motivates Us (2011),
Daniel Pink argues that autonomy, mastery and purpose are what motivates people.
One aim of this process goal is to suggest ways of working that enable both people and
teams to work as autonomously as possible, yet still collaborate effectively with others
as needed. Note that the Develop Common Vision process goal promotes the idea of
teams with purpose and the Grow Team Members process goal provides opportunities
for gaining mastery.
• Working agreement within the team. A team's working agreement describes how it will
work together as well as with others. An important aspect of our team's working
agreement is how we intend to coordinate our activities internally within our team.
• Working agreement with other teams. Similarly, indicating how others may interact
with our team is also an important part of our team's working agreement. Having
effective coordination strategies in place enables our team to collaborate effectively
with others.

Evolve WoW
The Evolve Way of Working (WoW) process goal provides options for identifying and evolving
how we will work together as a team. The focus of this goal is on the WoW for a team, the
focus of Continuous Improvement is to support and enable teams to choose their WoW and to
share learnings across the organization. There are several reasons why this goal is important:
• Every team is unique and faces a unique situation. Because people are unique, teams
are therefore also unique. Every team faces a unique configuration of complexity factors
including team size, geographic distribution, technical complexity, regulatory
compliance, and other issues. The implication is that a team needs to tailor their WoW
to address the situation that it faces.
• We are constantly learning. As individuals we learn every day - maybe we learn a new
skill, something about the problem we face, something about how our colleagues work,
something about our technical or organizational environment, or something else. These
learnings will often motivate us to evolve the way that we work.
• The other teams we collaborate with are evolving. Very few agile teams are "whole" in
practice. They must collaborate with others to achieve their mission. Because these
other teams are evolving their WoW over time the implication is that the way that they
interact with us will evolve too, something that we may be able to learn from.
• Our environment is constantly evolving. Our external environment is constantly
changing, with our competitors evolving their offerings, the various levels of
government introducing new legislation (including regulations that we need to comply
with), new and evolving technical offerings in the marketplace, and world events in
general. Our internal environment also evolves, with people joining and leaving our
organization, our organizational structure evolving, and our IT ecosystem evolving as
other teams release their solutions into production. Needless to say, we may need to
evolve our WoW to reflect these changes.

59
 • The team needs somewhere to work. On some teams, everyone is dispersed and
working from home; the rest will need space for some or all team members.
• The team needs sufficient tooling. The team needs access to physical and digital tools
so we can do our work.
• These strategies are applicable to a wide range of teams, not just solution delivery
teams. We've applied these strategies with leadership teams, marketing teams, finance
teams, enterprise architecture teams, data management teams, and many others.
Having said that, the focus is on how solution delivery teams can choose their WoW.
Although this process goal applies to all of those teams the rest of the goals may not.
Each of these domains (marketing, leadership, etc.) requires domain-specific advice.

Leverage and Enhance Existing Infrastructure

The Leverage and Enhance Existing Infrastructure process goal provides options for reusing and
hopefully improving existing assets within our organization. These assets may include guidance,
functionality, data and even process-related materials. This process goal is related to the
Improve Quality process goal, which focuses on strategies to pay down technical debt in such
assets and the Reuse Engineering process blade, which focuses on the reuse of existing assets.
There are several reasons why this goal is important:
• A lot of good work has occurred before us. There is a wide range of assets within our
organization that our team can leverage. Sometimes we will discover that we need to
first evolve the existing asset so that it meets our needs—which often proves faster and
less expensive than building it from scratch.
• We can reduce overall technical debt. The unfortunate reality is that many organizations
struggle under significant technical debt loads. By choosing to reuse existing assets, and
investing in paying down some of the technical debt that we run into when doing so,
we'll slowly dig our way out of the technical debt trap that we find ourselves in.
• We can provide greater value quicker. Increased reuse enables us to focus on
implementing new functionality to delight our customers instead of just reinventing
what we're already offering them.

Addressing Risk
Disciplined Agile Delivery (DAD) has several risk mitigation strategies built in:
• The Address Risk process goal. Originally DAD had two risk-focused process goals, this
one and Identify Initial Risks, but due to the significant overlap between the two we
decided to simplify the framework by combining them into a single process goal.
• Support for a risk-value life cycle. DAD promotes a risk-value life cycle approach where
we recommend that risk be considered when prioritizing work in addition to stakeholder
value---many agile methods focus just on value to their detriment. The risk-value profile
for a DAD team shows how DAD teams address a lot of risk very early in the life cycle via
addressing the Stakeholder Vision and Proven Architecture milestones.
• Support for ordered ways of working (WoW). As you've seen here, within each process
goal diagram many of the decision points have ordered option/choice lists. This makes

60
 the lower-risk ways of working explicit because the more effective options tend to be
towards the top of the lists.
• The Address Risk process goal provides options for how we will approach risk within our
team. Although the project management community prefers the term "manage risk"
rather than "address risk," not surprisingly, we find that the word manage comes with
too much baggage---managing risk leaves the door open to needless bureaucracy,
whereas addressing risk motivates us to focus on dealing with the challenges that we
face.
There are several reasons why the Address Risk goal is important:
• We face many risks. Many risks are addressed within the team, but some risks we'll
need help from outside the team to address. Disciplined teams make risks transparent,
making it easier for them to garner the help they need.
• Understanding the level of risk is a critical decision factor for moving forward. Two of
the questions that we should ask at the Stakeholder Vision milestone is whether the
team understands the risks that it faces and if so, does it have a viable strategy to
respond to them? Similarly, any go-forward decision made during Construction should
take the current level of risk faced by the team into account.
• Reducing risk increases our chance of success. Enough said.
• It's usually better to deal with risks early (in other words, shift risk mitigation left). Risks
tend to grow (but not always). If a risk proves to be a problem, it's better to know that
early when we still have time and budget to fix it, or if the risk proves insurmountable,
it's better to cancel or go in a different direction and thereby not waste time and
money.

Process Goal: Govern Delivery Team

The Govern Delivery Team process goal provides options for governing agile and lean delivery
teams. Governance establishes chains of responsibility, authority and communication in
support of the overall enterprise's goals and strategy. It also establishes measurements,
policies, standards and control mechanisms to enable people to carry out their roles and
responsibilities effectively. You do this by balancing risk versus return on investment (ROI),
setting in place effective processes and practices, defining the direction and goals for a team,
and defining the roles that people play within a team.
The Govern Delivery Team process goal is supported by both the IT Governance and
the Control process blades. There are several reasons why this goal is important:
• We are going to be governed. Many in the agile community believe that governance is a
swear word, likely because they've had negative experiences when traditional
governance strategies [COBIT] were applied to agile teams. Although we understand this
attitude, we find it to be counterproductive because someone is going to govern our
teams, like it or not. Someone will govern the finances, they will govern the quality, and
they will govern what we produce---just to name a few issues.
• We deserve to be governed well. Our team is made up of intellectual workers, people
who are smart and skilled at their jobs. They respond well to leadership—deciding for

61
 themselves what to do—and not very well to management—being told what to do. As a
result, effective governance is based on motivation and enablement, not command and
control.
• Governance is context sensitive. A traditional waterfall team is governed in a very
different way than an agile project team, which in turn is governed in a different way
than a team following the Continuous Delivery: Lean life cycle. Teams that are less
experienced or facing significant risk will require more governance than those that are
not.
• Our team is part of a larger organization, and we need to leverage that. Our
organization is a complex adaptive system (CAS), a collection of teams working together
in an adaptable and constantly changing manner. And we've been doing this for a very
long time, in some cases decades and even centuries. We have a wealth of experience,
skills, intellectual property and physical assets available to us that we can use in new
ways to delight our customers. The point is that we don't need to work on our own, and
in fact we likely can't—given the complexity that we face, and we certainly don't need
to build everything from scratch.
• Effective governance enables collaboration. Given that our organization is a CAS, the
leaders who are governing us must focus on helping our teams to be successful. This
includes ensuring that we have the resources we require to accomplish our mission and
ensure that we're collaborating effectively with the other teams that we need help
from.
• We have responsibilities to external stakeholders. Our team has stakeholders to whom
we are beholden, and one aspect of governance is to ensure that our team meets their
needs. These stakeholders include auditors who need to ensure that we're compliant to
any appropriate regulations or internal processes, legal professionals who help us to
address appropriate legal issues, and company shareholders (citizens when we work for
a government agency or nonprofit) whom we effectively work for.
Our focus in this process goal is on delivery/development governance, but as you can imagine
other governance categories have an effect on it. For example, solution delivery teams will still
need to be governed in their use of data, guided by user experience (UX) standards, and funded
in accordance to finance guidelines, while fulfilling roles supported by people (management)
governance.
In this process goal we use several terms that we want to define now:
• Leadership. People within our organization, often senior management, who are leaders.
• Enterprise groups. Teams responsible for information technology (IT) or enterprise-level
activities such as enterprise architects, finance, security and procurement.
• Enterprise professionals. People such as enterprise architects, finance professionals,
security engineers and procurement specialists.

62