Scribd
Upload
109 views

DASM Study Guide-6

Uploaded by

MILTON CÉSAR AGUILAR DE AZAMBUJA
Copyright
© © All Rights Reserved
Available Formats
Download as PDF, TXT or read online on Scribd
109 views

DASM Study Guide-6

Uploaded by

MILTON CÉSAR AGUILAR DE AZAMBUJA
Copyright
© © All Rights Reserved
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 7

Shared Team Services

Collaborative Enterprise Teams


Individuals are members of both a work team and an enterprise team.
In some cases, the work teams will nominate who will be in the enterprise role for them.
In other cases, the enterprise team will assign one of their people to support a work team.
This requires a lot of people to be part of the enterprise team.
Shared Services Enterprise Teams
These teams fulfill requests for work from other teams.

Team Context and Scaling Factors


Every team is in a unique situation.
There is more to scaling than just team size.
The spider diagram below shows each scaling factor for tactical scaling. The further out you are
on each leg, the more complex your team’s context is. This means you will face more challenges
in scaling and may need to look at tailoring in more areas than if your context was near the
center of the diagram.

35
Team size – Scaling Factor
Key Concepts
• Large teams are organized differently than small teams.
• Globally distributed teams are organized differently than collocated teams.
• Organizational distribution, some people working for an outsourcer, can also affect
things.
• This lesson works through these issues.
• Sometimes we need to bring in technical or domain experts to help us out for a short
period.
• Sometimes we’re supported by an independent tester due to regulatory compliance
concerns.
• The line with the diamond at the end is the UML notation for composition.
• Coordination within medium-sized teams can likely be accomplished via a “Scrum of
Scrums.”
• Each subteam builds a portion of the overall solution (features, components, …).
• Large teams: The leadership teams will self-organize and meet and coordinate with each
other as they see fit.
• Large teams: The program manager/coordinator coordinates the overall program and
leadership subteams (called an RTE in SAFe®).

Geographic Distribution – Scaling Factor


As team members are more geographically dispersed, coordination becomes more difficult and
more sophisticated communication and coordination methods are required. Tools like
conferencing or messaging apps are vital here.

Organizational Distribution – Scaling Factor

36
Compliance – Scaling Factor

Technical Complexity – Scaling Factor

37
Domain Complexity – Scaling Factor

Tactical Agility at Scale


Using a tool like the spider diagram supports tactical agility at scale: scaling agile at the team
level. The aim is to apply agile deeply to address all the complexities/scaling factors
appropriately.

38
Lesson 4: Choosing Your WoW!
Description
To be an effective DASM for a delivery team, you’ll want to have a firm understanding of the
Disciplined DevOps layer so that you can effectively help your team meet complex challenges
in producing high quality solutions on time. With your understanding of the DA landscape
and the DA tool kit, you can optimize how the team works with the Disciplined DevOps layer.
You are also equipped to identify and help resolve impediments in this layer that the team
faces.

Objectives
Describe what business agility is and how it is core to the value proposition of Disciplined Agile
• Define business agility
• Identify the full range of business agility
Determine which situations each of the DA life cycles is best applied
• Describe how DA supports a variety of lifecycles
• Identify the 3 phases of the DAD delivery cycle
• Describe the Agile life cycle and identify when to use
• Describe the Lean life cycle and identify when to use
• Describe the continuous delivery Agile life cycle and identify when to use
• Describe the continuous delivery Lean life cycle and identify when to use
• Describe the exploratory life cycle and identify when to use
• Describe the program life cycle and identify when to use
• Describe the business agile and business lean life cycles
• Identify how to choose a life cycle and who chooses
Apply the DA practice of choosing a team's way of working (WoW)
• List the 5 steps for choosing your WoW
• Analyze the context using the spider chart
• List factors impacting context when choosing a team's WoW
• Select best-fit life cycle using the decision tree

Agenda
1. What is business agility?
2. What is a complex adaptive system?
3. Why do we want to be able to choose our team's way of working?
4. What are the Disciplined Agile life cycles?
5. How do you choose your way of working?

39
Lesson Notes

What is Business Agility?


Business agility is an organization’s ability to rapidly adapt to market and environmental
changes in productive and cost-effective ways.
Business agility focuses on value realized by having stakeholders identify, prioritize and
sequence the work to be done and allocate it appropriately to the product/service teams.
This is sometimes referred to as enterprise or organizational agility.
Business agility enables the realization of the highest value in a shorter amount of time,
predictably, sustainably and with high quality.
By working in small delivery increments, we continuously adjust to what is needed, enabling the
organization to change direction at low cost.

Why Do We Want to Be Able to Choose Our Team’s Way of Working?


We want to be able to choose our team’s way of working so we give those teams the flexibility
to adapt to changing circumstances, which is at the heart of agility. It gives the pieces of the
organization—and, by extension, the organization itself—the ability to adapt.
And because your organization is a complex adaptive system. What works for some teams may
not work for others. And even if a specific way of working does work for another team, there
may be unintended consequences outside that team.
Things to consider when choosing your way of working:
• Every team has a different way of working.
• We evolve our way of working to reflect what we learn when we work with other
teams.
• We accomplish our goals by working with other teams.

What Are the Discipline Agile Life Cycles?


A life cycle is a process for planning, creating, testing and deploying a product or service.
Disciplined Agile life cycles provide teams with the flexibility of choosing an approach that
makes sense for them. They are an essential tool for teams choosing their own way of working.
• Disciplined Agile Delivery supports several life cycles, which are shown here.
• Disciplined Agile also has life cycles for business teams.
• The flow aspects of process blades are described via either a life cycle or workflow
diagram(s)

Disciplined Agile Life Cycles—Agile


It extends Scrum’s construction life cycle. In addition to being a more detailed view of the life
cycle, we consider several other interesting aspects:

40
• It is iteration based.
• It uses non-Scrum terminology. Remember, Disciplined Agile is agnostic!
• It shows inputs from outside the delivery life cycle.
• There is a work item list, not a product backlog.
• It includes explicit milestones. Along the bottom of the life cycle diagram, see the
suggested lightweight milestones that teams should strive to meet. Such milestones are
an important aspect of agile governance.
When to use the Agile life cycle:
The work:
• is primarily enhancements or new features
• can be identified, prioritized, and estimated early in the project
The team:
• is new to agile practices
• is familiar with Scrum and Extreme Programming (XP)
• is typically working on a project

Disciplined Agile Life Cycles—Lean


There are several interesting features to this life cycle:
• It supports a continuous flow of work. In this life cycle, the solution is deployed as
often, and whenever, it makes sense to do so. Work is pulled into the team when there
is capacity to do it, not at the regular cadence of an iteration.
• Practices follow their own cadences. With iterations/sprints, many practices (detailed
planning, retrospectives, demos, detailed modeling and so on) effectively follow the
same cadence, which is that of the iteration. In a lean approach, the conventional
wisdom is to do something when it makes sense to do it, and not when the calendar
indicates that you’re scheduled to do it
• It has a work item pool. All work items are not created equal, although you may choose
to prioritize some work by business value. Some work, particularly work resulting from
legislation, is date driven. Some work must be expedited, such as fixing a “severity one”
production problem. So, a work item pool instead of a prioritized stack makes a bit more
sense when you recognize these realities.
When to use the Lean life cycle:
The work is:
• broken down into very small work items of roughly the same size
• difficult to predict in advance
The team:
• favors the lean approach of minimizing batch and any planning in advance of doing the
work
• is typically working on a project

41

You might also like