Last week we visited Florence and then spent a few days in Tuscany ( instead of attending Agile20xx like last year ). The Uffizi Gallery in Florence was formerly the office of the Medici family and is now one of the preeminent collections of Renaissance art in the World. Truth be told, the buildings and architecture of Florenze are more impressive than the art. For some reason, the pictures of Saint Sebastian (Thumbnails below with bigger images at the bottom of the post) held a particular interest for me.
After a while I realised that they are a counterpoint for Scaling Agile. The Artists all agree on certain points such as “St Sebastian was male”, “He was bound and shot with arrows”, “The arrows do not seem to affect him” and “He was wearing shorts made of a sheet”. They did not agree on other points though such as “Was he young or old”, “Where did the arrow pierce his body”, “Did the action take place inside or outside”. To the artists and those in the church who commissioned the works, the differences did not matter. All that mattered was that a Christian Saint was shot with arrows for his faith and survived. I sometimes feel that some of those involved in Scaling Agile are focusing on the details that differentiate them rather than the common things that are important. In a particular context, each of the approaches to Scaling Agile may be more or less relevant.
Instead of focusing on the differences, we should focus on the core common elements and then identify the context where the appropriate approach is more appropriate.
For the past year or so, @TonyGrout and I along with a bunch of other coaches have been trying to help a company to Scale Agile. This is the diagram and explanation I have been drawing for the past few months to help others understand the constraints and issues that we face.
Here is the description I’ve used to some success.
The scaled investment process starts with an Investment Decision Process which identifies an ordered list of investment possibilities ( I call it a list of Unicorn Horns as they are not realistic ). The ordering and naming of this list will be culturally specific. Do they use Weighted Shortest Finished Job, or Cost of Delay, or Business Cases, or just Hippos ( Highest Paid Person’s Opinion ). Who decides on the order? Do they call them MVPs or MVFs, or MMFs, or BVIs, or Investments or Stories or Bets or… The point is that the culture will determine the process to give a rough ordering to the list of potential investments. I will call them MVPs for this post.
The next step is to perform Capacity Planning for the coming period of time (typically quarterly). For this, the owner/promoter of each MVP contacts all of the groups* that need to provide input to deliver an MVP and asks them for a SWAG ( Sweet Wild Assed Guess ) in units of Scrum Team Weeks. The group puts as much effort as necessary into the estimate ( I recommend a solid five to ten minutes at most ). The group also provides their capacity for coming period ( Default is number of Scrum teams in the group multiplied by weeks in period times by 50% ). <Editor’s note. I realised I have not described this process in full on this blog. Watch this space>
* Group – Random name representing a group of one or more Scrum Teams that can work on a component or system within the organisation.
During Capacity Planning, the business investors ( whoever they are ) all come together and select items from the list of Unicorn Horns. For each item they select, they reduce the capacity of the impacted groups. This means the groups form the constraints rather than a generic mythical man month notion of organisational capacity. There are two outputs from this process. One, an ordered backlog for the organisation that all business investors agree to which provides direction to the teams. Two, a list of groups that are constraining the organisations ability to deliver. Note that the constraints are dynamic based on the kind of work involved, although most organisations have a few groups that are needed for pretty much everything. The backlog is the focus for those interested in delivery (short term). The list of constrained groups is of interest to those managing organisational liquidity (longer term).
The Delivery involves the teams adding the items to their team Backlogs. They build the things needed for the MVP which eventually results in a release. The release results in an outcome which feeds back into the investment decision process. This is all very standard Agile/Lean practice.
This is also where our experience differs from standard Agile Doctrine. The belief is that teams will self organise to ensure delivery of the MVPs. This is not what we have experienced. The teams deliver but the organisation does not.
To address this issue we proposed that each MVP is assigned a Product Owner and a Scrum Master who are responsible for its delivery ( I consider accountable and responsible as synonyms. Hopefully someone will explain the difference ).
The MVP Product Owner is responsible for the value delivery of the MVP (The Outcome). As the teams develop the MVP, the MVP PO will let them know what can be descoped without impacting the value delivery.
The MVP Scrum Master is responsible for the delivery of the MVP. They will ensure that the MVP is initiated properly so that everyone involved is aware of their expected contribution. They will ensure that an appropriate architecture is in place. They will set up and facilitate the MVP Scrum of Scrums and Retrospectives. They will ensure transparency on the MVP to ensure all involved can see the status.
The roles are similar to traditional Project Manager and Business Analyst roles with one huge and significant difference. They have NO authority. They influence using transparency and they rely on facilitation instead of direction. This is particularly important as they will develop influencing skills they need when they operate on areas where they do not have authority or influence such as in clients or other business units. They will be servant leaders. To do this, they will need tools to report and show progress.
So this is the software investment process in full. However, we also need to consider governance. A governor was a device on a steam engine that stopped it from blowing up. Two balls would spin around, their speed a function the steam pressure. If the steam pressure went too high, centripedal force would force them out causing them to rise, opening a va would release steam resulting in the pressure dropping. The purpose of governance of governance in an organisation is the same. It ensures that the risks within the system are managed effectively.
The risk managers of the system ( another role without authority other than the power of transparency ) is to ensure that the risks in the system are properly managed, and if the individuals do not have the appropriate skills and experience to manage the risks, ensure that they are provided with coaching so that they can. Consider people playing by a cliff. The risk manager would help to make them aware of the danger. They would show them the cliff and help them work out an appropriate risk strategy. If they wanted to build a wall but did not know how, the risk manager would introduce them to people who could teach them how. The risk manager would monitor the risk to ensure it continues to be managed. This is not about control, but more the appreciation that whilst we are playing in the field, we might forget about other things like risks and demons. Recasting definition of done as a set of risks to be managed allows the teams to find the best solution for their context whilst ensuring that the organisation is not exposed to known risks.
These risk managers are responsible for staff liquidity at the team, group and organisational levels. They are responsible for ensuring the overall investment portfolio is balanced as well as ensuring investment is occurring where it should rather than where it is easy. Rather than simply looking at status of a team, they are considering the health of the organisation as a whole as well as in parts.
One of the most critical risks to address is to ensure that the correct approach is taken to building the teams backlog for the MVP.
The Cynefin Framework is ideal ( and necessary ) for helping teams understand whether they should build the backlog iteratively ( in the complex domain ), or build independent solutions ( in the chaos domain ), or up-front ( in the complicated domain ) or simply let the team do its thing ( for obvious domain ).
A risk management and coaching based approach to delivery and governance is vital for Scaling Agile. It allows software development to fulling integrate with the entire business. However, Cynefin is the “Fifth Discipline” of Scaling Agile to the organisational level, without it, we will be doing the “Wrong things righter, er, The right things wronger”.. without it, we will be barking at the wrong tree.
So have I painted a process where we agree he was shot with arrows? Or does this invite discussion about how old or how good looking he is?
Thoughts?
Paintings of Saint Sebastian
The IT Risk Manager 
July 27th, 2014 at 9:37 pm
Hi Chris
I think this a great model that describes how to apply Agile principles to multiple teams. I particularly like the gradual reveal of using a consistent approach in the macro and then using Cynefin to adjudge individual team approaches in the micro.
With regards to your Saint Sebastian analogy, your approach to “scaling” Agile seems markedly different to other approaches such as SAFe. It seems to be attuned to Arlo Bishee’s original “don’t scale Agile, grow it out of successful teams” recommendation http://arlobelshee.com/scaling-agile-the-easy-way/, as opposed to – what seems to me – SAFe’s nonsensical strategy of applying homogeneity to a heterogenous delivery landscape for an easy marketing message.
I suggest that there might be a reason why artists cannot agree on where or when Saint Sebastian was killed. They might not even agree on _how_ the arrows were fired, and that might be OK. A minority of artists might be better informed than the majority.
Steve
July 29th, 2014 at 12:05 pm
Hi Steve
Thank you.
The big breakthrough was to move away from detailed planning to broad brush capacity planning that involved the whole organisation. This allowed us to identify the contraints, which is the first and, from my experience, the thing people find the hardest part of TOC. Once you have a process to identify the constraints, discussions on prioritisation are now open and focused ( which hopefully leads to a better decision process ).
The other big Ah Ah was when the scrum masters for the teams said they did not all want to coordinate between teams. They were leaving it to product owners which misses huge opportunities for improvement.
I like what Arlo is saying but it strikes me as little niaive and fails to appreciate what is involved in coordinating a large scale company. He comes from the purest software school of Agile and fails to appreciate that as you scale and coordinate between different groups, that the constraint moves around. Quite often the constraint is not a software issue, and more often than not it is policy or HR type stuff. The proof is in the pudding. Arlo coaches at Microsoft Office. When office are making releases every 3 months, we know his approach is probably the best of them all. The reality is that once you talk about scaling Agile, the developer is no longer the constraint, and hence the focus of attention. Other issues need to be addressed which require non development skills. Some people do not like that.
I like Martin’s comment here on the context where Safe adds most value. I need to think more about it. In the absence of Chefs and where Chefs are not allowed ( i.e. at McDonalds…. ).
July 29th, 2014 at 12:29 pm
Hi Chris
In my experience the hardest part of TOC beyond Development and Ops is the lack of instrumentation and measurement.
I am confused by Scrum Masters saying they do not want to coordinate work between teams. If the product owner(s) have established the flow of work the coordination is a delivery problem rather than a business problem, which would suggest Scrum Masters are in a position to help.
I agree Arlo’s points on scaling Agile are development-focussed, but it remains the most compelling approach I’ve found.
As Don Reinertsen or Joshua Arnold would say, so few organisations measure Cost of Delay that there is a lack of urgency and huge potential to improve ideation -> delivery cycle time. When considering the entire organisation as you do I agree it is highly unlikely the constraint is development, testing, or operations. It is far more likely to be features trapped in queues of projects piling up in front of development.
I am hesitant to comment on Martin’s SAFe feedback. I have only an uninformed opinion, but I am extremely skeptical of it.
Steve
July 29th, 2014 at 1:23 pm
Hi Steve
What do you mean by instrumentation and measurement as the hardest part? What do you need them for?
Scrum Masters look after a team. Not all Scrum Masters are comfortable trying to coordinate the activities of several Scrum teams, or even know how.
I’m intrigued that you find Arlo’s approach the most compelling. Does that mean you have a theoretical preference? Or is this based on practical experience of trying to Scale Agile, or the successful case studies he presents? I would love to understand why you prefer Arlo’s approach.
I agree about cost of delay as a powerful tool. Sadly it is not available in all contexts and requires a level of organisational maturity. COD is great the portfolio and Team/Project level in some contexts as a number of the problems do not exist.
I’m curious that you are skeptical of Safe which has had a few successes at scale, but you are an advocate of Arlo’s approach. I would love to understand why. I think (Martin will no doubt correct me 🙂 ) that Martin is saying “If you are very broken, Safe (recipes) is better than other things. If you have solid Agile experience and support, it is probably not for you.
Chris
July 28th, 2014 at 1:09 am
You say that, Steve, but Chris’ description is very well aligned with SAFe (which is very obvious to anyone with knowledge, rather than doctrinally imposed “NO YOU MAY NOT THINK THAT WAY” blinkers).
So Chris, given that your suggestion has two diametrically opposed interpretations, your St Seb analogy may be about right!
July 28th, 2014 at 5:11 pm
Martin,
You seem to be missing the point. In what contexts does Safe work? And in what contexts does it not work?
Chris
July 29th, 2014 at 9:26 am
Well that’s the important question, isn’t it (for any approach)? Where is it a step towards more effective practise, and where is it a step away?
I put keyboard to pixels a while back on SAFe’s target environment
http://everydaylean.info/2013/10/safe-for-its-context/
but the TL:DR version is this:
If your organisation is already capable of and effective in everything we know as current Agile practise, then SAFe is a backward step.
On the other hand, if your current world is the 5 year (or even 1 year) single delivery, and Agility hasn’t succeeded in gaining organisational traction and influence needed to fix that beyond perhaps the tiny bubble centred around programmers (with maybe a little design and test on the edges), it’s a huge step forward.
In other words: all the things about organisational change resistance that Agile communities have been complaining of for ever and have not been very successful at addressing.
If your argument is that it’s not Agile enough, I might agree (at least in terms of an end state). But it’s really using the Kanban thinking of start where you are now, and agree to pursue evolutionary change.
Given that SAFe has Inspect and Adapt loops built in at all levels, how likely is it that an implementation as designed (of course there will be bad implementations too) will go through SAFe as currently defined and find even better ways? If we’re lucky (including Leffingwell being as open to input as he says he is), some of improvements will be more widely usable, and be contributed upstream (think: Ubuntu/Debian).
I’d very much like for your Risk Manager idea to be one of those, by the way.
August 6th, 2014 at 11:32 am
Hi Chris
When you say
“This is also where our experience differs from standard Agile Doctrine. The belief is that teams will self organise to ensure delivery of the MVPs. This is not what we have experienced. The teams deliver but the organisation does not.”
I’d be interested in some examples in a future post.
Steve
August 8th, 2014 at 12:52 pm
[…] way? This is why lightweight rapid relative estimating (Blink Estimating, Storypoints or even Sweet Wild Ass Guesses) can be powerful. All these methods have their own weaknesses, but they’re all more useful […]
August 12th, 2014 at 11:50 am
Christopher Avery has explain the difference between accountability and responsibility on his blog:
http://www.christopheravery.com/blog/the-difference-between-accountability-and-responsibility/
August 27th, 2014 at 3:05 am
Chris,
Riddle me this…
Why the overhead of a MVP Scrum Master in addition to the MVP Product Owner?
The MVP-PO makes complete sense. The MVP Scrum Master is a head scratcher for me. If I envision the typical role of an SM – coaching the team, I’m not seeing how having someone at a broader level is helpful. What am I missing?
I know this is based off your actual experience so please fill me in on what problems that setup helped address.
Thanks!
Kent
August 27th, 2014 at 6:13 pm
Scrum Masters are normally members of the development team. They are happy owning the process for the team but do not necessarily see coordination between teams as part of their responsibility. In fact, they see it as the role of the product manager(s), and that the coordination is achieved through their backlog. The MVD Scrum Master owns responsibility for the delivery of the MVD. This means they can pull the teams together to agree on architecture and delivery approaches that might not sit comfortably with the PO. e.g. The MVD Scrum Master might pull the teams together to agree on APIs and mocking/testing approach. This might create some feedback into the PO’s backlog and the order that work is done. Specifying APIs could quite possibly be outside of the responsibility of the PO.