01 May 2017

Agile Institute has become part of Agile for All

Agile Institute (me, essentially) has merged with (joined) Agile for All.  

What does this mean for you?

Not much will change for you, because not much is changing for me.  All my courses are still available, along with the high levels of personalized service you've enjoyed in the past. I'm still delivering coaching and training in all things Agile/Scrum/XP/Lean, still spending weeks in hotels and airports (and I haven't grown tired of travel yet!), and still working hard to get the book finished.

I have a great deal of autonomy: Agile for All operates a lot like an umbrella organization, or a consortium: They're taking on the paperwork and minutiae that detracted and distracted me from the enjoyment of providing fun and pragmatic Agile courses to my clients. Health insurance, business insurance, quarterly taxes, sending out 1099s, receiving 1099s, reconciling 1099s, the DUNS number, printing & shipping, contracts, subcontracts, invoicing... All done for me for a percentage of my revenues.

Additionally, I have access to hand-picked Agile and Scrum trainers, Executive Coaches, and others whom I can collaborate with in order to best serve our clients.

And, of course, we're all "Agilists," and thus very empirically-minded. If this isn't an improvement for me, for Agile for All, and for my clients (the triple-win!), it's effectively reversible. I retain the rights to my training materials, and the agileinstitute.com domain will not be lost to me any time in the foreseeable future.

Here are some links for you:

New Agile for All blog:

Most importantly to readers of this post, here's my new blog:  http://agileforall.com/author/rmyers/

I've already posted my first post, which--you may notice--is an updated and improved re-post of a very early post on this blog. I will continue to intersperse the best posts from this older blog alongside new posts, particularly when I'm feeling a little lazy. Like today. ;-)

Existing links that will continue to function:

I'm not letting go of this prime Twitter handle: https://twitter.com/agilecoach

The Agile Institute Facebook page will remain available for now, as a place for me to easily share interesting posts from others:  https://www.facebook.com/AgileInstitute/

My LinkedIn profile has changed, but for other reasons. Here's the new one: https://www.linkedin.com/in/robmyersagilecoach/

And some exciting new places to stay in touch:

Last, but certainly not least, you can monitor the progress of my upcoming book in these two places:


Many thanks for your kind attention and years of readership!


27 February 2017

Random Thoughts on Business Models and Cost of Delay

I cover Cost of Delay and CD3 (Cost of Delay Divided by Duration) in my Essential Agile Product Leadership course. (CD3 being similar to WSJF). This part of the course is derived from from the work of Joshua J. Arnold, with Mike Cohn's business modeling "dimensions" (may be my term) as a starting point in the thinking process.

Mike Cohn's business modeling stuff is somewhat software-oriented, so it may be a good place to start for Agile (or Agile-hopeful) organizations.

I think I may have divided Mike Cohn's business modeling stuff into "dimensions" so that I could better explain them, but I'm no longer certain who did what.  I also added a little to it. It's safe to say this is strongly based on the work of Mike Cohn.


The dimension of Purpose is the selection of why we are building what we are building:
  • New: New customers, new markets, improved cash flow.
  • Upsell: Upgrades and enhancements for existing customers.
  • Retention: Avoids losing customers or cash flow.
  • Efficiency: Saves money while enhancing growth.
  • Reputation: Improves our standing in the market, e.g., feature-parity, repairing defects. (I may have added this one...)


The dimension of Necessity is a rough model of how we see this feature improving value:
  • Mandatory: A Minimal Marketable Feature (MMF).
  • Linear: Adds nominal value to the MMFs.
  • Exciter: Will create enthusiasm and joy in the user community.


Lastly, the dimension of Process, which may have been added by me as a catch-all for remaining things from Mike's set, or so I could add topics that I think folks should consider when exploring their Cost-of-Delay and Duration estimates:

  • Cycle Time: Time it takes between receiving a request and delivery (or use) of the feature.
  • Waste: Things we do that may not provide value. E.g. re-work due to defects.
  • Risk: Things we may or may not be doing that will result in a loss of value.
  • Operational expenses: Keeping the lights on, and many others.
  • Cost of Delay: What it obviously costs to wait, i.e. lost opportunity. (See below.)
  • Complexity: Keeping it smartly simple.

Cost of Delay

The dimensions give leaders some starting points to think about as they come up with their cost-of-delay estimates, and helps them identify other folks to talk to--and what to ask them--in order to uncover other time and hidden cost estimates. "CD3 is cross-functional!" I say. At least as cross-functional as the best DevOps-embracing Scrum team.

I strongly emphasize that:

  1. All estimates must be provided by the people doing that part of the work, and that know the most about that estimate based on prior experience.
  2. Estimates must come with the mutual trust and understanding that an estimate is neither commitment nor guarantee, but is being used to choose between high-level options.
  3. CD3 is a starting point for ranking features, but that leaders cannot just sit back and let the equations do the release planning for them.
  4. If these techniques are not being done at the highest levels (e.g., portfolio planning), then they're going to be pointless at the feature level.
And I sometimes quip that, since value is an estimate, and time is an estimate, that the "estimate" units cancel out. ;-) 

26 January 2017

Religion: An Apt Analogy for Agile

There are very few topics of exploration that have unceasingly retained my curiosity throughout life. One is software development, another is religious thought.* But in my teens and 20s, I didn't really expect them to overlap...

You've likely heard the word "religion" used to describe the Agile movement (or, now more aptly, the Agile industry), and usually it's meant unkindly.

But it's an apt analogy, and I've often used it myself.  In a way, Agile is indeed an umbrella term for a collection of "religions of software development." I don't think that's a bad thing.

A religion, as a topic of study, circumscribes a set of beliefs, ethics, and practices.  Every religion in history and today has its share of dedicated practitioners, crackpots, expert teachers, and charlatans. Every one started out as a new, challenging idea, appropriate to historical context, and usually rejected by the status quo. Every one provided value to its adherents. Every religion has been abused for personal gain. Every single one.

Over time, some ideas become the status quo, some practices that once had value are performed mechanically, and some ethical systems are paid mere lip-service. Like in a "cargo cult", people will continue to perform the practices though they get none of the value.  Often because they've confused cause and effect.

Agile is no different.  In the late 1990s, we were considered rebellious. Now you will encounter Agile frameworks that recommend ritualized adherence to well-regarded practices, and are packaged in a way that's palatable to folks with Theory X management styles.

Just last week I met with a team resisting Scrum as "too heavyweight" and "requiring attendance at too many meetings." That's sad, because Scrum is intended to be an extremely lightweight approach, with minimal overhead, oversight, or waste. "Where do such misinterpretations come from?!" you may ask. Human nature, my friend.

With Scrum and Extreme Programming (XP) in the 90s, we were looking for a "middle way" (if you'll pardon the personally-biased reference) between basement hacking and the Rational Unified Process (RUP).

We are still, today, looking to improve on the way we build software. The search for greater fluency doesn't ever end.

In my experience, the chosen system of thought, to continue to provide value and comfort, needs to (a) be self-reflective, and adapt to changing context (i.e., it has to "change with the times"), (b) adapt to regional realities and native cultures, while still providing the original, foundational values, and (c) be easy to describe and to learn the basics (though there are always higher and higher levels of fluency to be explored over a lifetime).

"Is he still talking about scaling Agile in a complex corporate setting?!" Of course.

* There are others, and you may note significant overlap, but they are not as relevant to this post: Science, and fitness. Ask me about those; I'll pedantically talk your ear off. You've been warned. ;-)