Author Archives: Scott Ambler

About Scott Ambler

Senior Consulting Partner at SA+A. We help teams to become awesome.

DA Day 2018 – Call for Presentations

The  call for presentations (CFP) for DA Day is open until March 25th.  This first of its kind, this one-day online conference will bring together leading Disciplined Agile (DA) experts, practitioners, and customers to share best practices, DA success stories, and introduce new DA techniques and learning materials. Agenda topics have been selected by DAC members as part of ongoing surveys to determine areas of most interest.

The 5 agenda topics are:

  • DAIT: Enterprise Architecture – How do you apply lean and agile strategies for Enterprise Architecture?  How do Enterprise Architects work effectively with IT delivery teams?
  • DevOps: IT Operations – How do you build and run a trustworthy IT ecosystem that runs so efficiently it  goes unnoticed by clients?
  • DAIT: Continuous Improvement  – How do you enable people to easily and systematically share improvement learnings?
  • DevOps: Release Management – How do you effectively plan, coordinate and verify the deployment of IT solutions into production in multi-team environments? How are IT delivery teams implementing CI/CD pipelines in established enterprises?
  • DAE: Business Operations – How has agile and lean enabled your organization to more effectively provide services and products to customers? How has the relationship between IT and “the business” evolved?

We are seeking DA practitioners with experience in these areas to participate as speakers for DA Day.  Final presentations will be limited to 15 minutes and a maximum of 10 PowerPoint slides and will be done in webinar format.  This is a great way to share your experiences with others, and get yourself out there as an agile conference speaker.

Please send a short abstract describing your presentation idea to along with your contact information and level of DA certification (if any).


Product Owners vs. Product Managers


A common question that we get is what is the difference between Product Owners (POs) and Product Managers? From a Disciplined Agile (DA) perspective, it’s a matter of strategy vs. tactics:

    • Product Owners are more tactical in practice.  POs work closely with delivery teams to ensure they build the right functionality in a timely manner. POs will transform the high-level vision of the Product Manager into detailed requirements. To do this they work closely with a range of stakeholders for the product, including non-customer stakeholders such as finance, security, operations, support, audit, and others.  Tactical activities such as attending team coordination meetings, organizing demos, doing sufficient analysis to ensure that requirements are ready to be worked on, and being involved with ongoing testing efforts easily add up to a full-time job.
    • Product Managers are more strategic in practice. They should be focused on the long-term vision for the product, on observing trends in the marketplace, on identifying new potential outcomes or themes to be supported by the product, on supporting the sales/adoption of the product, and on ensuring the product meets the needs of the value stream(s) the product is involved with. Effective Product Managers tend to be very customer focused, although recognize that this needs to be tempered by the constraints and capabilities of your organization. The activities that Product Managers are responsible for – product marketing, supporting product sales/adoption, budgeting, long-term envisioning, customer care, and of course supporting the solution delivery team(s) – can easily add up to a full time job.


We Need to Collaborate

As you can see in the following diagram, the role of Product Manager is different, yet overlapping, with that of a Product Owner (PO).  The PO will spend the majority of their time on tactical activities, including working with the team to communicate stakeholder needs to them and working with stakeholders to elicit and prioritize their needs. The Product Manager, on the other hand, spends most of their time on more strategic issues, collaborating closely with customers (and potential customers) to identify their potential needs.

Figure 1. Example of rolling wave planning for product functionality (click on image for larger version).Product Owners and Product Managers

There is clearly overlap between strategic, long-term thinking and tactical, short-term implementation.  Product Owners are responsible for the Product Backlog in Scrum, what Disciplined Agile DAD (DAD) teams might refer to as a Work Item List or in the case of teams who have adopted one of the lean lifecycles a Work Item Pool, and some of the items in the backlog/list/pool might be several months away from being implemented (if ever).  In Figure 1, these are items that fall into the yellow or red timing areas, or even the grey area.  Product Managers, being responsible for strategic thinking, will be focused on high-level outcomes or themes for the product.  They may even be focused on more concrete, yet still high level, epics or features.  So we see overlap in the Product Manager’s high-level strategic focus and the Product Owner’s tactical focus, indicating the need for collaboration between the two roles so that the tactical decisions reflect the overall strategy, and the overall strategy is informed by the realities faced on the ground by the delivery team.

Please note that the timing of “short term” and “long term” will vary by product.  In the case of Figure 1 the long-term planning horizon is around the three month point (where the diagram shifts from yellow to red).  That’s just an example, from one team.  We’ve worked with some teams where the long-term planning horizon was anything more than a month.  We’ve also worked with other teams where the long-term planning horizon was closer to a year (they’ve since shortened that considerably).


Shouldn’t Product Owners Also Address Strategic Issues?

Here are a few thoughts to help answer this question:

  1. Everyone should consider strategic issues.  Some people, particularly those focused on Scrum, will tell you that Product Owners should also be focused on strategic issues.  It’s certainly good for POs to understand the long-term strategy for the product that they are focused on. In short, POs, like everyone else, should be Enterprise Aware.
  2. Each role requires a different, and comprehensive, skillset.  Each of these roles are challenging enough by itself. You’ll have a much better chance of finding someone with the skills to work tactically, and someone with the skills to work strategically, than finding a single person with both skillsets (or the time and inclination to pick up both).
  3. There is often too much work for one person.  As we argued earlier, the day-to-day tactical work tends to be a full-time job (and often more) as does the strategic Product Management work.  As a result, you are often motivated to tease these two roles out into separate positions.
  4. These are roles, not positions. In straightforward, non-scaled situations, it is common to see a single person taking on both of these roles.  This is common in start-up organizations where the company simply can’t afford to have two people to do this work.  It’s also common with new products in general because it isn’t yet obvious whether the product will be sufficiently successful in the marketplace to warrant much investment in long-term strategic thinking around it.

So, as usual, the answer is “it depends.”  As we like to say in DA, context counts which is why choice is good.


Related Reading

Introduction to Disciplined Agile Delivery 2nd Edition is now available!

I’m happy to announce that Introduction to Disciplined Agile Delivery 2nd Edition: A Small Agile Team’s Journey from Scrum to Disciplined DevOps is now available.  The 111 page book sells for $9.99 US for the paperback edition and $3.99 US for the Kindle edition.  The book is currently available on in the US and will soon be available on Amazon in other countries as per Amazon’s usual deployment strategy.

This book provides a quick overview of how agile software development works from beginning-to-end.  It describes Disciplined Agile Delivery (DAD), the first of four levels of the Disciplined Agile (DA) process decision framework, and works through a case study describing a typical agile team’s experiences adopting a DA approach.  The book describes how the team develops the first release of a mission-critical application while working in a legacy enterprise environment.  It describes their experiences from beginning-to-end, starting with their initial team initiation efforts through construction and finally to deploying the solution into production.  It also describes how the team stays together for future releases, overviewing their process improvement efforts from their Scrum-based beginnings through to a lean continuous delivery approach that fits in with their organization’s evolving DevOps strategy.

What’s Different in This Edition

In the 2.5 years since the first edition was released DAD, and to a greater extent the DA framework in general, has evolved. Here are the major changes:

  • Chapter 3 was completely rewritten to reflect the changes to DAD, in particular to addition of the Continuous Delivery: Agile lifecycle as well as the evolution of several process goals.
  • Chapter 12 was rewritten to describe how the team, and more importantly the organization they work within, evolve into a Disciplined DevOps strategy. In the first edition we just took the team to the Continuous Delivery: Lean point, but in this edition we take them right into DevOps.
  • Appendix A was rewritten to reflect the latest release of the DA framework. When the first edition was released the 2.1 version of the framework was overviewed in the Appendix. Since then the framework has been expanded to address four levels – DAD, Disciplined DevOps, Disciplined Agile IT, and now Disciplined Agile Enterprise (DAE) – instead of the original three. With the addition of DAE the DA framework provides true insight for how to begin supporting business agility within your organization.
  • General updates were made throughout the book, including the update of several diagrams to reflect the evolution of DAD, expanding on a few ideas that readers said they wanted to hear more about, and fixing a few outstanding grammar errors.
  • The book is using a slightly larger format, 6 inches by 9 inches, to match An Executive’s Guide to Disciplined Agile format. Similarly we also updated the cover to be consistent with that book.

Strategies for Capturing Non-Functional Requirements


Agile modeling

Non-functional requirements, also known as quality of service (QoS) or technical requirements, address issues such as reliability, availability, security, privacy, and many other quality issues.  The following diagram, which overviews architectural views and concerns, provides a great source of NFR types (the list of concerns).  Good sources for NFRs include your enterprise architects and operations staff, although any stakeholder is a potential source for NFRs.

Architecture Views and Concerns

Why Are NFRs Important?

Stakeholders will describe non-functional requirements at any time, but it’s particularly important to focus on them during your initial scoping efforts during Inception as you can see in the goal diagram below for Explore Initial Scope.  Considering NFRs early in the lifecycle is important because:

  1. NFRs drive important architecture decisions. When you are identifying your initial technical strategy you will often find that it is the NFRs that will be the primary drivers of your architecture.
  2. NFRs will drive some aspects of your test strategy. Because NFRs tend to be cross-cutting, and because the tend to drive important aspects of your architecture, they tend to drive important aspects of your test strategy.  For example, security requirements will drive the need to support security testing, performance requirements will drive the need for stress and load testing, and so on. These testing needs in turn may drive aspects of your test environments and your testing tool choices.
  3. NFRs will drive acceptance criteria for functional requirements (such as stories).  are typically system-wide thus they apply to many, and sometimes all of your functional requirements.  Part of ensuring that your solution is potentially consumable each iteration is ensuring that it fulfills its overall quality goals, including applicable NFRs.  This is particularly true with life-critical and mission-critical solutions.

Explore Initial Scope


Capturing NFRs

As you can see in the goal diagram above, there are three basic strategies, which can be combined, for capturing NFRs:

  1. Technical stories.  A technical story is a documentation strategy where the NFR is captured as a separate entity that is meant to be addressed in a single iteration.  Technical stories are in effect the NFR equivalent of a user story. For example “The system will be unavailable to end users no more than 30 seconds a week” and “Only the employee, their direct manager, and manager-level human resource people have access to salary information about said employee” are both examples of technical stories.
  2. Acceptance criteria for individual functional requirements.  Part of the strategy of ensuring that a work item is done at the end of an iteration is to verify that it meets all of its acceptance criteria.  Many of these acceptance criterions will reflect NFRs specific to an individual usage requirement, such as “Salary information read-only accessible by the employee,”, “Salary information read-only accessible by their direct manager”, “Salary information read/write accessible by HR managers”, and “Salary information is not accessible to anyone without specific access rights”.  So in effect NFRs are implemented because they become part of your “done” criteria.
  3. Explicit list.  Capture NFRs separately from your work item list in a separate artifact.  This provides you with a reminder for the issues to consider when formulating acceptance criteria for your functional requirements.  In the Unified Process this artifact was called a supplementary specification.

Of course a fourth option would be to not capture NFRs at all.  In theory I suppose this would work in very simple situations but it clearly runs a significant risk of the team building a solution that doesn’t meet the operational needs of the stakeholders.  This is often a symptom of a teams only working with a small subset of their stakeholder types (e.g. only working with end users but not operations staff, senior managers, and so on).

Related Resources

Update: Address Changing Stakeholder Needs


Just wanted to share a quick FYI with you.  We recently updated the Address Changing Stakeholder Needs goal diagram:

Address Changing Stakeholder Needs

The changes were straight forward:

  • We added On-site customer to Stakeholder Interaction with Team.  This is a practice from XP.  As an aside, Agile Modeling’s Active Stakeholder Participation practice is an extension of On-Site Customer (which is likely why we had forgotten to include On-Site Customer as a practice, our bad).
  • We added Interviews to Elicit Requirements.
  • In Elicit Requirements we renamed Look-ahead modeling to Look-ahead modeling/Backlog refinement to include the Scrum terminology.

In all, just a few small incremental improvements!

The Disciplined Agile Product Management Mindset

Building on the ideas captured by the Disciplined Agile Principles and the Disciplined Agile Manifesto, there are several agile/lean philosophies that are critical to success in Product Management.  These philosophies are:

  1. Be customer driven.  The needs of customers, and more importantly the potential desires of customers that they are not even be aware of, should drive your Product Management decisions.  The implication is that Product Managers must work closely with existing customers, and furthermore must invest time to identify and understand potential customers so as to grow the market for their product.
  2. Address the full value stream.  An important part of being customer driven is to understand that it is the full customer experience with your organization, not just the “products”, that must be addressed.  You need to understand the full value stream(s) that your product(s) are part from beginning to end from the customer’s point of view – Product Management is about solutions and not just software.
  3. Take an experimental approach. People often don’t know what they want, will struggle to describe what they want, often won’t tell you want they want, and will change their minds anyway.  The point is that you need to go beyond asking people for their requirements if you want to identify what to offer your customers.  Modern thinking is to take an experimental approach via creation of minimal viable products (MVPs) to get something in front of potential customers to determine what they actually want – you do this through observing the features of your MVP that they use, how they use them, and the features that they don’t use.  This strategy was popularized by Eric Ries via his Lean Startup work and is captured in DAD’s Exploratory lifecycle.
  4. Release incrementally and often.  Releasing smaller increments more often enables you to reduce the feedback cycle with your customers, which in turn enables you to learn quickly and thus react to customer needs faster.
  5. Embrace change.  Customer needs and desires change, often rapidly.  New competitors enter the market with different or improved offerings.  New technologies and platforms are introduced and then evolved.  To be trite, the only constant is change.  Successful product managers not only accept this but they embrace it.  The implication is to adopt flexible, light-weight strategies.
  6. Plan strategically and react tactically.  Products should be planned strategically in the long term yet implemented tactically in the short term.  The common agile strategy is to take a what is known as a rolling wave planning approach where detailed planning occurs for what should be delivered in near team incremental releases but for future releases the planning is high-level and less detailed the further in the future something is.

Being a Product Manager is an interesting and exciting role.  We hope that this blog has been valuable for you.

Defining MVP, MMF, MMP, and MMR


The term minimal viable product (MVP) has achieved buzzword status in recent times and I’m now hearing people throwing around the term MVP almost on a daily basis.  Sometimes they’re using it correctly but many times they aren’t.  Frankly it’s driving me nuts.

The issue is that it’s common for people to say MVP when they are actually talking about a minimal marketable feature (MMF), a minimal marketable product (MMP), or even a minimal marketable release (MMR).  As you can see, these terms are very similar to one another so we shouldn’t be surprised that there’s a bit of confusion around them.  So let’s try to clear things up.


First, Some Definitions

Figure 1 below overviews how these following terms relate to one another:

  • Minimal Viable Product (MVP). An MVP is a version of a new product that is created with the least effort possible to be used for validated learning about customers.  MVPs are used to run experiments to explore a hypothesis about what your customers really want.  They are much closer to prototypes than they are to the “real” running version of your end product.  A development team typically deploys an MVP to a subset of your (potential) customers to test a new idea, to collect data about it, and thereby learn from it.  MVPs are created to help you to find the features that customers are actually interested in.
  • Minimal Marketable Feature (MMF). An MMF is the smallest piece of functionality that can be delivered that has value to both the organization delivering it and the people using it.  An MMF is a part of an MMR or MMP.
  • Minimal Marketable Release (MMR).  Successful products are deployed incrementally into the marketplace over time, each “major” deployment being referred to as a release.  An MMR is the release of a product that has the smallest possible feature set that addresses the current needs of your customers.  MMRs are used to reduce the time-to-market  between releases by reducing the coherent feature set of each release to the smallest increment that offers new value to customers/end users.
  • Minimal Marketable Product (MMP). An MMP is the first deployment of a Minimal Marketable Release (MMR).  Having said that, the terms MMP and MMR are often used interchangeably.  An MMP is aimed at your initial users, typically innovators and early adopters. The key is develop and MMP for the few, not the many, and thereby focus on the key features that will delight this core group of people.  An MMP is a tool to reduce the initial time to market because it can be developed faster than a feature-rich product.

Figure 1. The relationship between MVP, MMF, MMR, and MMP.

MVP terminology


Is it Minimum or Minimal?

Given that I’m being picky about terminology, I realized that there isn’t agreement as to whether we should use the term MINIMUM viable product or MINIMAL viable product (and similarly for MMR, MMP and MMF).  Once again, the words are very close:

  • Minimum. The refers to the least quantity or lowest possible amount.
  • Minimal.  This refers to barely adequate or sufficient (similar to the agile concept of just barely good enough (JBGE)).  Minimal is an adjective derived from the word minimum.

As you can see, very nuanced.  For our purposes the term minimal is more appropriate than minimum because it brings in the idea that it must be sufficient to fulfill the needs of our product’s customers.  Or more precisely, what we believe to be the current pressing needs of our stakeholders.


Example: Developing a New Product

Now let’s work through an example of the development of a fictional product.  One day while shopping in the local mall my phone ran out of power.  This proved to be a problem for me because I had a conference call that I had to be on, forcing me to cut my shopping trip short to go home and take the call there. This experience made me realize that there’s a potentially untapped market need as I would have been very willing to pay to charge my phone while at the mall. Note: I am fully aware that products such as Safecharge and Brightbox exist, but let’s pretend they don’t for the sake of this example.

Just because I’m willing to pay for this doesn’t mean that others will. To determine whether this could be a profitable endeavour I decide to follow Disciplined Agile’s Exploratory Lifecycle (see Figure 2), which is based on Lean Startup’s hypothesis-driven approach.  My plan is to iteratively build a series of MVPs to explore this product idea.

Figure 2. The Exploratory Lifecycle.DAD Exploratory LIfecycle

Over a several week period I work through a series of minimal viable products (MVPs):

  1. MVP #1: A power bar on a table.  I start with a very simple approach: I talk the mall manager into allowing me to put a table against a wall for a one week period to run an experiment. I plug a power bar into a nearby outlet and put it on the table.  On the wall I have a sign that indicates this is a phone charging station.  Throughout the week I stand by the table telling people about the service and tell them I’ll keep an eye on their phone if they want to go shopping while it charges (I quickly discovered that nobody is willing to actually do that, or at least they’re not willing to trust me, hmmm….). For anyone willing, I have them take a short survey asking them what they think about the service.
  2. MVP #2: I add several common power cords. On the first day several people indicated that they would use the service but unfortunately didn’t have their charging cable with them.  So at the end of the first day I bought several power adapters from an electronics store in the mall. Sure enough, over the next few days I had more people willing to charge their phones at my table.  By the end of the week I had gathered a fair bit of data that showed there was general interest in the idea but that a major problem was the inability to safely leave a device to charge while they go off to shop.
  3. MVP #3: I move to a cafe. The following week I run a similar experiment in a cafe a few blocks away from where I live.  Interestingly, I have several people ask to borrow a power cable from me so that they could power their phone while sitting at their own table.  The cafe already has power sockets for people to charge devices and it’s fairly common for people to camp out in the cafe for several hours with a laptop or table plugged into the wall.  After several days it becomes clear to me that a cafe isn’t a good option for a charging station.
  4. MVP #4: I add lockable cubby holes.  Over the next week I decide to build out a more sophisticated solution, a wood cabinet that has 16 cubby holes for charging devices.  Each cubbyhole has a specific type of charge cable, so if you want to change a phone you need to use a cubby with the right type of cable.  Each cubby has a door with a physical key lock.  I go back to the mall, in the same location as I’d been in previously, and instead of a survey I interview people to discover what they they think, how they would make it better, and what they’d be willing to pay for such a service.

This series of experiments led me to identify a collection of minimal marketable features (MMFs) that this product should offer:

  1. Lockable cubby holes.  People will only leave their phones and other devices if they’re safe.  Each cubby hole needs to be locked in such a way that only the person who left their phone in the cubby can get access to it.  This could be an electronic locks where people can type in a private code or a physical key-based system.
  2. Common phone power cords.  We need to be able to support charging a range of devices.  Each cubby should have several common power cord/cables as well as a normal power plug.
  3. Easily accessible location that doesn’t offer charging alternatives.  Malls and restaurants are good options, but public areas that already support device charging (like cafes) are not.
  4. Payment processing.  We want to support credit card and possibly blue-tooth payment strategies such as Apple Pay.  Payment options need to be investigated still.

Over the next two months we built a minimal marketable product (MMP).  The MMP was five large boxes, each of which had 16 cubby holes for small devices such as phones.  We wanted five boxes so that we could place three boxes in the mall where we had run our initial experiments and two boxes in another smaller mall on the other side of the city.  We made each box from folded sheet metal with clear, thick plastic doors so that people can see their devices.  For security and payment processing we built a device that used a small touch screen (it was actually a large smart phone) as an input device attached to a card swipe for capturing both credit and debit card payments.

Over time we continued to evolve the product via a series of minimal marketable releases (MMRs).  We ran some experiments in a public library where we discovered that library patrons wanted to charge large devices such as tablets and laptops as well as smaller devices.  We developed a “Library Charging Station” that had eight small device cubbies and six large device cubbies.  We also hired a designer to develop a sleeker looking box when one mall management change told us that they loved the concept but wouldn’t allow our boxes into their more upscale locations until our boxes where more attractive.


Why The Confusion?

There are several reasons why there is significant confusion in the marketplace:

  • These are closely related concepts with very similar names.
  • Various authors over the years have used these terms in different ways, thereby muddying the waters.
  • Few people go back to the original source of a concept and instead choose to read derivatory work (such as this article).  In effect suffer from the whisper game – you heard the term MVP from one person, who heard it from someone else, who heard it from someone else, and so on.

My hope is that this article, and the supporting poster that is now available on the Disciplined Agile Consortium site, has helped to clear up some of this confusion.


Related Resources

Disciplined Agile and SEMAT


I’m happy to announce that the Disciplined Agile Consortium (DAC) is now working with SEMAT. SEMAT, Software Engineering Method and Theory, is an international community of people, companies, and universities.  Led by Ivar Jacobson, SEMAT is working together to create a common ground, or kernel, for software engineering.  As you may know I am one of the original signatories who first indicated their support for the SEMAT effort and am currently a member of the SEMAT advisory board.

So why are we working with SEMAT?  We hope to gain several benefits:

  1. Share DA concepts more widely.  We intend to work together to essentialize some of the key concepts that are unique within the Disciplined Agile (DA) framework.  This will help to get our leading-edge material into the hands of more people.
  2. Leverage essentialized practices.  The SEMAT community has already captured, what they refer to as essentialization of, a wide variety of great practices such as TDD, continuous integration, coordination meetings, and so on.  Our approach in DA is to put such practices into context but not to go into detail describing them (instead we reference existing descriptions).  So, SEMAT provides DA with a great source of existing material to reference.
  3. Collaborate with the SEMAT community.  There are many practitioners, trainers, and researchers within the SEMAT community and it’s always a great idea to work with smart people!
  4. Enable our customers.  A big advantage with SEMAT is that they’ve published, and continue to publish, a lot of great process material.  This is exactly the type of material that organizations need to support the learning activities of their staff as well as their own process definition efforts.

Of course it is still early days and there is a lot to do.  Please stay tuned here for further updates!

Recommended Reading

Building Your IT Support Environment

An important aspect of Support that is easily forgotten is the need to build out your infrastructure to enable your support efforts.  This may include:

  • Creating a support knowledgebase so that your Support Engineers can capture solutions to the problems they solve.
  • Provide access to the support knowledgebase to support self-service by end users.  This access is often limited for privacy reasons – end users should have access to solutions to common problems but not the details to specific incidents.
  • A support environment to simulate problems.  In some cases, such as an online trading system perhaps, you don’t want your Support Engineers trying to diagnose end user problems on the live system itself due to potential side effects of doing so.
  • Installing communication systems such as chat software and a phone/call in system.
  • Automated support systems such as integrated voice response (IVR) and artificial intelligence (AI)/bots

Figure 1. High-level architecture for a Support environment (click on it for larger version).Support desk architecture

The Oath for an Agile Coach: Great Start, But We Need to do Better


I recently ran into The Oath for an Agile Coach.  There are clearly some great ideas in the oath and it would be hard to argue that you wouldn’t want to adopt the advice contained within it.  So I won’t do that.  However, I do feel that there are some serious challenges surrounding the oath but that with a bit of hard work we could do better.

Some Great Ideas Here

Frankly, what’s not to like?  The oath promotes the idea that coaches should do no harm, that they’re guests, that they should respect learnings, that they value discretion, and many other wonderful philosophies.  Several of them are arguably a bit naive, for example:

  • First, do no harm. From one point of view the definition of an agile coach is to do harm – harm to the status quo, harm to the incumbent mindset, harm to the corporate politicians who rose to power building the current environment that the coach is there to help the organization improve.  You wouldn’t be much of a coach if you weren’t doing harm to the bad stuff in your organization.
  • I prevent dysfunction.  Really?  I’ve worked in many environments that are “target rich” when it comes to dysfunction.  I’m expected to help prevent all of these dysfunctions right away?  I’m supposed to prevent dysfunction that is beyond my current scope of influence?  Of course not.  I need to help the people that I’m working with to identify and prioritize their pains, then help them address these pains as and when it is appropriate to do so (if ever).  Clearly the advice in the oath is context sensitive and it isn’t meant to be taken literally.

It’s clear to me that a lot of smart people have put a lot of effort into the oath, that they’ve thought it through, and are honestly trying to make things better.  I also believe that this is a step in the right direction, although at the time of this writing there are some serious challenges surrounding it that can and should be addressed.


A Few Serious Challenges

First and foremost, we should give the authors of the oath the benefit of the doubt and assume that they aren’t doing the things I’m about to describe on purpose.  Although what I have to say is harsh, I honestly believe that the authors have their hearts in the right place but have not thought through the implications of what they’ve started.  So here goes.

The oath is deceptive and as a result possibly unethical.  The reason why I say this is that they claim to have based the coach’s oath on the The Hippocratic Oath (which I’m sure they’ve actually done).  The problem is that they’ve merely skimmed the surface of the Hippocratic Oath, lifting ideas such as “First, do no harm” (which the oath doesn’t actually say, that’s the Hollywood interpretation of it) without also adopting the context in which the Hippocratic Oath is taken.  This is important.  New medical practitioners, after years of training, are asked to take the oath, or something similar, by medical schools.  These schools are governed and the medical professionals themselves are governed.  Control mechanisms are in place to ensure that the people who take the oath know what they’re doing and work in a trustworthy manner.  Therein lies the rub – no such governance exists for agile coaching and I suspect the vast majority of agile coaches would chaff at the suggestion.

To see why this is an issue consider the following example.  I have no medical training or background, with the exception of taking a few first aid courses over the years.  Come to think of it, by agile standards I have more than enough medical training to be considered a Certified Surgery Master (CSM), so it’s all good. I have just now recited the Hippocratic Oath and have pledged to abide by it.  As a result I now feel that I am qualified to offer plastic surgery procedures as I’ve heard that this is a lucrative business to be in.  If you would like a face lift, liposuction, or augmentation of a body part please contact me to arrange a procedure.  You can trust me because I’ve recited the Hippocratic Oath and I’m a CSM.  What?  You’re not interested? I’ve pledged to do no harm, so you can trust me.

I think that you inherently know it would be a bad thing for me to perform plastic surgery on you.  I’m obviously not qualified.  Therein lies the rub.  I could easily advertise that I’ve pledged the oath, tell people about my CSM credentials, and make it sound like I’m qualified, particularly to people who don’t have much of a background in agile.  In fact, recently in Toronto, a 19-year old woman did something very similar to this and as you’d expect it didn’t work out well for the recipients of her surgery endeavours.

By claiming that the agile coach’s oath is based on the Hippocratic Oath the authors are taking advantage of something called “prestige association.”  The Hippocratic Oath is prestigious – the people who pledge it have to work very hard to be asked to pledge it and are subsequently held to its high standards throughout their careers.  By explicitly associating the agile coaching oath with the Hippocratic Oath the prestige of the latter is conferred to the former.  This is deceptive at best and unethical at worst.  I believe we can be better than this.


How We Can Do Better

It isn’t appropriate to complain about the Agile Coach’s Oath without also providing some possible ways to fix it.  Here are my initial thoughts:

  1. Avoid prestige association. The very first thing, and easiest thing, that could be done is to stop comparing this oath to the Hippocratic Oath.
  2. Define paths to becoming a great coach.  A straightforward, and relatively easy, way to add real value would be to put together a path, or more likely several paths, that people could follow to become a great coach.
  3. Help people to follow those paths. In short, build a respectable agile coaching guild that focuses on helping people over making money off of them.
  4. We need to respect ourselves. This is an observation for agilists in general, but particularly important for agile coaches.  At the present moment the Agile Coach’s Oath is yet another vapid agile band wagon for people to jump onto without having to do any real work.  As coaches we lament the large number of lame agile “certifications” that are little more than participation ribbons, so perhaps it’s time we choose to say enough is enough.  We know that effective coaching requires skill, knowledge, and experience that require years of hard effort to earn.  Just like the medical community requires years of education and training before extending the privilege of asking someone to take the Hippocratic Oath, we could choose to do something similar.  But first we’d need to respect ourselves enough to actually do that.

I believe the people who developed The Oath for an Agile Coach have good intentions.  They’ve gotten a great start on an interesting and potentially valuable idea. But, they need to follow through and make it something real if they really want this oath to be meaningful.  I hope they choose to build a vibrant community that does exactly that.  Time will tell.


Related Postings