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:

Scott Ambler
Glen Little
Mark Lines
Valentin Mocanu
Daniel Gagnon
Michael Richardson
Joshua Barnes
Kashmir Birk
Klaus Boedker
Mike Griffiths

Recent Posts

The Disciplined Agile Enterprise (DAE) Layer

Disciplined Agile (DA)'s Value Streams Layer

The Disciplined DevOps Layer

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

The Four Layers of the Disciplined Agile Tool Kit

Disciplined Agile (DA)'s Value Streams Layer

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 (5)

Agile Metrics: Questions and Answers

Categories: marketing, Transformation

Metrics

On March 21 2017 we ran a webinar entitled Measuring Agile: A Discipline Agile Approach to Metrics.  We unfortunately didn’t have enough time to answer all of the great questions that we received so we said that we’d write a blog with the answers.  This is it.

We’ve organized the blog into the following sections:

 

Convincing Management

First and foremost, please read our blog entitled 7 “Easy” Steps to Convince Management to Support a Hard Change.  This blog has a lot of great advice for getting support from senior management for the changes asked about below.

 

Q: What is the message to deliver to the board of directors of a company and/or sponsors of projects when it comes to metrics?

The principles section of the webcast made this pretty clear I think.  The principles we discussed are:

  • There is no easy answer
  • Every metric has strengths and weaknesses
  • Compete against yourself
  • Measure to improve
  • You get what you measure
  • Measure outcomes at the team level
  • Each team needs a unique set of metrics
  • Team use metrics to self organize
  • Trust but verify
  • Adopt common metrics categories across teams
  • Don’t manage to the metrics
  • Automate wherever possible
  • Prefer trends over scalars
  • Prefer leading over trailing metrics
  • Prefer pull over push

If I had to pick a key message, it’s that you need to be flexible and enable teams to take a context sensitive approach.

Q: How do you address the resistance to ranged estimates?  We see a lot of resistence to this with leaders!

Sadly this is all too common.  There is a desire for an “exact number” for the cost/schedule for an IT project, the belief being that such precision leads to lower financial risk. This never seems to work out, and in practice it tends to increase overall financial risk.  Worse yet it motivates some very ethically questionable management practices such as padding the budget (lying about the cost to get the fixed estimate as close to the upper end of the range as possible), dropping scope late in the lifecycle (lying about what will be delivered and wasting money working on stuff you had no hope of delivering in the first place), or asking for more money when it’s clear you’re not going to deliver it (this is arguably extortion).  In the article Estimating on Agile Projects I go into further detail about the need for ranged estimates.

As we discuss in the 7 Easy Steps blog, you need to educate management on the trade-offs involved with their current approach and help the to see that it isn’t working out well for them in practice.

Q: My management definitely wants to know if they are on time and on budget… how should I handle this problem?

This is also another common problem in more traditional organizations, and is sadly a mindset that is often promoted by project management canon.  The first thing to do is ask them why “on time and on budget” is important to them, and to continue to explore their goals via an evolutionary “5 why” strategy until you get to the heart of the matter.  Usually the real issue is that they want to reduce schedule risk and financial risk but they only know to ask for on time and on budget respectively.  Help them to recognize that they can do better than that.  For example, a more effective question to ask instead of “Are we on budget?” would be “Are we spending the money wisely?”, the latter question requiring competent governance to truly answer.  Similarly, a more effective question to ask that “Are we on schedule?” would be “Are we going to deliver when the functionality is actually needed?”, also a question requiring better governance than many organizations seem to have today.

Q: Executives and senior management wants common metrics period… can you talk to this – how should a change agent (me) handle this?

Sadly another very common problem.  This proves to be selfishly motivated in most cases – they want a common set of metrics to make it easy for them to monitor teams (they have less thinking to do when all the dashboards look the same).  As we discussed in the webinar, this isn’t realistic because every team is unique, they face a unique situation, and they have a unique set of priorities.  Yes, there are commonalities between teams but also differences.  For example, it makes sense for teams to measure quality.  BUT, surely it’s obvious that a data warehousing team will measure quality different than a mobile app team, which in turn measures quality differently than a team sustaining a mainframe-based system.  This is why I promoted the idea of asking teams to address common categories (such as Quality, Stakeholder Satisfaction, Finance, and so on) but to do so in a manner that makes sense for them.

 

Transformation Metrics

Q: In a transformation is the ‘stakeholder vision’ milestone something that you see ‘could’ be used as a way to guage adoption of the toolkit across an Enterprise?

Stakeholder vision is a milestone that marks the end of the Inception phase.  I’m not sure how it could be used to gauge adoption.  It could be used to gauge readiness to move forward with the transformation though.

Q: Is there more thoughts you have on transformation metrics?

Context counts.  In general, take a context-sensitive approach where you measure what is important to you.  I worked through a lightweight approach to Goal-Quality-Metric (GQM) during the webinar and the OKR approach is also good.  There is no one single answer.

Q: How do start-up agile projects best survive in a really non-agile organization?

Sadly, they generally don’t.  If you go poking around on the web you’ll find that there’s a lot of advice around this sort of issue, and a large portion of it advising you to jump to another organization.

 

Specific Metrics

Q: Please throw some light on Accelaration metric. I’d like to implement that in my org.

We have a detailed blog about acceleration.

Q: Velocity, used to calculate acceleration, can only be calculated if velocy is based on the same point system… I don’t agree acceleration factors out the points, the points have different meaning potentially by project – can you talk to this some more?

You’re wrong,  Here’s a quick answer:

  • Team 1 has a velocity this iteration of 20 and a velocity 5 iterations ago of 15.  Velocity is measured in Atari points on this team.  Acceleration = (20 Ataris – 15 Ataris)/15 Ataris = 33% over 5 iterations.
  • Team 2 has a velocity this iteration of 30 and a velocity 5 iterations ago of 20.  Velocity for this team is measured in Nintendo points by this team.  Acceleration = (30 Nintendos – 20 Nintendos)/20 Nintendos = 50% over 5 iterations.
  • When I divided Atari points by other Atari points the unit of measure, Atari points, disappeared.  Similar thing happened to Nintendo points.  Hence acceleration is comparable as long as it’s calculated over a similar time period (if not, adjust so that you are dealing with a similar time period).
  • Read the Acceleration blog for details.

Q: Is value is only monetary value is $?

No, it doesn’t have to be but often is.  You should measure value in units that are important to your stakeholders.  Perhaps value may be measured in market share by them, for example.

 

Miscellaneous

Q: Excecutive leaders want to measure “team health” using metrics and compare teams – maybe reward or punish based on these metrics – please talk to this.

This is generally recognized as bad practice because as soon as teams realized that they are being judged by management they’re motivated to game the metrics as best they can.  In the case of automated metrics that are difficult to game, then perhaps its possible to compare against that (code quality metrics come to mind).  But, management will get what they measure.  For example, if they judge teams based on how many defects they fix, chances are pretty good that the team will start identifying relatively trivial defects and then “fix” them to make their metrics looks good.  However, if they judge teams based on code quality trends (i.e. Is code quality improving?) they will likely get higher quality code in the long run.

As I said in the webinar, the primary usage of metrics should be to provide insights to teams to help them to improve.  Monitoring teams, part of your overall governance strategy, should be an important but secondary concern.

Q: What if the teams don’t agree with the metrics established by management?

My advice is for teams to identify the metrics that make sense for the situation that they face via a lightweight GQM approach (or something similar such as OKR).  Management may want to guide teams, perhaps by insisting on certain categories of metrics, see the earlier discussion, or even by suggesting metrics being collected by other teams.

If it’s a situation where management is trying to inflict a common metrics strategy across all teams, which is a relatively bad idea as I discussed earlier, then I think that the team should justify why they don’t agree with the metrics prescribed by management.  I also hope that they would suggest a more appropriate strategy and that management would listen to them.

Q: What are some of your favorite tools for metrics?

I typically don’t like recommending tools because the answer to this question is context dependent.  Tool choice will be driven by:

  • What you are hoping to measure
  • Your existing platform(s)
  • Your organizational preferences around tooling (are you a Microsoft shop, are you willing to pay for commercial tools, are you willing to adopt open source tools, …)
  • Your previous experiences around such tooling, if any

So, identify what you situation is then do a bit of research to identify the tools that are right for you.

Q: Is it realistic at scale to have multiple dashboards? +900 teams.

I’ll turn this one around.  Is it reasonable to ask teams not to have dashboards simply because your organization is big?  Is it reasonable to give up on monitoring teams because your organization is big?  Is it reasonable to give up on automation because your organization is big? You see where I’m going with this.

 

Posted by Scott Ambler on: March 23, 2017 01:07 PM | Permalink | Comments (0)
ADVERTISEMENTS

"The secret to creativity is knowing how to hide your sources."

- Albert Einstein

ADVERTISEMENT

Sponsors

Vendor Events

See all Vendor Events