Project Management

Disciplined Agile

by , , , , , ,
This blog contains details about various aspects of PMI's Disciplined Agile (DA) tool kit, including new and upcoming topics.

About this Blog

RSS

View Posts By:

Tatsiana Balshakova
Mark Lines
Mike Griffiths
Scott Ambler
Bjorn Gustafsson
Curtis Hibbs
James Trott

Past Contributors:

Joshua Barnes
Michael Richardson
Daniel Gagnon
Valentin Tudor Mocanu
Kashmir Birk
Glen Little
Klaus Boedker

Recent Posts

DA 5.6 is released

Disciplined Agile 5.5 Released

Choose Your WoW! Second Edition Is Now Available

Requisite Agility applied in Project Management

Disciplined Agile and PMBoK Guide 7th Edition

Categories

#ChoiceIsGood, #ChooseYourWoW, #ConsumableSolution, #ContinuousImprovement, #CoreAgilePractices, #experiment, #Experimentation, #GuidedContinuousImprovement, #Kaizen, #LifeCycles, #ProcessImprovement, #TealOrganizations, Adoption, agile, agile adoption, Agile Alliance, Agile Business Analyst, Agile certification, agile data, agile governance, agile lifecycle, agile metrics, agile principles, agile transformation, Agile2018, Agile2019, Agile20Reflect, AgileData, Analogy, announcement, Architecture, architecture, architecture owner, Articles and publications, Asset Management, Atari, Backlog, Barclays, being agile, benefits, bi, blades, book, Branching strategies, Browser, Business Agility, business intelligence, business operations, capex, Case Study, Certification, certification, charity, Choose your WoW, CMMI, cmmi, Coaching, Collaboration, Communications Management, Compliance, Compliancy, Conference, Construction, Construction phase, Context, Continuous Improvement, coordination, COVID-19, Culture, culture, Cutter, DA, DAD, DAD Book, DAD discussions, DAD press, DAD roles, DAD supporters, DAD webcast, DADay2019, Data Management, database, dependencies, Deployment, Development Strategies, DevOps, disaster, Discipline, discipline, Disciplined Agile, disciplined agile delivery, disciplined agile delivery blog, Disciplined Agile Enterprise, disciplined devops, Documentation, Domain complexity, dw, DW/BI, Energy Healing, Enterprise Agile, Enterprise Architecture, Enterprise Awareness, enterprise awareness, Essence, estimation, Evolving DA, Executive, Experiment, facilitation, FailureBow, feedback-cycle, finance, Financial, FLEX, Flow, foundation layer, Funding, GCI, GDD, Geographic Distribution, gladwell, global development, Goal-Driven, goal-driven, goals, Governance, GQM, Guideline, Hybrid, Improvement, inception, Inception phase, India, information technology, infosec, Introduction, iterations, Kanban, large teams, layer, lean, Lean Startup, learning, Legal Project Management, LeSS, Lifecycle, lifecycle, Manifesto, mark lines, marketing, MBI, Metaphor, Metrics, metrics, mindset, Miscellaneous, MVP, News, News and events, Non-Functional Requirements, non-functional requirements, Non-solo development, offshoring, Operations, opex, Organization, Outsourcing, outsourcing, paired programming, pairing, paper, People, People Management, phases, Philosophies, Planning, PMBoK, PMI, PMI and DA, PMI Chapter, Portfolio Management, post-format-quote, Practices, practices, Principle, Process, process improvement, process tailoring, Product Management, product owner, Product Owners, productivity, Program Management, Project Management, project-initiation, Promise, Quality, quality, rational unified process, Refactoring, Reiki, Release Management, release management, Remote Training, Remote Work, repeatability, requirements, Requirements Management, research&development, responsibilities, retrospectives, Reuse, Reuse Engineering, ride for heart, rights, Risk Management, Risk Management, Risk management, Roles, RUP, SAFe, sales, Scaling, scaling, scaling agile, Scheduled Workshops, SCM, scorecard, Scrum, ScrumMaster, SDLC, Security, security, self-organization, SEMAT, serial, skill, solutions software consumable shippable, Stakeholder Management, strategy, Support, Surveys, Teal organizations, team development, Team Lead, team lead, Teams, Technical Debt, Teleconferencing, Terminology, terraforming, test strategy, testing, time tracking, Tool kit, Toolkit, tools, traditional, Transformation, Transition iteration, transition phase, Uncategorized, Upmentors, Using PMI Standards, value stream, velocity, vendor management, Virtual Training, Workflow, workflow, workspaces

Date

DA For Remote Agile Teams

linkedin twitter facebook Request to reuse this  

Remote agile teams typically use more video conferencing and extra written communication than collocated teams to stay synchronized. While perhaps not as effective as direct face-to-face communication, these approaches make up some of what is lost from sitting together and provide the advantage of being easily recorded for later access.

This asynchronous access to information is especially valuable for globally remote teams that may not share the same work hours. By accessing content on-demand, people can contribute when works best for them and sync up with the rest of the team at preset events.

Remote Onboarding Challenges

Onboarding new team members can be a challenge for remote teams. Introducing team members, explaining agreed to norms around process and tools are traditionally done in-person. Writing all of this information down along with the justifications and discussions around the decision process is a significant undertaking.

GitLab, one of the most successful all-remote agile development organizations, has onboarding materials that would occupy over 8,000 pages if printed. As organizations transition to more remote-friendly structures, documenting how teams work is becoming more critical.

Disciplined Agile for Onboarding

Fortunately, Disciplined Agile (DA) can help. It contains a vast tool kit of approaches accompanied by industry vetted analysis of when they add value when they do not, along with the pros and cons of implementing them. Teams can use the DA tool kit as the starting point for describing their way of working.

Using the upcoming DA Profiler tool, teams can debate, discuss and decide on their ways of working. The tool captures the goals, decision points and trade-off tables of each selected process or technique. Then, when new team members join, they can be pointed to the saved profile representing the team’s way of working. This saves creating lengthy onboarding materials and descriptions of processes.

Of course, processes should not remain static but instead, continue to evolve as teams and businesses learn and develop. So, at regular intervals, teams are encouraged to review and update their way of working and create a new definition. DA provides a robust strategy to support this and the goal “Evolve Way of Working.”

Keeping it Real

A strength of DA is its realism and pragmatism towards how organizations work. Not all organizations are fully agile yet, nor perhaps want to be. So, if some traditional, serial practices are still in use, that is OK; DA supports it. If Team A uses Scrum with two-week Sprints, Team B uses Kanban with continuous flow, and Team C uses SAFe, that works too.

DA is approach agnostic and capable of supporting a variety of popular techniques along with custom hybrid solutions. It also embraces a set of principles that make building guidance for remote agile teams more successful. These include: “Be pragmatic,” “Context counts,” “Choice is good” and “Enterprise awareness.”  These principles provide practical advice teams can apply to define their remote ways of working.

Mind Your Toes

Returning to the GitLab onboarding process, they promote a fun principle called “Short toes,” which comes from when people join the company and frequently say, “I don’t want to step on anyone’s toes.”

At GitLab, they aim to be accepting of people taking the initiative in trying to improve things. They recognize that as organizations grow, their decision-making speed often slows since more people are involved. However, this can be counteracted by having short toes and feeling comfortable letting others contribute to their domain.

Short toes is a great concept that is required if organizations are to scale and evolve successfully. It aligns well with another of DA’s principles, “Be awesome,” which is all about striving to be the best that we can and to always get better.

Summary

Adapting to the challenges of more remote team members and new all-remote teams creates the need for better onboarding resources.

DA provides great scaffolding to build onboarding handbooks that document how teams have selected to work without making manuals with thousands of pages.  It supports group-based discussion and selection of techniques, ongoing refinement and offline access. Perfect for onboarding today’s increasingly remote workforce.

Posted by Mike Griffiths on: December 01, 2020 04:21 PM | Permalink | Comments (5)

Why doesn't Disciplined Agile use the term "predictive"?

linkedin twitter facebook Request to reuse this  

Crystal ball - Getty Images

Quick answer

The term predictive is deceptive.

 

Detailed answer

In the Disciplined Agile (DA) tool kit we use the term traditional or serial, rather than predictive or waterfall, to refer to the classic/linear ways of working.  We feel that predictive is deceptive, more on this in a minute, and waterfall to be insulting (albeit still in common use within the IT community).  Furthermore, we're starting to move away from using traditional as we're now seeing a generation of practitioners who feel that some of the older agile approaches, in particular Scrum, are traditional ways of working.

There are several reasons for why we feel the term "predictive" to be deceptive:

  1. "Predictive" implies predictable.  Predictive is defined as "relating to the ability to predict" whereas predictable is "something that happens in a way or at a time that you know about before it happens."  Something that is predictable is a sure thing, yet something that is predictive is not. This is an important difference, particularly given that we know that projects aren't completely predictable - otherwise we wouldn't need risk management.
  2. "Predictive" approaches to IT projects are a poor choice in most cases.  Years ago I led a study for Dr. Dobb's Journal that investigated the effectiveness of different approaches (agile, lean, iterative, ad hoc, and traditional) to IT projects.  We found that traditional strategies were less effective in practice than agile and lean approaches, and we weren't the only ones to have found this.  We also investigated what was initially predicted at the beginning of the project and what actually happened by the end of the project, and once again traditional approaches didn't do as well as agile & lean.  BUT, I must stress that the study focus was on IT projects only, not on projects in general.  
  3. "Predictive" approaches to intangible projects are likely a poor choice  DDJ found, in several studies in fact, that "predictive" strategies were less predictable in practice than agile/lean approaches in IT.  I highly suspect that this is true of intangible projects in general although do not have hard data to back up that claim.  We need to investigate this.
  4. "Predictive" approaches to tangible projects are likely a good choice, but I suspect we can do better.  I suspect that "predictive" approaches are more appropriate for tangible projects, such as building houses or buildings, than agile/lean approaches.  I also believe that a hybrid approach combining the best from traditional, agile, and lean strategies is likely better than traditional alone. Having said this, as with the previous point, I don't know of any research that has compared the various project management paradigms for tangible projects, so this too is something we need to investigate.

In short, we know that "predictive" is a deceptive term for a large category of projects and suspect this to be true for other project types.  As a result the only use of the term predictive in DA is to tell you that we don't use it.

 

Posted by Scott Ambler on: November 09, 2020 12:38 PM | Permalink | Comments (9)

The Disciplined Agile Enterprise (DAE) Layer

linkedin twitter facebook Request to reuse this  

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

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

Figure 1. The layers of the DA tool kit.

Disciplined Agile Layer Overview

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

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

The process blades of Disciplined Agile

Figure 3. The process blades specific to the DAE layer.Disciplined Agile Enterprise (DAE) process blades

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

Asset management

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

Enterprise architecture

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

Finance

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

Information technology

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

Legal

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

People management

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

Transformation

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

Vendor management

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

Posted by Scott Ambler on: October 12, 2020 06:24 PM | Permalink | Comments (7)

Disciplined Agile (DA)'s Value Streams Layer

linkedin twitter facebook Request to reuse this  

Money river - Source Getty

The value streams layer encompasses the capabilities required to provide value streams to your customers.  A value stream begins, ends, and hopefully continues with a customer. A value stream is the set of actions that take place to add value for customers from the initial request through realization of value by the customers.  The value streams layer is one of the four layers of the Disciplined Agile (DA) tool kit, overviewed in Figure 1.  These layers are: Foundation, Disciplined DevOps, Value Streams, and Disciplined Agile Enterprise (DAE).  This blog focuses on the value streams layer.

Figure 1. The layers of the DA tool kit.

Disciplined Agile Layer Overview

Figure 2 depicts the DA FLEX lifecycle, overviewing the high-level workflow for a value stream.  As you can see, a value stream begins with the initial concept, moves through various stages for one or more development teams, and on through final delivery into business operations.

Figure 2. The DA FLEX lifecycle for value streams.

DA FLEX lifecycle

Let's explore the components of Disciplined Agile's value stream layer.  The hexes in Figure 2 and Figure 3 represent process blades, sometimes called process areas. A process blade encompasses a cohesive collection of process options, such as practices and strategies, that should be chosen and then applied in a context sensitive manner.  Process blades also describe functional roles specific to that domain as well as extensions to the DA mindset specific to that domain. 

Figure 3. The process blades of Disciplined Agile's value stream layer.

Disciplined Agile Value Streams Layer

You can see in Figure 3 that some process blades, such as Product Management and Program Management, are specific to this layer.  Other process blades, such as Strategy and Marketing, are shared between the value streams layer and the disciplined agile enterprise (DAE) layer. This is an indication that you may choose to implement those process blades at both the enterprise level as well as the level of a single value stream - do what is right for your situation.

Expanding upon the Disciplined DevOps layer, the value stream layer adds the following blades:

Business operations

Business operations focuses on the activities required to provide services to customers and to support your products. The implementation of business operations will vary by value stream, in a bank retail account services is implemented in a very different manner than brokerage services for example. Business operations includes help desk and support services (integrated in with IT support where appropriate) as well as any technical sales support activities such as training, product installation, and product customization. As you can imagine close collaboration with both your Sales and Marketing efforts is required to successfully Delight Customers.

Continuous improvement

The continuous improvement process blade describes how people within your organization can share their improvement learnings with one another in a systematic way.  There are many strategies for doing so, including centers of excellence (CoEs), communities of practice (CoPs) which are also known as guilds, techniques for exploring existing ways of working (WoW), identifying new WoW, and sharing techniques.

Governance

Governance is the leadership, organizational structures, and strategies to enable you to sustain and extend your organization’s ability to produce meaningful value for your customers. Lean governance promotes strategies such as motivating people to do the right thing, enabling them to do so (often via automation), communicating organizational objectives, and preferring visibility over reporting.

Marketing

The goal of marketing is to ensure successful interactions between your organization and the outside world. Disciplined Agile marketing applies data and analytics to continuously source promising opportunities or solutions to problems in real time, deploying tests quickly, evaluating the results, and rapidly iterating. It also means taking a validated learning approach, being customer focused, working in a collaborative and flexible manner, and working in an evolutionary (iterative and incremental) manner. Your marketing efforts will represent your organization and your offerings, both products and services, to the outside world and conversely will represent external stakeholders, and potential stakeholders, to the rest of the organization. In conjunction with product management, Marketing will be actively involved with long-term visioning for your organization’s offerings. Marketing is sometimes called brand management

Portfolio management

Portfolio management addresses how an your organization goes about identifying, prioritizing, organizing, and governing their various endeavors. Disciplined Agile portfolio management seeks to do this in a lightweight and streamlined manner that maximizes the creation of business value in a long-term sustainable manner. Potential endeavors include solution delivery initiatives/projects, stable product development teams, business experiments (along the lines of a lean startup strategy), and the operation of existing solutions.

Product management

Product management is the art of taking strategic objectives and turning them into tactical activities.  Disciplined agile product management is performed in a collaborative and evolutionary manner that reflects the context of your organization. Disciplined agile product management includes the acts of:

  • Identifying and prioritizing potential products/solutions to support your organization's vision;
  • Identifying, prioritizing, and allocating features to products under development;
  • Managing functional dependencies between products;
  • Marketing those products to their potential customers;
  • Exploring the needs of existing and potential customers;
  • Identifying minimum business increments (MBIs) for delivery teams to work on.

Program management

A program is a large team composed of two or more sub-teams (also called squads). The purpose of program management is to coordinate the efforts of the sub-teams to ensure they work together effectively towards the common goals of the overall endeavor. Program management encompasses financial activities, vendor management, coordination of people/staffiing concerns, coordination of the evolution of the solution, and coordination of requirements management issues across the sub-teams within the program.

Research & development

Research & development (R&D) encompasses the innovative activities undertaken by your organization to identify potential new offerings (services or products), or to identify potential improvements to existing offerings. R&D constitutes the first stage of development of a potential new offering.  R&D activities are an important part of both product management and solution development to help explore potential ideas and strategies.

Sales

The aim of your sales efforts is to, you guessed it, sell your organization’s offerings (both products and services) to customers. Your sales people, if any, will work very closely with your marketing team to ensure they are focused on selling offerings that reflect your organizations’ overall strategy. They will also work closely with product management to ensure that what they’re selling is available or can be built in a timely manner. Organizationally Sales is often combined with marketing or may even be matrixed into business operations.

Strategy

Strategy is what you do now, and what you intend to do in the future.  The focus of the strategy process blade is to identify, evolve, and then drive the execution of your organization’s vision. Your vision is driven by the perceived needs of your customers and influenced by the environment in which you operate.

 

Posted by Scott Ambler on: October 02, 2020 12:00 AM | Permalink | Comments (6)

Would you like to get involved with the 20th Anniversary of Agile?

Categories: agile, Scrum, Kanban, lean

linkedin twitter facebook Request to reuse this  

Agile20Reflect

Scott Seivwright is leading the #Agile20Reflect effort to reflect on 20 years of the agile movement. He has posted a call for help to organize Agile20Reflect.

He's looking for people to get involved who can help run things rather than argue and fight about various nuances. Given the Disciplined Agile strategy of embracing the various agile, lean, and even traditional strategies I suspect that some of you may be well suited to join in this effort.

And yes, I'm already involved.

Posted by Scott Ambler on: September 07, 2020 09:26 AM | Permalink | Comments (4)
ADVERTISEMENTS

Not that there's anything wrong with that.

- Jerry Seinfeld

ADVERTISEMENT

Sponsors