Disciplined Agile

1. Roles (5+5)

1.1. Primary

1.1.1. Team Lead

1.1.1.1. Similar (but noit the same) like Scrum Master in Scrum

1.1.1.2. Agile process expert, keeps team focused on achievement of goals, removes impediments

1.1.1.3. Responsible for the effectiveness and continuous improvement of the team's process

1.1.1.4. Facilitates close collaboration between team members

1.1.1.5. Keeps the team focused on the project vision and goals

1.1.1.6. Removes impediments for the team and escalates organizational impediments

1.1.1.7. Protects the team from interruptions and external interference

1.1.1.8. Maintains honest communication between everyone on the project

1.1.1.9. Coaches others in the use of agile practices

1.1.1.10. Prompts the team to discuss and think through issues when they are identified

1.1.1.11. Facilitates decision making (but does not make decisions or mandate internal team activity)

1.1.2. Product Owner

1.1.2.1. Owns the product vision, scope and priorities of the solution

1.1.2.2. The Stakeholder "proxy"

1.1.2.3. Go-to person for information on the solution requirements

1.1.2.4. Prioritizes all work for the team

1.1.2.5. Participant in modeling and acceptance testing

1.1.2.6. Has access to expert stakeholders

1.1.2.7. Facilitates requirements envisioning and modeling

1.1.2.8. Educates team in business domain

1.1.2.9. May demonstrate solution to key stakeholders

1.1.2.10. Monitors and communicates status to stakeholders

1.1.2.11. Negotiates priorities, scope, funding, and schedule

1.1.3. Team Member

1.1.3.1. Cross-functional team members that deliver the solution

1.1.3.2. Is a cross-functional, generalizing specialist

1.1.3.3. On small teams every team member is typically a developer, but on larger teams non-developers may appear

1.1.3.4. Volunteers to do any work that allows the team to most efficiently deliver the work committed to for the iteration

1.1.3.5. Seeks to both learn about other specialties as well as coach others on their own specialty

1.1.3.6. Goes to the product owner for domain information and decisions

1.1.3.7. Works with the architecture owner to evolve the architecture

1.1.3.8. Follows enterprise conventions and leverages and enhances the existing infrastructure

1.1.4. Architeture Owner

1.1.4.1. Owns the architecture decisions and technical priorities, mitigates key technical risks

1.1.4.2. Guides the creation and evolution of the solution's architecture

1.1.4.3. Mentors and coaches team members in architecture practices and issues

1.1.4.4. Understands the architectural direction and standards of your organization and ensures that the team adheres to them

1.1.4.5. Ensures the system will be easy to support by encouraging appropriate design and refactoring

1.1.4.6. Ensures that the system is integrated and tested frequently Has the final decision regarding technical decisions, but doesn't dictate them

1.1.4.7. Leads the initial architecture envisioning effort

1.1.4.8. Works closely with enterprise architecture team (if one exists)

1.1.4.9. Responsible for technical risk mitigation

1.1.5. Stakeholder

1.1.5.1. Includes the customer but also other stakeholders such as Project Sponsor, DevOps, architecture, database groups, governance bodies

1.1.5.2. The people who affect the success of your system and are affected by it

1.1.5.2.1. End users

1.1.5.2.2. Principals

1.1.5.2.3. Partners

1.1.5.2.4. Insiders

1.2. Supporting

1.2.1. Domain Expert (business)

1.2.1.1. Someone with deep knowledge of the domain, such as a legal expert or marketing expert who is brought in as needed to share their expertise

1.2.2. Specialist

1.2.2.1. Someone in a specialist role, such as business analyst, program manager, or enterprise architect

1.2.3. Technical Expert

1.2.3.1. Someone with deep technical knowledge, such as a security engineer or user experience (UX) professional, whose help is needed for a short period

1.2.4. Independent Tester

1.2.4.1. A test/quaility professional outside of the team who validates their work

1.2.5. Integrator

1.2.5.1. Someone responsible for the operation of the overall team build

1.3. DAD project roles means roles not positions

1.3.1. DAD project roles means roles not positions will be in one or more roles

1.3.2. Individual can change their role(s) over time, and any given role will have zero or more people performing it at any given time

2. Levels (4) & Process blades (33)

2.1. Disciplined Agile Enterprise (DAE).

2.1.1. 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 focuses on the rest of the enterprise activities that support your organization’s value streams.

2.1.2. Process blades (8)

2.1.2.1. Enterprise Architecture

2.1.2.2. People management

2.1.2.3. Information Technology

2.1.2.4. Asset management

2.1.2.5. Transformation

2.1.2.6. Finance

2.1.2.7. Vendor management

2.1.2.8. Legal

2.2. Disciplined DevOps.

2.2.1. DevOps is the streamlining of software development and IT operations activities. In Disciplined DevOps we extend this to take an enterprise-class approach that integrates Security and Data Management so as to provide more effective outcomes for your organization. We also recognize that for organizations with hundreds, and sometimes thousands of systems in production that Support (Help Desk) and Release Management activities need to be robust.

2.2.2. Process blades (6)

2.2.2.1. Disciplined Agile Delivery (DAD)

2.2.2.2. Security

2.2.2.3. Data management

2.2.2.4. Release management

2.2.2.5. Support

2.2.2.6. IT Operations

2.3. Value Streams.

2.3.1. The Value Streams layer is the glue that ties together an organization’s strategies. This layer visualizes what an effective value stream looks like, enabling you to make decisions for improving each part of the organization within the context of the whole. It’s not enough to be innovative, you also need to increase value realization – value streams show you how to do exactly that in the environment that you face.

2.3.2. Process blades (10)

2.3.2.1. Research & development

2.3.2.2. Business Operations

2.3.2.3. Strategy

2.3.2.4. Governance

2.3.2.5. Marketing

2.3.2.6. Continuous improvement

2.3.2.7. Sales

2.3.2.8. Portofolio management

2.3.2.9. Product management

2.3.2.10. Program management

2.4. Foundation.

2.4.1. The Foundation layer provides the conceptual underpinnings of the DA tool kit. This includes the DA mindset; fundamental concepts from both agile and lean; fundamental concepts from serial/traditional approaches; roles and team structures; and the fundamentals of choosing your way of working (WoW).

2.4.2. Process blades (9)

2.4.2.1. Principles

2.4.2.2. Promises

2.4.2.3. Guidelines

2.4.2.4. Agile

2.4.2.5. Lean

2.4.2.6. Serial

2.4.2.7. Roles

2.4.2.8. Teams

2.4.2.9. Way of Working (WoW)

3. Phases (3+1) & Process Goals (21) - DA BROWSER

3.1. https://www.pmi.org/disciplined-agile/da-browser

4. created by Dionysis Svoronos www.linkedin.com/in/dionysis-svoronos

5. Certification journey

5.1. DASMTM: The Disciplined Agile Scrum Master has a basic knowledge of DA and is able to use the DA tool kit with their own teams to choose their WoW and improve their processes.

5.2. DASSMTM: The Disciplined Agile Senior Scrum Master has a better understanding of the DA mindset and can use the DA tool kit to help one or more teams under their leadership solve more complex problems. They also have knowledge of team development, emotional intelligence, and conflict management, as well as planning and reporting and metrics. As a team lead, they focus their team or team of teams.

5.3. DACTM: The Disciplined Agile Coach has internalized the DA mindset and can apply it in any context. They are able to use the DA tool kit at an advanced level to coach any team or group of teams to become proficient at evolving their WoW and improving their processes. They are also able to help teams see their place in the larger organization and solve cross-team problems accordingly.

5.4. DAVSCTM: The Disciplined Agile Value Stream Consultant takes an even more challenging role, helping organizations achieve agility by improving processes across the enterprise in a way that optimizes the organization’s value streams.

6. Description

6.1. Disciplined Agile Delivery (DAD) - an iterative, incremental and adaptive (change-driven / empirical) agile project management method and framework (not just framework like Scrum) for general (not industry specific e.g. IT or Engineering) agile project management. fundamental strategies to choose and evolve your way of working (WoW) and the Disciplined AgileTM mindset, overviews DAD, describes typical roles and responsibilities of people on DAD teams, describes a process goal/outcome-driven approach that makes your process choices explicit, and shows how DAD supports several life cycles that share a common governance strategy.

6.1.1. discipline to follow many agile practices & philosophies

6.1.1.1. Reduce the feedback cycle

6.1.1.2. Learn continuously

6.1.1.3. Deliver solutions incrementally

6.1.1.4. Be goal driven

6.1.1.5. Enterprise aware

6.1.1.6. Streamline Inception and Transition efforts

6.1.1.7. Adopt agile governance strategies

6.1.2. Agile Manifesto

6.1.2.1. Individuals and interactions over processes and tools

6.1.2.2. Consumable solutions over comprehensive documentation

6.1.2.3. Stakeholder collaboration over contract negotiation

6.1.2.4. Responding to change over following a plan

6.1.2.5. Principles

6.1.2.5.1. 1. Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.

6.1.2.5.2. 2. Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.

6.1.2.5.3. 3. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.

6.1.2.5.4. 4. Business people and developers must work together daily throughout the project.

6.1.2.5.5. 5. Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.

6.1.2.5.6. 6. The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.

6.1.2.5.7. 7. Working software is the primary measure of progress.

6.1.2.5.8. 8. Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.

6.1.2.5.9. 9. Continuous attention to technical excellence and good design enhances agility.

6.1.2.5.10. 10. Simplicity—the art of maximizing the amount of work not done—is essential.

6.1.2.5.11. 11. The best architectures, requirements, and designs emerge from self-organizing teams.

6.1.2.5.12. 12. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

6.1.3. Lean Software Development Principles

6.1.3.1. Eliminate waste.

6.1.3.2. Build quality in.

6.1.3.3. Create knowledge.

6.1.3.4. Defer commitment.

6.1.3.5. Deliver quickly.

6.1.3.6. Respect people

6.1.3.7. Optimize the whole.

6.1.4. Critical aspects (8)

6.1.4.1. people-first, learning-oriented, hybrid agile approach to IT solution delivery.

6.1.4.2. People first

6.1.4.2.1. People, and the way we work together, are the primary determinant of success for a solution delivery team. DAD supports a robust set of roles, rights, and responsibilities that you can tailor to meet the needs of your situation.

6.1.4.3. Hybrid

6.1.4.3.1. DAD leverages proven strategies from several sources, providing a decision framework to guide your adoption and tailoring of them in a context-driven adoption and tailoring of them in a context-driven

6.1.4.4. Full-delivery life cycle.

6.1.4.4.1. DAD addresses the full-delivery life cycle, from team initiation all the way to delivering a solution to your end users.

6.1.4.5. Support for multiple life cycles.

6.1.4.5.1. DAD supports agile, lean, continuous delivery, exploratory, and large-team versions of the life cycle. DAD doesn’t prescribe a single life cycle because it recognizes that one process approach does not fit all. Chapter 6 explores life cycles in greater detail, providing advice for selecting the right one to start with and then how to evolve from one to another over time.

6.1.4.6. Complete.

6.1.4.6.1. DAD shows how development, modeling, architecture, management, requirements/ outcomes, documentation, governance, and other strategies fit together in a streamlined whole. DAD does the “process heavy lifting” that other methods leave up to you.

6.1.4.7. Context-sensitive.

6.1.4.7.1. DAD promotes what we call a goal-driven or outcome-driven approach. In doing so, DAD provides contextual advice regarding viable alternatives and their trade- offs, enabling you to tailor DAD to effectively address the situation in which you find yourself.

6.1.4.8. Consumable solutions over working software.

6.1.4.8.1. Potentially shippable software is a good start, but what we really need are consumable solutions that delight our customers.

6.1.4.9. Self-organization with appropriate governance.

6.1.4.9.1. Agile and lean teams are self-organizing, which means that the people who do the work are the ones who plan and estimate it. But that doesn’t mean they can do whatever they want.

6.1.5. DAD effective teams characteristics

6.1.5.1. The majority of team members should be "generalizing specialists" (T-skilled people)

6.1.5.2. focused

6.1.5.3. tailored to the environment

6.1.5.4. trust & respect

6.1.5.5. safe

6.1.5.6. provide learning opportunities

6.1.5.7. as small as possible

6.1.5.8. have shared woskspaces

6.1.5.9. "whole"

6.1.5.10. have adequate resources to fulfill their remit

6.1.5.11. accountable

6.1.5.12. self-aware

6.1.5.12.1. strive to identify what works well for them, what doesn't and the learn and adjust

6.1.5.12.2. understand how to improve

6.1.5.13. self-disciplined

6.1.5.13.1. commit only to the work which they can accomplish and then perform that work as effectively as possible

6.1.5.14. self-orgainizing

6.1.5.14.1. estimate & plan their own work and then proceed to collaborate ineratively to do so

6.1.5.14.2. within the constraints of appropriate governance

6.1.5.15. enterprise aware

6.1.5.15.1. DAD teams strive to leverage and enhance the existing organizational ecosystem wherever possible

6.1.5.16. include dedicated people

6.1.5.17. geographically close

6.1.5.18. follow a common strategy

6.1.5.19. stay together

6.1.6. Rights of everyone

6.1.6.1. To be treated with respect

6.1.6.2. To produce and receive quality work based upon agreed standards

6.1.6.3. own the estimation process

6.1.6.4. determine how teams resources are allocated

6.1.6.5. work in a "safe environment"

6.1.6.6. be provided good faith information and decisions in timely manner

6.1.6.7. own the team's processes and be enabled to improve them

6.1.7. Responsibilities of everyone

6.1.7.1. produce a solution that meets the needs of stakeholders given the resource constraints

6.1.7.2. optimize the use of those resources

6.1.7.3. be willing to collaborate extensively within your team including those outside your specialty

6.1.7.4. share all information including "work in progress"

6.1.7.5. coach others in your skills and experience

6.1.7.6. expand your knowledge and skills outside your specialty

6.1.7.7. validate your work as early as possible, working with others to do so

6.1.7.8. attend co-ordination meetings in person or through other means if not collocated

6.1.7.9. proactively look for ways to improve team performance

6.1.7.10. avoid accepting work outside of the current iteration without consent from the team

6.1.8. Challenges when building teams

6.1.8.1. You don't have adequate agile mentoring

6.1.8.2. You don't have team leads that are skilled coaches

6.1.8.3. You don't have (enough) generalizing specialists

6.1.8.4. You don't have skilled product owners

6.1.8.5. Your human resources (HR) department is geared toward staffing traditional teams

6.1.8.6. You don't have (enough) agile-experienced people

6.1.8.7. You can't build a whole team

6.1.8.8. Not everyone is an agile expert

6.1.8.9. You don't know how to identify agile-experienced people

6.1.8.10. Some of your staff want/need to be directed and not be self-organizing

6.1.9. Risk and value driven

6.1.9.1. Address common project risks

6.1.9.1.1. Stakeholder consensus around vision

6.1.9.1.2. Proving the architecture early

6.1.9.1.3. Align with enterprise direction

6.1.9.1.4. Work on things that promote learning early in the lifecycle

6.1.9.2. Value Driven

6.1.9.2.1. Work on the most valuable things first

6.1.9.2.2. Continued assessment of project viability and business value

6.1.9.2.3. Determining when sufficient functionality has been produced

6.1.9.2.4. Potentially consumable solutions throughout the lifecycle

6.1.9.2.5. Continually assessing new work against the vision

7. Mindset

7.1. Principles (8)

7.1.1. provide a philosophical foundation for business agility. They are based on both lean and flow concepts.

7.1.2. Delight customers.

7.1.2.1. We need to go beyond satisfying our customers' needs, beyond meeting their expectations and strive to delight them. If we don't then someone else will delight them and steal our customers away from us. This applies to both external customers as well as internal customers.

7.1.3. Be awesome.

7.1.3.1. We should always strive to be the best that we can and to always get better. Who wouldn't want to work with awesome people, on an awesome team for an awesome organization?

7.1.4. Context counts.

7.1.4.1. Every person, every team, every organization is unique. We face unique situations that evolve over time. The implication is that we must choose our way of working (WoW) to reflect the context that we face, and then evolve our WoW as the situation evolves.

7.1.5. Be pragmatic.

7.1.5.1. Our aim isn't to be agile, it's to be as effective as we can be and to improve from there. To do this we need to be pragmatic and adopt agile, lean, or even traditional strategies when they make the most sense for our context. In the past, we called this principle “Pragmatism.”

7.1.6. Choice is good.

7.1.6.1. To choose our WoW in a context-driven, pragmatic manner we need to select the best-fit technique given our situation. Having choices, and knowing the trade-offs associated with those choices, is critical to choosing our WoW that is the best fit for our context.

7.1.7. Optimize flow.

7.1.7.1. We want to optimize flow across the value stream that we are part of, and better yet across our organization, and not just locally optimize our WoW within our team. Sometimes this will be a bit inconvenient for us, but overall we will be able to more effectively respond to our customers.

7.1.8. Organize around products/services

7.1.8.1. To delight our customers we need to organize ourselves around producing the offerings, the products and services, that they need. We are in effect organizing around value streams because value streams produce value for customers, both external and internal, in the form of products and services. We chose to say organize around products/services, rather than offerings or value streams, as we felt this was more explicit.

7.1.9. Enterprise awareness.

7.1.9.1. Disciplined agilists look beyond the needs of their team to take the long-term needs of their organization into account. They adopt, and sometimes tailor, organizational guidance. They follow and provide feedback too, organizational roadmaps. They leverage, and sometimes enhance, existing organizational assets. In short, they do what's best for the organization and not just what's convenient for them.

7.2. Promises (7)

7.2.1. agreements that we make with our fellow teammates, our stakeholders, and other people within our organization with whom we interact. The promises define a collection of disciplined behaviors that enable us to collaborate effectively and professionally.

7.2.2. Create psychological safety and embrace diversity.

7.2.2.1. Psychological safety means being able to show and apply oneself without fear of negative consequences of status, career, or self-worth—we should be comfortable being ourselves in our work setting. Psychological safety goes hand-in-hand with diversity, which is the recognition that everyone is unique and can add value in different ways. The dimensions of personal uniqueness include, but are not limited to, race, ethnicity, gender, sexual orientation, agile, physical abilities, socioeconomic status, religious beliefs, political beliefs, and other ideological beliefs. Diversity is critical to a team’s success because it enables greater innovation. The more diverse our team, the better our ideas will be, the better our work will be, and the more we’ll learn from each other.

7.2.3. Accelerate value realization.

7.2.3.1. In DA we use the term value to refer to both customer and business value. Customer value, something that benefits the end customer who consumes the product/service that our team helps to provide, is what agilists typically focus on. This is clearly important, but in Disciplined Agile we’re very clear that teams have a range of stakeholders, including external end customers. Business value addresses the issue that some things are of benefit to our organization and perhaps only indirectly to our customers. For example, investing in enterprise architecture, in reusable infrastructure, and in sharing innovations across our organization offer the potential to improve consistency, quality, reliability, and reduce cost over the long term.

7.2.4. Collaborate proactively.

7.2.4.1. Disciplined agilists strive to add value to the whole, not just to their individual work or to the team’s work. The implication is that we want to collaborate both within our team and with others outside our team, and we also want to be proactive doing so. Waiting to be asked is passive, observing that someone needs help and then volunteering to do so is proactive.

7.2.5. Make all work and workflow visible.

7.2.5.1. DA teams will often make their work visible at both the individual level as well as the team level. It is critical to focus on our work in process, which is our work in progress plus any work that is queued up waiting for us to get to it. Furthermore, DA teams make their workflow visible, and thus have explicit workflow policies, so that everyone knows how everyone else is working.

7.2.6. Improve predictability.

7.2.6.1. DA teams strive to improve their predictability to enable them to collaborate and self-organize more effectively, and thereby to increase the chance that they will fulfill any commitments that they make to their stakeholders. Many of the earlier promises we have made work toward improving predictability.

7.2.7. Keep workloads within capacity.

7.2.7.1. Going beyond capacity is problematic from both a personal and a productivity point of view. At the personal level, overloading a person or team will often increase the frustration of the people involved. Although it may motivate some people to work harder in the short term, it will cause burnout in the long term, and it may even motivate people to give up and leave because the situation seems hopeless to them. From a productivity point of view, overloading causes multitasking, which increases overall overhead.

7.2.8. Improve continuously.

7.2.8.1. The really successful organizations—Apple, Amazon, eBay, Facebook, Google, and more—got that way through continuous improvement. They realized that to remain competitive they needed to constantly look for ways to improve their processes, the outcomes that they were delivering to their customers, and their organizational structures.

7.3. Guidelines (8)

7.3.1. help us to be more effective in our way of working (WoW) and in improving our WoW over time.

7.3.2. Validate our learnings.

7.3.2.1. The only way to become awesome is to experiment with, and then adopt where appropriate, a new WoW. In guided continuous improvement (GCI) we experiment with a new way of working and then we assess how well it worked, an approach called validated learning. Being willing and able to experiment is critical to our process-improvement efforts.

7.3.3. Apply design thinking.

7.3.3.1. Delighting customers requires us to recognize that our aim is to create operational value streams that are designed with our customers in mind. This requires design thinking on our part. Design thinking means to be empathetic to the customer, to first try to understand their environment and their needs before developing a solution.

7.3.4. Attend to relationships through the value stream.

7.3.4.1. The interactions between the people doing the work are what is key, regardless of whether or not they are part of the team. For example, when a product manager needs to work closely with our organization’s data analytics team to gain a better understanding of what is going on in the marketplace, and with our strategy team to help put those observations into context, then we want to ensure that these interactions are effective.

7.3.5. Create effective environments that foster joy.

7.3.5.1. Part of being awesome is having fun and being joyful. We want to work in our company to be a great experience so we can attract and keep the best people. Done right, work is play. We can make our work more joyful by creating an environment that allows us to work together well.

7.3.6. Change culture by improving the system.

7.3.6.1. While culture is important, and culture change is a critical component of any organization’s agile transformation, the unfortunate reality is that we can't change it directly. This is because the culture is a reflection of the management system in place, so to change our culture we need to evolve our overall system.

7.3.7. Create semi-autonomous self-organizing teams.

7.3.7.1. Organizations are complex adaptive systems (CASs) made up of a network of teams or, if you will, a team of teams. Although mainstream agile implores us to create “whole teams” that have all of the skills and resources required to achieve the outcomes that they’ve been tasked with, the reality is that no team is an island unto itself. Autonomous teams would be ideal but there are always dependencies on other teams upstream that we are part of, as well as downstream from us. And, of course, there are dependencies between offerings (products or services) that necessitate the teams responsible for them to collaborate.

7.3.8. Adopt measures to improve outcomes.

7.3.8.1. When it comes to measurement, context counts. What are we hoping to improve? Quality? Time to market? Staff morale? Customer satisfaction? Combinations thereof? Every person, team, and the organization has their own improvement priorities, and their own ways of working, so they will have their own set of measures that they gather to provide insight into how they’re doing and, more importantly, how to proceed. And these measures evolve over time as their situation and priorities evolve. The implication is that our measurement strategy must be flexible and fit for purpose, and it will vary across teams.

7.3.9. Leverage and enhance organizational assets.

7.3.9.1. Our organization has many assets—information systems, information sources, tools, templates, procedures, learnings, and other things—that our team could adopt to improve our effectiveness. We may not only choose to adopt these assets, we may also find that we can improve them to make them better for us as well as other teams who also choose to work with these assets.

7.4. Beliefs (3)

7.4.1. The complexity belief.

7.4.1.1. Many of the problems that we face are complex adaptive problems, meaning by trying to solve these problems we change the nature of the problem itself.

7.4.2. The people belief.

7.4.2.1. Individuals are both independent from and dependent on their teams and organizations. Human beings are interdependent. Given the right environment (safety, respect, diversity, and inclusion) and a motivating purpose, it is possible for trust and self-organization to arise. For this to happen, it is necessary to treat everyone with unconditional positive regard.

7.4.3. The proactive belief.

7.4.3.1. Proactivity is found in the relentless pursuit of improvement.

8. Life Cycles (6)

8.1. Agile

8.2. Lean

8.3. Continuous Delivery: Agile

8.4. Continuous Delivery: Lean

8.5. Exploratory

8.6. Program

9. DAC

9.1. DAC role

9.1.1. DAC definition

9.1.1.1. The purpose of a coach is to help people see the world in a way that enables more effective action.

9.1.1.1.1. Coaches don’t tell people what to do.

9.1.1.1.2. Rather, they empower people to make their own decisions by helping them identify their problems and find effective

9.1.1.2. A Disciplined Agile CoachTM uses agile coaching skills and advanced Disciplined Agile® knowledge to enable teams in any part of an organization to independently improve their way of working (WoW) by embracing the DA mindset and applying the DA tool kit.

9.1.1.2.1. The most important quality of a DAC is an ability to universally recognize and apply the DA mindset to any circumstance, team, or challenge.

9.1.1.3. DACTM: The Disciplined Agile Coach has internalized the DA mindset and can apply it in any context. They are able to use the DA tool kit at an advanced level to coach any team or group of teams to become proficient at evolving their WoW and improving their processes. They are also able to help teams see their place in the larger organization and solve cross-team problems accordingly.

9.1.2. DA tool kit expertise

9.1.2.1. As a DAC, you’ll need to be an expert in the full DA tool kit and capable of helping diverse teams use the tool kit to solve complex problems, even when there is no optimal solution. The capabilities of a DAC range beyond the Disciplined Agile Delivery (DAD) team to include process goals that fall under a variety of process blades, including those at the enterprise level.

9.1.3. DAC skills

9.1.3.1. • Ability to work with people and teams in the entire organizational stack • Expertise in applying a variety of approaches and tools, especially the DA tool kit, as well as o Lean change management o Multiple coaching models o Multiple change models • Creativity and flexibility in recognizing teams as unique, and approaching problems with an open mind • Willingness to ask for help when needed, and knowledge of where to go for help • Diplomacy and negotiation skills, especially with leadership

9.1.4. DAC focus

9.1.4.1. A DAC focuses on teams. They usually serve multiple teams, often within a particular area of the organization (such as development, human resources, or finance). A DAC recognizes that teams exist within their larger organization and is aware of the impact of various external forces on the teams they coach. As a result, they often find that they need to coach two or more teams through identifying better ways to work together.

9.1.4.1.1. Because every organization is a complex, adaptive system, a DAC works at a variety of levels to address issues and remove impediments to team agility.

9.1.4.2. • Many of an organization’s problems and impediments manifest at the team level. • Although many problems are systemic, they are most acutely felt at the team level. • As teams learn to identify problems, improve processes, and become more agile, the organization will become more agile.

9.1.5. Scope

9.1.5.1. Teams

9.1.5.1.1. Work with teams to improve their way of working.

9.1.5.2. Teams in organization

9.1.5.2.1. Look at how teams fit into the organization and help them deal with problems that originate in other parts of the enterprise.

9.1.5.3. agile transformation

9.1.5.3.1. Lead teams through their part of the organization’s agile transformation.

9.1.6. Benefits

9.1.6.1. Faster adoption and improvement, meeting more complex challenges.

9.1.6.1.1. Unlike traditional coaches, a DAC possesses the knowledge, expertise, and tools to help teams make meaningful improvements and develop the skills and confidence to continue on after the coach has left, in essence, to achieve long-term, sustainable agility.

9.1.7. Responsibilities

9.1.7.1. “accelerates learning about agile and lean ways of working. Coaching also helps teams to understand how to work effectively together.”

9.1.7.1.1. trade-offs

9.1.7.2. “A DAC is responsible for sharing their skills and knowledge with others in a timely and respectful manner.”

9.1.7.2.1. o Helps individuals or teams to improve their way of working (WoW). o Helps to keep the team on track in building their agile mindset and applying new techniques. o Coaching a team in a new approach often takes longer than you’d hope. o There is a clear cost to coaching, but it is hard to measure the benefits. o It is difficult to find experienced, knowledgeable coaches.

9.1.8. Spectrum

9.1.8.1. 1. Self. The first level of coaching involves understanding yourself and building you own interpersonal and subject matter skills. 2. Individual. Once you understand yourself and have a base of knowledge, you can help others develop their skills. 3. Team. Next, you gain skills to coach teams, which entails understanding group dynamics; creating an environment conducive to high performance, inclusion, and collaboration; helping teams develop skills to become agile; and cross-team improvements. 4. Value stream. A value stream begins, ends, and continues with a customer. Value streams require multiple teams to work together effectively, and this in turn often needs to be supported by coaching/consulting efforts. 5. Organization. Finally, a coach may choose to develop an additional capability to work on an enterprise level to help organizations develop business agility.

9.1.9. DAC responsibilities

9.1.9.1. A Disciplined Agile Coach (DAC)TM coaches at the team and enterprise levels. When an organizational function is missing, decide the extent to which it is needed.

9.1.10. Mindset

9.1.10.1. • Collaborative decision- making • Why teams should choose their way of working (WoW) • Guided continuous improvement (GCI)

9.1.10.2. • Unvalidated assumptions = blind spots • Decisions may be based on unvalidated assumptions • People often hold on to assumptions • Sometimes sponsors need coaching

9.2. DAC Goals

9.2.1. Objectives

9.2.1.1. • Self-organizing

9.2.1.1.1. The DAC trusts that the team can choose a way of working (WoW) that’s best for them, given the context that they face. However, they must do so in an enterprise-aware manner by collaborating with other teams and following organizational procedures and standards. When team members are enterprise-aware, they’re motivated to consider the overall needs of their organization. They ensure that what they’re doing contributes to the organization's goals and not just to the goals of their team. Teams are part of a complex, adaptive system (CAS) where they work together in an adaptable and constantly changing manner. Keep in mind that your team affects other teams, and they affect yours.

9.2.1.2. • Self-learning

9.2.1.2.1. The DAC equips the teams with tools and practices that help them continuously improve their skills and knowledge. The Grow Team Members process goal diagram (in Chapter 22 of Choose Your WoW!) includes a decision point for Improve Skill and Knowledge. As you can see, in the diagram below, one strategy is Communities of Practice (CoPs), which enable a group of people who share an expertise to collaborate, develop ideas, and grow in their discipline. They essentially “band together” to learn from each other and share their knowledge.

9.2.1.3. • Self-improving

9.2.1.3.1. Experiment. The DAC also wants the team to be as productive as possible while learning from their successes and failures. A self- improving team can experiment with small changes in their work processes. They can keep the changes that work well and discard the ones that don’t. This approach is based on the Kaizen loop that encourages the team to implement small, incremental improvements that gradually evolve their way of working. Leverage new practices. Just as you want the teams to be self-learning, you also want them to use what they’ve learned to make improvements. That’s where guided continuous improvement (GCI) comes into play as it takes the Kaizen loop a step further. By leveraging the DA tool kit, you can teach the team how to find new practices or processes that are likely to address the issue that they are facing. As a result, the team can choose to experiment with the practices that are most likely to be effective and helpful. Once they get better at this process, they’ll succeed more often and improve faster. Share learning. Using GCI, the team leverages their knowledge to plan experiments, decide how to measure them, evaluate their outcomes for what works and what doesn’t, implement their findings, and share their learning with the rest of the organization. GCI is the key to a team becoming self-improving.

9.2.2. Temas' tools & practices

9.2.2.1. Collaboration

9.2.2.1.1. • Collaboration Not only should team members work together, but they should also collaborate with stakeholders. It’s important that the team clearly understands their stakeholders’ expectations to meet and exceed those expectations. This means that the team must consider the impact that their work may have on other teams. Part of being a self-learning team is understanding other teams’ ways of working and adapting accordingly when appropriate (in other words, being Enterprise Aware). Collaboration also gives teams the opportunity to learn from one another. • Voting Techniques Part of collaboration is working together to reach a decision. Voting techniques (Griffiths, 2017) and guidelines can facilitate the process of arriving at a decision. Here are a few techniques you may want to consider.

9.2.2.2. Voting

9.2.2.2.1. Simple voting “For” or “against” by a show of hands is easy, but it misses the opportunity for decision refinement. Instead, it strives for a result too quickly and can miss a better alternative. Using thumbs up, down, or sideways is a much faster way of achieving a simple vote. People with a thumb sideways are asked why they could not make up their minds. This approach is quicker than polling everyone for input, as most people will have no concerns and just want to move forward. Using Highsmith's Decision Spectrum, team members are asked to indicate, with tick marks, where on a spectrum (from “fully in favor” to “mixed feelings” to “No, veto”) they feel about the decision at hand. This technique allows people to indicate support for a decision and air their reservations at the same time. The Fist of Five method combines the speed of “thumbs up/down/sideways” with the degrees of agreement from the decision spectrum. Typically, holding all five fingers up shows your full agreement with the decision, while holding up only a fist shows that you fully object to the decision. Between these two extremes are lesser degrees of support. Holding up one finger shows that you have serious concerns about the decision but will vote to move it forward. Two fingers indicate a vote to move forward, with some reservations. As a coach, it’s important to have guidelines in place that allow voters with reservations to express their concerns before a final vote is reached.

9.2.2.3. GCI

9.2.2.3.1. GCI extends the Kaizen loop strategy to use proven guidance from the DA tool kit to help teams identify techniques that are likely to work based on their context. This increases the percentage of successful experiments, and as a result, increases the overall rate of process improvement. As a DAC, teach the team the steps of GCI to eventually go through this process on their own and become a self-learning and self-improving team. Through collaboration and decision-making techniques, the team can decide which option to try and then determine whether to adopt or abandon it.

9.2.2.4. DA toolkit

9.2.2.4.1. Show the team how to use the tool kit to improve their way of working or address a challenge they are facing. The tool kit provides choices to help the team make decisions that are best for them. By experimenting with proven strategies and techniques, they can streamline their processes and continue evolving and improving. Ensure that the team has the time they need to experiment and learn from their successes and failures.

9.2.2.5. Retrospectives

9.2.2.5.1. Running retrospectives allows for a team review of lessons learned and for the team to decide how they want to move forward as they continue to self-improve and evolve.

9.2.2.6. CoP or guilds

9.2.2.6.1. Give teams opportunities to share their knowledge and learn from each other across teams. o Set aside time that allows team members to build their professional skills by attending CoPs, guilds, and skill shares. It’s important that team members understand that it’s okay to take time away from the current sprint/iteration to attend learning opportunities. Management should build time into the project schedule to accommodate this. o Measuring outcomes can help determine the effectiveness of a training program. For example, a team member who is highly skilled in one area trains others on the team. As a result, the team can increase their velocity by getting more work done in the next iteration. Being able to show measurable results is a key indicator of the effectiveness of the training.

9.2.2.7. Capabilities

9.2.2.7.1. • Make decisions together as a team (collaborate). • Use guided continuous improvement to improve their processes and learn from their successes and failures (GCI). • Take advantage of learning opportunities, such as CoPs (self-learning/self-improving). • Use the DA tool kit as a knowledge base to find potential strategies and practices that can improve their way of working. Then, they can become a semi-autonomous, self-sustaining team.

9.2.3. Collaborative Decision-Making

9.2.4. groan zone

9.2.4.1. In between divergent thinking and convergent thinking is the groan zone. The groan zone comes into play when the team finds themselves in the uncomfortable area of “now we have all great ideas,” but “how do we decide which one to move forward with?” The groan zone is a term that comes from Sam Kaner’s Diamond Participation model, shown above. The convergent zone is the phase where the team evaluates their options, based on facts. Creative thinking is not part of this process. From convergent thinking comes a collaborative decision. Collaborative decision-making may also come into play when deciding which option to choose from in the DA tool kit.

9.2.5. Common Barriers to Decision-Making

9.2.5.1. • Lack of explicit guidelines on how to make a decision.

9.2.5.2. • The team is not empowered to make certain types of decisions.

9.2.5.3. • Lack of direction from management.

9.2.5.4. • Lack of psychological safety.

9.2.5.5. • Not enough diverse opinions.

9.2.5.6. • The team is caught in the groan zone.

9.2.5.7. • Certain team members don’t like making decisions. More dominant members are happy to make all the decisions.

9.2.5.8. • Not embracing diversity.

9.2.5.9. The team may be resistant to diverse opinions.

9.2.6. How to Help Teams Move to Convergent Thinking

9.2.6.1. Active listening

9.2.6.2. Emotional Intelligence (EQ)

9.2.6.3. Collaborating With External Teams to Explore New Ways of Working

9.2.6.4. Using the DA Tool kit to Identify a Baseline and Goals

9.2.7. Guided Continuous Improvement (GCI)

9.2.7.1. 1. Identify problem. Determine what the problem is. Identify potential solution(s). Use the DA tool kit to find a potential solution(s) with which to experiment. *If you get better at this, you will succeed more often and improve faster. 2. Try the solution(s). Run an experiment. Some experiments will fail. You will learn something, but they are still a failure. Failing fast is fine, but succeeding early is better. 3. Assess effectiveness. Determine how well it worked. 4. Adopt what works. Abandon what does not work. 5. Share learnings. Share lessons learned with the rest of the organization.

9.2.8. Measuring Outcomes

9.2.8.1. • Lead time • Cycle time • Throughput • Work in process (WIP) • Incidents • Colleague engagement and Net Promoter Score ® (NPS ®)

9.2.9. Coaching agreement

9.2.9.1. • Develop separate coaching agreements. • Remember the qualities of a good DAC. • Create semi-autonomous, self- organizing teams (importance of being self-organizing, self- improving, self-learning). • Develop peer and mentor relationships outside the workplace.

9.2.9.2. Team Coaching Canvas

9.2.9.2.1. Purpose Scope Team members Commitments Impediments Key action items. Workflow. Involve WoW

9.2.9.3. Working Agreement Items to Consider:

9.2.9.3.1. We will not look to the coach to do work or facilitate a situation just because we think it is hard. We will take guidance from the Coach, but are free to challenge when we don't understand the value. We will all be responsible for creating a safe place to learn, experiment, and grow as we adopt this new WoW. The Coach supports us but WE are responsible for our success, not the Coach. We will choose and own our way of working. We will use information radiators / visual controls. We will respect working agreements (coaching agreement, team norms, DoR, DoD, etc.) We use and keep the Kanban boards up to date. We make our work and the work flow visible to the team and outside the team. We will demonstrate the work frequently and on-demand as asked. We solve critical challenges together. Conduct frequent Retrospectives. We use Kaizen loops for continuous improvement opportunities. Each iteration we will include at least one improvement item. Team Leads shadow the DAC. Teams will share their WoW and outcomes - team will not blindly copy another team's WoW.

9.3. Change

9.3.1. Why Do People Resist Change?

9.3.1.1. • Job security/status/authority

9.3.1.2. • Working conditions

9.3.1.3. • Loss of freedom

9.3.1.4. • The belief that the change doesn’t make sense

9.3.1.5. • Excluded from the change initiative

9.3.1.6. • Perception of criticism

9.3.1.7. • Lack of respect for the leaders making the decisions

9.3.2. When Do People Accept Change?

9.3.2.1. • When change is seen as a personal gain in security, money, authority, status or prestige, responsibility, working conditions, and achievement, people are more likely to accept it. • When an existing process becomes less burdensome (for example, eliminating the need to write lengthy requirements specifications with developing user stories that require less documentation.) • When it provides a way to gain a new marketable skill that could lead to a promotion or offers greater job security. • When people are consulted, they feel invested in the change and are more likely to accept it. • They agree with the change, the reason behind it, and like and respect the person leading the initiative.

9.3.3. Stages of dealing with change

9.3.3.1. Denial Anger Bargaining Depression Acceptance

9.3.4. Concerns Different Stakeholders Have About Change

9.3.4.1. Executives and Risk of failure, unprecedented practices, project sponsors counter-intuitive planning approaches Managers Fear loss of role, loss of control Development team Resistance to changes being forced upon them by “management” User community Fear of not getting all the required features and concerns around quality in early iterations Supporting groups Concern over apparent lack of control, continual requests for involvement, and lack of a visible endpoint

9.3.5. Levels of Resistance and Associated Mitigation Strategies

9.3.5.1. Level 1. Confusion Create a newsletter, discussion forums, websites (lack of information) Provide opportunities for feedback

9.3.5.2. Level 2. Resistance to change (fear of loss) Build strong working relationships Maintain a clear focus Embrace resistance, provide acknowledgment Listen with an open mind Stay calm to stay engaged

9.3.5.3. Level 3. Entrenched resistance (beyond the changes at hand) Continually work on building relationships Begin small Candid conversation is vital Support yourself Get people deeply involved in changes that affect them Be prepared for setbacks

9.3.6. Consider Organizational Change and Its Impact on the Team

9.3.7. Supporting the Team Through Change

9.3.7.1. The change curve.

9.3.7.1.1. Now, let’s look at the change curve below adapted from the Satir Change Model (Smith, 1997) (Satir, 1998). This model gives you a perspective on some of the emotions people go through as they learn a new process or way of working. In the early stages, team members are excited about what lies ahead. Then as they gradually start learning, there is a dip in the curve (confusion/loss) and some ups and downs occur (turmoil and despair) in the level of acceptance when they begin to realize that the change is difficult and may not be working as they hoped (maybe, agile is not for us). In the turmoil/despair stage, team members need your support and encouragement. Reassuring them that their feelings are normal can help them overcome these emotions and move on to the next stage of growth and confidence. From there, they can advance to mastery (the peak of the curve), having learned a new skill or process, and are now better off for it.

9.3.8. Creating psychological safety (DA Promise)

9.3.9. Psychological safety and change (LeBow, 2021)

9.3.10. Four stages of psychological safety

9.3.10.1. In Timothy R. Clark’s book, The 4 Stages of Psychological Safety: Defining the Path to Inclusion and Innovation (2020), he describes psychological safety as “a progression through four developmental stages based on respect and permission.” He defines respect as one’s ability to accept somebody for who they are and appreciate their skills and abilities, even if they don’t necessarily agree on everything. He refers to permission as something granted by a group that allows someone to contribute and be a part of the team. It also means being permitted to influence others on the team to which you belong. When there is respect and permission, people tend to advance more readily from one stage to the next.

9.3.11. Psychological safety model (Clark, 2020)

9.3.11.1. Clark lays out psychological safety in a model with two dimensions (respect and permission) and four stages (inclusion safety, learner safety, contributor safety, and challenger safety). Each stage builds on the next. Let’s look at each of the stages and how they relate to psychological safety in the workplace. You can use this model to assess the status of a team member's level of psychological safety.

9.3.11.2. • Stage 1: Inclusion Safety We all want to feel that we fit in and that others accept us. That’s part of our human nature. With inclusion safety, the team has welcomed us into the fold. It’s up to you, as the coach, to ensure that everyone is included in discussions and decision-making. • Stage 2: Learner Safety Once we feel included and part of the team, we have the confidence to learn, experiment, and grow. In this stage, we feel safe asking questions, getting feedback, trying things out, and even making a few mistakes without the fear of judgment or criticism. Encourage the team to take risks, experiment, and learn new things. Acknowledge those who do. • Stage 3: Contributor Safety In this stage we are not just learning but are making a difference. We feel comfortable sharing our knowledge with the team. Contributor safety leads to innovation and creativity. Encourage everyone to participate so that all voices can be heard, not just the loudest ones. • Stage 4: Challenger Safety In this stage, we have reached the highest level of psychological safety. We feel safe to challenge the status quo, ask why things are done a certain way, and suggest ways to make something better without fear of jeopardizing our position. To quote Timothy Clark (2020), “Innovation is the disruptor of the status quo.”

9.3.12. Paternalism and exploitation

9.3.12.1. • Paternalism occurs when a leader affords someone respect but gives them no permission to experiment and grow. In this context, the leader micromanages the team member, essentially restraining the individual from working to their full potential. • Exploitation is another deterrent to a psychologically safe environment. In this context, a manager or team member grants someone permission but does not afford them respect. Here, the individual’s psychological safety falls into the “gutter,” as they feel their contributions and talents are not valued.

9.3.13. Analyze each team member’s openness to change

9.3.13.1. Inclusion safety Learner safety Contributor safety Challenger safety What would you do to help this person?

9.3.14. Using the Coaching Conversation to Promote Acceptance of Change

9.3.15. using DA toolkit

9.3.15.1. Sustaining a team while they are adapting to change

9.3.15.2. Improving team members’ skills and knowledge

9.3.15.3. Helping teams to continuously improve

9.3.15.4. Communicating change and ensuring production readiness

9.3.16. Change Model

9.3.16.1. Implementing change using the Brightline® Transformation Compass

9.3.16.1.1. The Brightline® Transformation Compass lays out five building blocks for change: 1. The North Star A crisp, inspiring articulation of the vision and strategic objectives for change. Create a compelling case for change that the team can understand and embrace. Explain what the future will bring and the importance of change. Having a vision at the team level and the immediate organizational level helps the team make more intentional decisions that align with their goals and values. 2. Customer insights Customer insights and customer efforts impact others in the organization. The team must understand both their immediate customer (who consumes their work output) and the ultimate customer being served by the organization. 3. Transformation operating system This includes a flat, adaptable, and cross-functional organizational structure that enables rapid decision-making. Encourage cross-team collaboration to sustain the pace of the change. Remove any roadblocks that impede team progress. Set clear targets for the team to achieve and make them measurable. Encourage the team to be proactive and use GCI on a regular cadence to find better ways of working. Improving existing processes is a form of change.

9.3.16.1.2. 4. Volunteer champions Identify, recruit, and empower key team members to champion the change. They can be the influencers who get other team members on board. 5. Inside-out employee transformation A set of tools to make the transformation personal for your employees, connecting their aspiration to the North Star and to your customers.

9.3.16.2. Key concepts for transformation

9.3.16.2.1. • Keep people engaged and involved in the change process to gain their acceptance. • People are central to the success of any change. • Change doesn’t fail because of the strategy or issues with technology. Instead, it fails because you, as a coach, didn’t win your team members’ hearts and minds.

9.3.16.3. Implementing change – strategic approach vs. human approach

9.3.16.4. Differentiating a Change Model From a Coaching Strategy

9.3.16.4.1. A change model is a strategic approach to move an organization from where it is today to where it wants to be in the future to grow and evolve. It is a significant change that may take several years to implement. A change model includes steps or phases that provide guidance and structure to implementing the change. When selecting a change model, leadership should consider one that is fit-for- purpose in that it complements the existing organizational culture.

9.3.16.4.2. A coaching strategy is an approach to address a current situation. It’s more short term. You may recall that we talked about how people are less willing to accept change when they feel it’s forced on them. If you adopt a “pull” strategy, the team has the opportunity to identify challenges and come up with potential improvement. Then they are more willing to experiment with potential solutions and ultimately accept the change that addresses an issue. This is a better approach than forcing change (push strategy).

9.3.16.5. Managing the change adoption speed

9.3.16.5.1. Team members progress through change at different adoption speeds. As shown in the diagram below, some will embrace change and want to charge ahead. We refer to these as the “keeners.” In contrast, others will be more skeptical and tend to lag. We refer to these as the “laggards.” As a coach, you’ll want to keep your team members engaged during a transition to a new way of working.

9.3.16.6. Managing a diverse group of people through a change

9.3.17. Workplace Culture and Coaching

9.3.17.1. The Schneider culture model (the four C’s of culture)

9.3.17.1.1. • Collaboration shares ideas and works closely with one another. • Control thrives on process, order, stability, and maintaining control. The culture is hierarchical, and problems are dealt with swiftly without much consensus. • Competence serves as experts in what they do. • Cultivation seeks to grow, learn, and evolve.

9.3.17.2. Additional points about culture

9.3.17.2.1. • By being aware of the team’s cultural attributes, you can recommend changes in practices that they are more likely to consider. • While you cannot change culture directly, you can impact behavior by helping the team develop an awareness of more effective ways of working. • Understanding the team’s cultural attributes will allow you to tailor your approach to motivate them in such a way that they’ll be more accepting of change.

9.3.17.3. Five key cultural attributes

9.3.17.3.1. focused

9.3.17.3.2. oriented

9.3.18. Embracing Diversity and Inclusion

9.3.18.1. A safe, inclusive environment

9.3.18.2. Diversity on teams

9.3.18.3. Types of diversity

9.3.18.3.1. • Demographic diversity This is gender, race, sexual orientation, and so on. • Experiential diversity This is our affinities, hobbies, and abilities. • Cognitive diversity This is how we approach problems and think about things.

9.3.18.4. Unconscious bias

9.3.18.5. Inclusivity diversity

9.3.18.5.1. • Create a culture of psychological safety and acceptance of diversity. • Collaborate proactively.

9.3.19. Limiting What the Team Works On

9.3.20. Experimenting with potential solutions

9.3.21. Visualizing Impediments

9.3.21.1. 1. Impediments backlog

9.3.21.1.1. o List problems and obstacles that are hindering their progress on a project; and o Provide a “to do” list of blockers that the scrum master, servant leader, or even you, as the agile coach, need to remove or mitigate to keep the project on track.

9.3.21.2. 2. Impediments board

9.3.21.2.1. After identifying impediments in a backlog, the next step is to add them to a task board that is accessible to all team members, stakeholders, and project leaders. The sticky notes in the example below represent constraints or blockages. Here, “identified problems” is the list of items from the impediments backlog. Entries under “to be solved” are impediments that the team leader or coach has identified as needing to be addressed. The “in progress” column designates the barriers that the leader is currently attempting to remove. Items in the “settled” column show impediments that have been fixed or resolved.

9.3.21.2.2. • Impediments should be identified, tracked, and addressed. • The Address Risk goal diagram lists competencies. • Use impediments boards to proactively track and manage. • Outstanding impediments have cost. Temporary workarounds reduce cost.

9.3.21.2.3. Impediments How we can eliminate them Why we don't. Actions we've decided to take.

9.3.21.2.4. Root cause analysis

9.3.21.3. 3. Task board showing blocked items

9.3.21.3.1. o Another way of visualizing blocked items is to arrange them on a board that shows which work items have dependencies and which ones don’t. o This board draws attention to where there are dependencies and issues. o It also helps leaders manage the flow of work more effectively when dependencies are visible.

9.3.21.4. 4. Blocked story aging

9.3.21.4.1. Another way to visualize impediments is to show the cause of the blockages. In the example below, the green ENV markers indicate that the team is encountering an environmental constraint (perhaps, the team cannot test their latest updates because the testing environment is not ready). The purple markers indicate the vendor is the blocker. Maybe, there’s a delay with the delivery of equipment from the supplier. Finally, tick marks indicate the number of days (or age) an item (or story) is still blocked. Every day at the standup meeting, the team adds a tick mark to items that are still blocked.

9.4. Coaching teams in context of their org

9.4.1. Disciplined Agile Enterprise (DAE)

9.4.1.1. • Agile

9.4.1.2. • Complex adaptive systems

9.4.1.3. • Unique

9.4.1.4. • Learning organizations

9.4.1.5. • Responsive

9.4.1.6. • Centered around value streams

9.4.2. The Disciplined Agile Enterprise (DAE) Layer

9.4.3. DAE process blades

9.4.3.1. • Enterprise architecture:

9.4.3.2. • People management:

9.4.3.3. Information technology:

9.4.3.4. • Asset management: • Transformation: • Finance: • Vendor management (procurement): • Legal:

9.4.4. Process blades shared between the DAE and Value Stream layers

9.4.4.1. • Research & development (R&D): • Business operations: • Strategy: • Governance: • Marketing: • Continuous improvement:

9.4.5. Enterprise Awareness

9.4.5.1. 1. Individual awareness 2. Team awareness 4. Enterprise awareness 5. Ecosystem awareness

9.4.5.2. What It Means to Be Enterprise Aware

9.4.5.2.1. • Work closely with enterprise professionals. • Adopt and follow enterprise guidance. • Leverage enterprise assets. • Enhance your organizational ecosystem. • Adopt a DevOps culture. • Share learnings. • Adopt appropriate governance strategies. • Implement open and honest monitoring.

9.4.5.3. Why Is Enterprise Awareness Important?

9.4.5.3.1. • Higher levels of productivity. They are less likely to reinvent the wheel. • Quicker times to deployment/market. They have less work to do. • Higher return on investment (ROI). They have less work to do. • Higher levels of quality. They follow common conventions and reuse what works.

9.4.5.4. Challenges to Enterprise Awareness

9.4.5.4.1. 1. The cultural challenge within the agile community that some “agile purists” perceive awareness as unnecessary overhead; and 2. Enterprise professionals often don’t understand how to work effectively with agile teams.

9.4.6. Why is the coordinate activities process goal important?

9.4.6.1. • Supports effective collaboration • Supports autonomy • Working agreement within the team • Working agreement with other teams

9.4.6.2. Questions the Coordinate Activities Goal Diagram Answers

9.4.6.2.1. • How will we share information within the team? • Who can update the artifacts created by the team? • How will we coordinate within the team? • How can we facilitate working sessions, potentially with large or diverse groups? • If we’re part of a larger team, how will we coordinate within it? • How will we work with enterprise teams? • How will we coordinate our release/deployment with the rest of the organization? • How will we collaborate with geographically distributed team members?

9.4.7. Why Should Become a Generalizing Specialist?

9.4.7.1. • Has one or more technical specialties (e.g., project management, database administration, etc.) • Has at least a general knowledge of software development • Has at least a general knowledge of the business domain in which they work • Actively seeks to gain new skills in both their existing specialties as well as in other areas, including both technical and domain areas

9.4.7.2. • Improved communication and collaboration • Less documentation • Improved flexibility • Less risk • Fewer bottlenecks

9.4.8. What Is an Enterprise Roadmap and How Can It Be Effective?

9.4.8.1. Enterprise roadmaps define the organization’s technical or business direction. They can provide a detailed or more summarized look at the business.

9.4.8.1.1. Detailed or concise

9.4.9. What Are the Trade-Offs of Each Organization-Level Coordination Strategy?

9.4.9.1. • Coordinate within the team

9.4.9.1.1. Within a team, coordination between individuals occurs in a continuous manner as a by- product of collaboration. There are three characteristics, or time frames, to consider when coordinating with team members:

9.4.9.1.2. o Look-ahead. Teams consider work items that they will be working on, exploring them in enough detail so they understand what the work entails. This is sometimes called backlog grooming or refinement. Doing this allows you to avoid waste from waiting or poor information sharing because the work item becomes “ready” to be worked on.

9.4.9.1.3. o Just in time (JIT). Team members naturally coordinate through conversations and nonsolo work. Teams identify work to be done and who may be doing it. This kind

9.4.9.1.4. of planning provides increased acceptance because it is the plan they have devised. The trade-off is that work items must be sufficiently explored before any work agreement is put into place.

9.4.9.1.5. o Look-back. This sort of coordination occurs via status meetings, status reporting, and trailing metrics.

9.4.9.2. • Coordinate across program

9.4.9.2.1. A program is a large team that has been organized into a team of teams. Large teams are typically formed to address complex problems. As a team grows, a common strategy is to split it up into a collection of smaller subteams to reduce the coordination overhead required. Ideally, each of the subteams are mostly whole, with enough people with the required skills to accomplish whatever purpose they have signed up for. Although there are many heuristics for when a team needs to be split, such as Miller’s law (teams should be 7 +/− 2 in size) or the two-pizza rule (if you can’t feed the team with two pizzas, it’s too large), the fact is there are no hard and fast rules.

9.4.9.2.2. There are several ways to coordinate across a program, and each comes with its own positives and negatives.

9.4.9.2.3. o Create an architecture owner team. Architecture owners from each of the subteams work together to guide the development of the architecture for the overall program. This team self-organizes and holds working sessions as needed to evolve the architecture for the program. Large programs may have a chief architecture owner to lead the architecture owner team. Doing this shares knowledge and vision among architects, allowing the architecture to evolve as the subteams learn. This is more necessary early in the project life cycle. It is a good way to share knowledge and experiences among each other and provides a coaching opportunity. This is more important as more teams become involved in a project.

9.4.9.2.4. o Common cadences. The subteams have iterations that are the same length. This makes system integration across teams easy to coordinate. It is effective at coordinating medium-sized batches of work across teams. Subteams are forced to have the same iteration length, and iterations in general, whether it makes sense for them or not. This is difficult when people are assigned to multiple subteams because critical ceremonies overlap.

9.4.9.2.5. o Coordination meetings/scrum meetings. The team gets together to quickly coordinate their work for the day, in a meeting that typically takes 10–15 minutes.

9.4.9.2.6. o Visualize work. The team visualizes their workflow and the work they are doing via a task board or Kanban (scrum) board. This process can be applied via sticky notes on a wall or digital tools such as Jira, Leankit, or Jile. These boards are one type of information radiator.

9.4.9.2.7. o Divisor cadences. The subteams have iterations with lengths divided up as part a larger coordination cadence. This provides explicit points in time to coordinate large batches of work, and flexibility to teams to vary their iteration length (or to not have iterations at all). It also increases the cadence for integrating “done” releases, which in turn increases the cycle time to delivery.

9.4.9.2.8. o Facilitated working sessions. Working sessions to explore stakeholder needs, to work through architecture or design strategies, or to plan the next increment of work are often needed on agile teams. When many people are involved, or when

9.4.9.2.9. there is a contentious issue to work through, these sessions should be facilitated by an outsider (preferably someone with facilitation skills). These sessions increase the chance that the session will produce value. They require preparation and follow-up work, and it can be difficult to find experienced facilitators. Costs are easily measured, but the benefits are difficult to measure, which causes difficulty in justifying it.

9.4.9.2.10. o Open spaces. This is a facilitated meeting or multiday conference where participants focus on a specific task or purpose. They are participant driven, with the agenda being created at the time by the people attending the event. This is also known as open space technology (OST) or an “unconference.”

9.4.9.2.11. o Product coordination team. The team leads from each subteam work together to drive team coordination efforts. They self-organize and meet when appropriate to coordinate among themselves, such as a daily scrum of scrums (SoS), decreasing the chance that interteam issues get out of hand. They provide an opportunity to address people management issues within the program and create a supporting mechanism for the program manager, which is important as more teams become involved. It also provides an opportunity to share experiences between team leads and to coach one another.

9.4.9.2.12. o Product owner team. The product owners from each subteam work together to manage requirements and work dependencies across subteams. They will self- organize and run working sessions, potentially several a week, to coordinate their efforts. Large programs may have a chief product owner to lead the product owner team. This is similar to LeSS, which has a product owner for the overall program and business analysts on each subteam. This ensures that requirements are managed effectively across subteams. It provides an opportunity to reduce risks associated with requirements dependencies, share experiences between team leads, and coach one another. On the negative side, it is one more responsibility for an already busy product owner. The greater the number of teams, the more important this becomes.

9.4.9.2.13. o Program manager/coordinator. A large program often has someone in a management role to oversee and guide the entire program. This person typically coordinates the efforts of the architecture owner, product owner, and product coordination teams. They manage relationships with vendors and monitor the overall budget and schedule. This role oversees explicit governance of the program and reporting to leadership, which is typically necessary in a large program. It provides explicit financial governance for the program, which is important since many programs can incur substantial costs.

9.4.9.2.14. o Scrum of scrums (SoS). Someone from the coordination meeting of a subteam (a scrum) attends the coordination meeting across all teams within the program (the scrum of scrums). This is a great solution for up to 5–6 teams but tends to fall apart given the increased need for technical and requirements coordination as a program grows.

9.4.9.3. • Coordinate release schedule.

9.4.9.3.1. In organizations with multiple solution delivery teams working in parallel, it will be

9.4.9.3.2. important to coordinate all release schedules to avoid the potential for interteam conflicts.

9.4.9.3.3. o Continuous deployment (CD)/release stream. The solution is automatically deployed through all internal testing environments and into production without human intervention. It is a low-risk, inexpensive way to deploy into production,

9.4.9.3.4. requiring a continuous integration (CI)/CD pipeline and sophisticated automated regression testing. CD enables the team to receive continuous feedback from end users. It is a practice that enables the team to adopt either the Continuous Delivery: Agile life cycle or the Continuous Delivery: Lean life cycle.

9.4.9.3.5. o Regular releases/release train. This solution is released on a regular schedule (e.g., quarterly, bimonthly, monthly, biweekly) into production. The release schedule becomes predictable, thereby setting stakeholder expectations and making it easier for external teams to coordinate with our team. It is a step toward a continuous delivery (CD) approach, particularly when the releases are predictable. The cycle time from idea to delivery into production may not be enough, particularly with longer release cycles (such as quarterly releases).

9.4.9.3.6. o Release windows (release slots). These are defined dates and times when teams are (not) allowed to release into production. Dates and times when teams are not allowed to release are sometimes called release blackout periods. This method sets expectations and enables coordination between potentially disparate teams, enabling teams to identify slower, low-risk periods for deployment. Scheduling into a release window needs to be coordinated across teams.

9.4.9.3.7. o Unique project releases. This occurs when a solution is released into production as a single release. Any subsequent releases are planned as separate efforts. This is often driven by commitments to customers or because of regulatory needs. Unique project releases are typically risky if a team has little or no experience in releasing a solution into production. Typically, changes identified by users can be very expensive to implement. Deployment often includes expensive and slow manual processes. However, this method could be appropriate for infrequent solutions that are truly one-release propositions.

9.4.9.3.8. o None. There is no coordination of releases across delivery teams. It works well for a small number of teams, or when there are few dependencies between systems.

9.4.9.4. • Coordinate between locations.

9.4.9.4.1. When a team is geographically distributed, there needs to be coordination between locations. We consider a team that is spread across floors within the same building, across buildings, or in different cities to be geographically distributed.

9.4.9.4.2. o Move team to a single location. When teams are relocated to a single location it can provide increased opportunities for communication and collaboration. Given these challenging times, it can produce serious morale issues if team members prefer working from home or remote locations. When such changes are about to occur, it may be desirable to introduce individual or team coaching.

9.4.9.4.3. o Gather physically at critical times. People come together at a single location, typically to have a working session to work through an important issue such as deciding on a strategy for upcoming work. This strategy allows you to make critical decisions quickly with a wider range of collaboration. It builds relationships between people who are working in disparate locations, enabling them to interact more effectively in the future with some planning, facilitation, and follow-up. The drawbacks include some people may not be able to travel without incurring

9.4.9.4.4. potentially high costs to the organization, travel time, and out-of-pocket expenses for the staff member.

9.4.9.4.5. o Ambassadors. An ambassador travels between locations, working at the location for a period of time before returning to their “home location.” They maintain communication between work sites, helping to build relationships between people at disparate sites. It is easy to measure the costs but difficult to measure the benefits, making it hard to justify. The team will need to leverage collaborative tools when not together.

9.4.9.4.6. o Boundary spanners. They are responsible for coordinating communication between sites, looking for opportunities to help remote staff work with one another more effectively when the situation requires. They improve the chance that people communicate with others at disparate locations. Once relationships between people are built, the need for this lessens, but likely doesn’t disappear. They work well with ambassadors and leverage collaborative tools to facilitate the collaboration.

9.4.9.4.7. o Adopt collaborative tools. Teams can adopt collaborative tools (such as chat software, videoconferencing, or discussion group software) to interact with one another. This is a common strategy that can improve communication between sites. These tools often enable persistence of information, although it can have too much signal noise compared to purposeful documentation such as roadmaps, but they are not as good as face-to-face communication.**

9.4.10. Scaling/ Complexity Factors

9.4.10.1. • Leadership brings in the coach but may not understand the implications. • Leadership often gets in the way. • A DAC often deals with management. • Context Counts and Choice Is Good can be difficult.

9.4.10.2. • Empower teams to reach their goals by utilizing a WoW that best suits their needs. • Work with leadership and others to gain support. • Set a framework for teams to self-organize and self-learn.

9.4.11. The Coaching Conversation to Promote Change

9.4.11.1. • Listen actively. • Be empathetic. • Ask questions to gain more insight. • Avoid offering a solution. • Get a commitment. • Schedule a follow-up meeting.

9.4.11.2. • Context counts. • Be pragmatic. • Collaborate proactively. • Change culture by improving the system.

9.4.12. Coach collaboration

9.4.12.1. Coaches can assist several teams to help them collaborate. Teams’ unique perspectives and priorities may not align. Help teams through conversations to choose new WoWs.

9.5. Coaching teams through their transformation journey

9.5.1. The Difference Between Transformation and Change

9.5.1.1. Change Transformation Directed toward a goal Actions are driven by the desire to improve the past Depends on external influences Not all change is transformational Entails modifying actions to achieve results

9.5.1.1.1. Directed by a goal Actions are directed toward the future Driven by internal efforts Transformation always includes change Entails modifying beliefs, leading to actions that naturally achieve results

9.5.2. Transformation is a series of planned, coordinated, intentional changes that get you closer to the set goals.

9.5.3. Traditional Organizational Structure

9.5.3.1. • Are team members and managers competing for resources with other teams, rather than focusing on their operations? • Do other teams avoid collaborating to resolve problems across their functional and political boundaries? • Is there a growing conflict between management and staff concerning areas of autonomy and control?

9.5.4. What Transformation Looks Like on Team and Cross-Team Levels

9.5.4.1. To become transformative, teams must become self-organized and empowered:

9.5.4.2. • Old management approaches, such as taking orders and micromanaging team members, must give way to individual team autonomy, trust, and reinforcement.

9.5.4.3. • Coaches must build teams around motivated individuals who can be nurtured within their environment. This, in turn, can help move team members to support one another and keep each other honest and accountable.

9.5.4.4. Transformation efforts can often take many months to achieve and must be a part of a planned effort using small incremental steps.

9.5.4.4.1. To become transformative, teams must become self-organized and empowered:

9.5.4.4.2. • Old management approaches, such as taking orders and micromanaging team members, must give way to individual team autonomy, trust, and reinforcement.

9.5.4.4.3. • Coaches must build teams around motivated individuals who can be nurtured within their environment. This, in turn, can help move team members to support one another and keep each other honest and accountable.

9.5.4.4.4. Transformation efforts can often take many months to achieve and must be a part of a planned effort using small incremental steps.

9.5.5. Three Phases of Transformation

9.5.5.1. • Ending. The initial transformation process can generate much uncertainly, angst, and resistance among team members and managers. • Neutral zone. As the process moves through the transition phase, it can also elicit a new sense of anticipation, still with some uncertainty about what will replace the old ways. • New beginning. Once the final agility stage has been achieved, a sense of accomplishment and awareness typically replaces the skepticism and resistance that anticipated the transformation process.

9.5.6. Attributes That Develop in the Transformation Process

9.5.6.1. • Self-learning

9.5.6.1.1. Disciplined Agile team members tend to be cross-functional, “generalizing specialists” who have attained the skills and resources necessary to achieve success in their profession and the domain they are working in.

9.5.6.1.2. Having team members with more robust sets of skills is a critical step toward becoming a self-learning team. This effort can help teams avoid dealing with outside specialists and consultants, thus opening a clear path for members to choose their own way of working.

9.5.6.2. • Self-organizing

9.5.6.2.1. DA teams also have the authority and flexibility to choose their own way of working (WoW), developing internal roles and responsibilities that work best for them. When achieved, this effort can greatly improve interactions among team members, but it can also have a positive ripple effect on how team members relate to other teams.

9.5.6.2.2. Developing semi-autonomous, cross-functional teams can ultimately lead to a transformative organization.

9.5.6.3. • Self-improving

9.5.6.3.1. Teams and organizations often go through periods of instability that can force them to

9.5.6.3.2. seek ways to improve what they are doing. Conversely, DA teams regularly and proactively look for ways to improve their processes.

9.5.6.3.3. Choosing or revising their current way of working doesn’t always guarantee improvement. DA teams use guided continuous improvement (GCI) to try out new ways of working, based on proven strategies, and then learn from their successes and failures.

9.5.7. Disciplined Agile Teams Are Transparent and Collaborative

9.5.8. How Team Transformation Contributes to Organizational Transformation

9.5.9. The Discipline Agile Coach Agreement

9.5.9.1. 1. Who needs coaching?

9.5.9.1.1. The initial answer to this question can often shift as the coaching exploration progresses. However, knowing who needs help right now is critical to understanding where to focus one’s energies. Will the coaching cover key individuals, a single team, multiple teams, or an entire organization? Coaching individuals or a small team typically requires less effort (e.g., workshops and observations) than working with a larger group.

9.5.9.2. 2. What specific kinds of coaching approaches are required?

9.5.9.3. 3. Where is the help needed the most?

9.5.10. Forming Organizational Alliances

9.5.11. Seeking Interaction With Mentors and Peers Outside of the Workplace

9.5.12. Engagement preplanning process

9.5.12.1. • Identify the challenges and competencies in planning. • Use a tool to work toward agile transformation on team and cross-team levels. • Complete the four steps of the DAC Engagement Preplanning Process.

9.5.12.2. 1. assessment, challenges and competencies 2. Improvement opportunities. 3. DAC playbook 4. Improvement work board.

9.5.12.2.1. • Assess the competencies and identify the current challenges.

9.5.12.2.2. (DAC Assessment Board)

9.5.12.2.3. • Create the DAC Playbook containing the backlog of competencies and actions for improvement.

9.5.12.2.4. • Populate the improvement work board.

9.5.12.3. • Examine the impact of not attending to a lack of specific competencies. • Optimize flow. • Change culture by improving the system. • Adopt measures to improve outcomes.

9.5.13. Lean Agile Procurement (LAP)

9.5.13.1. • Reduced lead time of sourcing. • Most important customer problems solved first. • Minimized risk of working with new partners.

9.6. Miro links

9.6.1. Module 1 & 2

9.6.2. Module 3

9.6.3. Module 4