Create
cancel
Showing results for 
Search instead for 
Did you mean: 
Sign up Log in

Choice is Good

Scott Ambler February 21, 2019

Let’s assume for a minute that your organization has multiple teams working in a range of situations, which in fact is the norm for all but the smallest of companies. How do you define a process that applies to each and every situation that covers the range of issues faced by each team? How do you keep it up to date as each team learns and evolves their approach? The answer is that you can’t, documenting such a process is exponentially expensive. But does that mean you need to inflict the same, prescriptive process on everyone? When you do that you’ll inflict process dissonance on your teams, decreasing their ability to be effective and increasing the chance that they invest resources in making it look as if they’re following the process when in reality they’re not. Or, does this mean that you just have a “process free-for-all” and tell all your teams to figure it out on their own? Although this can work it tends to be very expensive and time consuming in practice – even with coaching each team is forced to invent or discover the practices and strategies that have been around for years, sometimes decades. Luckily, the Disciplined Agile toolkit provides a better way.

Different contexts require different strategies – teams need to be able to own their own process and to experiment to discover what works in practice for them given the situation that they face. This is why the DA toolkit presents people with choices through the application of process goal diagrams. The idea is to make important decision points explicit, such as when to accept changes, and then present teams with their options and the tradeoffs surrounding those options. This enables teams to make better process choices given the situation that they face. To make these choices, teams need to know:what each option is, the tradeoffs associated with each one, and in what situations the option is and isn’t applicable. 

This choice-driven strategy is a middle way. At one extreme you have prescriptive methods, which have their place, such as Scrum and SAFe which tell you the one way to do things. Regardless of what the detractors of these methods will tell you these prescriptive strategies do in fact work quite well in some situations, and as long as you find yourself in that situation they’ll work well for you. However, if you’re not in the situation where a prescriptive method fits then it will likely do more harm than good. At the other extreme are experimental methods such as Spotify that tell you to experiment and learn as you go. This works well in practice but can be very expensive and time consuming and can lead to significant inconsistencies between teams which hampers your overall organizational process. Spotify had the luxury of evolving their process within the context of a product company, common architecture, no technical debt, and a culture that they could grow rather than change.  DA sits between these two extremes – by taking this process goal driven approach it provides process commonality between teams that is required at the organizational level yet provides teams with the flexibility required to tailor and evolve their internal processes to address the context of the situation that they face.

The DA toolkit can help your team to increase the effectiveness of retrospectives.  In a retrospective you will identify one or more things that you would like to improve.  But how can you improve it?  If there's nobody on the team with experience in that area, it can be difficult to identify a potential solution to your problem. With DA, your team can easily lookup potential strategies, either online or using our new book, Choose Your WoW!  Teams can choose from known strategies the likely options to then experiment with, increasing the chance that they find something that works for them in practice. At a minimum, it at least makes it clear that they have choices, that there is more than the one way described by the prescriptive methods.

There is a catchy phrase in the agile world called “fail fast” or better yet “learn fast.” As described earlier leadership should encourage experimentation early in the interest of learning and improving as quickly as possible. However, we would suggest that by referencing the proven strategies in Disciplined Agile you will make better choices for your context, speeding up the learning process and failing less.  Better choices lead to better outcomes.

2 comments

Comment

Log in or Sign up to comment
Carson Holmes
I'm New Here
I'm New Here
Those new to the Atlassian Community have posted less than three times. Give them a warm welcome!
February 21, 2019

First of all, it appears that you borrowed the tag line of the Advisor platform, which has been on the product banner for at least 7 years, or since development began in late 2010. Advisor - "Better Decisions mean Better Outcomes". What DA is throwing about now, as mentioned at the bottom of this post, and on blog posts on the DA site - "Better Decisions lead to Better Outcomes". Looks like substantial similarity to me.

Second, you imply that publishing multiple ways of working across large enterprises doesn't scale. As you assert this through your series of questions on "How to define a process ..." or "How to keep it up to date..." in your first paragraph, you should know full well that these capabilities have been around for quite some time in SDE's Enterprise Transformation Advisor. You state "The answer is that you can’t, documenting such a process is exponentially expensive." This is false, as our platform makes this economical at scale. While I agree that ramming a single way of work down everyone's throat, treating everything like a program like SAFe is a particularly nasty habit that our industry has, Advisor has been enabling teams to contextually declare their way of working using our industry first (and universal) practice choice architecture since, well late 2010. Building hybrid, agnostic practice-based approaches was fully documented in Value Stream: Generally Accepted Practice in Enterprise Software Development, circa 2014. US Patent - circa 2011. The origins of how to make this real so that one can explain why "succeeding projects succeed, failing projects fail" goes back further to SDLC 3.0: Beyond a Tacit Understanding of Agile, 2010.

Everyone reading this post should know that the essence of what is now being marketed in the Disciplined Agile "toolkit" "related to "Process Goal Diagrams" and "Choice is Good" has been around in Value Stream, and more importantly, The Enterprise Transformation Advisor for quite some time - like since April 2010. It has context declaration through 9 determinant scales, practice-based choice architecture to empower teams to declare their way of working, and risk advice and tradeoff analysis through a rules-based expert system (only in Advisor). Cultural affinity rules as well. Oh yeah, it is also software that can enable Inspect and Adapt with the reach to scale to the enterprise. Heck, even the entire industry. Its Been around long before the DAD book in 2012 and definitely long before the rewrite in "Choose your Wow" 2019.

Just setting the public record straight.

Scott Ambler February 21, 2019

Carson, thanks for your response.

I didn't realize advisor has the tag line of Advisor was "Better Decisions mean Better Outcomes."  Geniuses think alike!

Yes, there are a lot of great process definition and documentation tools out there, and they definitely can help in the right situation.

Scott Ambler February 22, 2019

Carson, as you know, building processes from agnostic practices, with or without tooling, certainly isn't a new concept.  For example, we originally met via Rational (now IBM Rational).  They've had a product called Rational Method Composer (RMC) since at least the early 2000s that allowed you to tailor your own processes.  More interesting, I think, was in 2006 when they open sourced part of that product and donated it to the Eclipse Foundation.  This product was called Eclipse Process Framework (EPF) and its premise was that people could develop process plug-ins, either open source or commercial, that could then be used by others to build their process.  These plug-ins comprised one or more practices.  In fact, I developed and then donated a plug-in for agile database techniques that I had put together a few years earlier in the form of the Agile Data method.  More recently I worked with Ivar Jacobson Inc. last year to create an essential definition of database refactoring for their platform.  That should be publicly available soon.

On the process side of things, there is a very deep history of this.  In fact, in the SDLC 3.0 book, Mark Kennaley has a pretty cool (at least from a process nerd point of view) history timeline of how various methods/processes built on each other over the years.  Just looking at my work, for example, in 2005 I published the Agile Unified Process (AUP) to show that the UP can be agile, much simpler that what Rational was pitching, and captured in a very simple format.  You can still download the AUP free of charge (it has always been freely available) and see that it's described as a collection of practices, sourced from all over the place, with links to external pages describing those practices.  AUP is severely out of date now of course.  Then there is Agile Data (2003), which builds on practices from Agile Modeling (2001), which in turn builds on practices from Extreme Programming (1999), which in turn included practices from other sources (pair programming was Larry Constantine's "two-coder approach" for example). Then there was all the great process patterns work that happened in the 90s, and is still going on today for that matter. 

And of course the idea of putting things into context isn't new either.  There's Philippe Kruchten's Octopus model which he was working on in the late 00's and published around 2012.  In parallel to that when I was at IBM I developed the Agile Scaling Model (ASM) which we published around 2009/2010.  ASM later evolved into the Software Development Context Framework (SDCF). And of course you could very likely find other context models created long before those ones.

Anyway, thanks for the trolling.

Like Alvaro DAlessandro likes this
Mark Kennaley
I'm New Here
I'm New Here
Those new to the Atlassian Community have posted less than three times. Give them a warm welcome!
February 22, 2019

I don't think using a pejorative like "troll" is called for, as it is important to raise awareness of the importance of this topic to the public with what is going on out there with prescriptive methods like SAFe and LeSS and how to break the vicious cycle. I commend Carson for raising this issue. No one is discounting the huge contributions to method engineering that you or Dr. Kruchten have made with RUP and its evolution towards AUP and then DAD. The point is that the public should know that the vision of situational method engineering, long ago /started/ by Victor Basili in "The Experience Factory", is now real and concrete. But to make it feasible and economical at scale, requires some rather powerful software. RMC or EPF is hardly the same as Advisor. Advisor is the "how" to pull off self-organization and "inspect and adapt" at scale that has been missing all these years. To go beyond the ills of "processware collecting dust on a shelf" from the software industry's past requires being able to corrrelate these ways of working to function-beyond-form, and most importantly, the function of the constituent practice parts within the overall declared ecosystem. As in internal ecosystem context. Not as simple as just icons on a palette. Development case documents and hard-wired XML hardly a substitute for dynamically generated, aspectual Value Stream Networks driven from a practice choice architecture, delivered as SaaS with a highly normalized database.

It's good to see you guys evolving your goals diagrams of practice choices beyond the original phase objectives of RUP. It is now basically equivalent to one possible view of SDE's Universal Kernel, something that was fundamentally different that had no prior art at the time it was cast in 2011. SEMAT gave it a shot, but missed the most "essential" element of all common to all software endeavors - feedback. Guess they didn't have a systems thinking background. And as you point out, SDLC 3.0 started to put out there how we study feedback in management science. Alistair Cockburn;s "Heart of Agile" is also a close call, but way too simplified to be of much utility at scale. Philippe's "Frog and Octopus" model started getting officially published around 2012 if I recall but with a model in my opinion missing in a similar fashion to Ivar's attempt; and definitely no choice architecture stuff, more focused on teaching. I do recall becoming aware of it right after the "Contextualization of Software Development" conference SDE held up at Whistler that both of you attended in 2013.

Great minds do think alike Scott. Better Decisions mean Better Outcomes (section 9.5 in Value Stream from 2014 that describes in great detail Decision-centric Capability Improvement) is in my opinion far more necessary for our industry than the activism in the Scrum slogan "Changing the World of Work".

TAGS
AUG Leaders

Atlassian Community Events