Scaled Agile Framework Applied - Part 1/5: Introduction and Context

Since encountering Dean Leffingwell’s Scaled Agile Framework(SAFe), I have presented the model to dozens of senior executives and middle management from numerous enterprises grappling with the question of how to effectively scale agile.  Without exception, the ‘Big Picture’ resonates.  It is easily incorporated in their mental model of the key ingredients in delivering enterprise scale outcomes, and a 1 hour overview leads to the response ‘I can believe in that’. 

The challenge, of course, arises when you start to delve into the follow-on question – “Now how do I make it work in my special situation?”  Like any good framework, it is designed on a set of principles.   Implementation requires leveraging your understanding of the principles to tailor the detail to your situation.

In this series of posts, I will endeavour to illustrate with working examples the fashion in which it has been applied in the group I have been guiding for the past 9 months.  

Approach

The success of this implementation has attracted a great deal of interest in both the enterprise the group belongs to and other Australian companies grappling with scaling agility.   On a weekly basis, groups visit to understand ‘how it is done’.  

Over time, we have established a ‘2-hour tour format’ that walks the model.   Tours always begin at an A0 poster of the ‘big picture’.  We spend 5 or 10 minutes giving a brief overview, then proceed to work our way through the portfolio, program, feature and team kanban walls illustrating the way work flows through the layers of the model and the type of discussions they facilitate.  My intent in this series will be as much as possible to provide a simulation of a physical tour.  It will be structured as follows:

• Part 1 - Introduction and Context
• Part 2 - Demand management and the portfolio kanban
• Part 3 - Program level pipeline management and the program kanban
• Part 4 - In-play work and the program level feature wall
• Part 5 - Results to-date and Conclusion 

Context 

The setting is a large enterprise in the midst of an Agile transformation.    They experienced good success with many smaller agile projects, but encountered significant challenges in the early stages of applying it to major programs of work.  Over the course of 2012, 4 major groups across the enterprise successfully adopted SAFe.  Each applied it to different problems and tailored it to suit – the one I will be writing about focuses on business intelligence and data warehousing. 

In April, I heard Dean describe his typical approach with a new client as “give me your worst program, I’ll fix that first and we’ll keep adding a program at a time from there”.   It’s a fairly apt description of the case at hand.   Agile project teams existed, but knitting them together into a program with appropriate cohesion, visibility and governance continued to be traumatic.  The model was applied first at the program level (the 2^nd and 3^rd layers of the framework), then extended up to the portfolio level and additional programs are now being transitioned in.

One other piece worth noting is that we are not yet describing a full enterprise-level SAFe implementation.   It is being actively explored, and what is known so far is that it will require 2 additional portfolio layers as the various groups are brought together.  I will be describing an implementation keeping 3 programs or delivery groups and roughly 200 people busy, but the eventual target involves more than 5,000.

Having set the scene, in Part 2 I will explore demand management and the portfolio layer implementation.

Book Review: The Secrets of Consulting

When I started this blog, I set a rule for myself that I would never post simply to point out interesting ideas from others without adding some form of value regarding the application of those ideas.  I'm about to break it.

I was reading about Virginia Satir's techniques for helping others/yourself to transform ingrained behavioural rules a few days ago.  It offered the insight that you could apply a three-step transformation to a rule such as "I must always deliver good news" as follows:

1. Change the word "must" to "can" - ie "I can always deliver good news"
2. Change the word "always" to "sometimes" - ie "I can sometimes deliver good news"
3. Apply a "when clause" listing the conditions under which you can do it - ie "I can deliver good news when I don't have to lie to do it or what might seem 'bad' to me might be good to someone else".

I thought this was an interesting technique to apply in helping people move into transparency under Agile.  Sometimes the "Green status report" culture is so deeply ingrained it takes a lot of shifting, and I could see this system really helping people to move through the transition.  

Then, I took the 'self-examination' focus and thought about rules I could apply it to in myself.  I am constantly encouraging both people I coach and friends to pick up books that have inspired me.  Twice this week I handed my kindle to a friend and said "here, this book is gold .. check the stuff I highlighted and you'll see why you need to read it."  Last night I realised I can write myself a new rule:

I can blog simply to point out interesting ideas from others when my purpose is to inspire others to follow the ideas to their source for elaboration.  

So, with that rule in hand I would like to inspire those who read this blog to go read Jerry Weinberg's 'The Secrets of Consulting'.  Jerry has written many many books, and prior to meeting him at AYE this book would have been absolutely bottom of the priority list for me.  I looked to him as a source of inspiration on Systems Thinking, not consulting!  I've now read it and highlighted more insights than in any other book I've read in the last 2 years.  Despite being written long before Agile came into being, it is just a must-read for anyone who is either an Agile coach or some other form of change agent.

Following are my favourite dozen quotes (in no particular order), enjoy them and go to the source to read the anecdotes that lie behind them and discover your own favourites:

The First Law of Consulting: In spite of what your client may tell you, there's always a problem.

The Second Law of Consulting: No matter how it looks at first, it's always a people problem.

You'll never accomplish anything if you care who gets the credit.

People who can solve problems do lead better lives.  But people who can ignore problems, when they choose to, live the best lives.  If you can't do both, stay out of consulting.

Know-how pays much less than know-when.

The chances of solving a problem decline the closer you get to finding out who was the cause of the problem.

If you can't think of three things that might go wrong with your plans, then there's something wrong with your thinking.

Any time you're afraid to say no to your client, you lose your effectiveness as a consultant.

Sometimes when I'm not getting anywhere with the words, I listen to the music ... When words and music don't go together, they point to a missing element.

Your ideal form of influence is first to help people see their world more clearly, and then to let them decide what to do next.

It may look like a crisis, but it's only the end of an illusion

Your primary tool is merely being the person you are, so your most powerful method of helping other people is to help yourself.

PS: I'm unashamedly on a Weinberg kick right now.  The rule transformation technique is taken from "More Secrets of Consulting"

  

What I learnt at the AYE Conference

I spent last week in New Mexico at the Amplifying Your Effectiveness (AYE) conference with Jerry Weinberg, Esther Derby, Johanna Rothman, Don Gray and 75 other attendees.

Since hearing about the conference format and making the commitment to attend, my excitement had been growing.  The concept of a ban on powerpoint, no session shorter than 3 hours, and every session facilitated by someone I deeply respected sounded too good to be true.

The week before leaving, one of the recurring themes in the office was the difference between “Capital ‘A’ Agile” and “little ‘a’ agile”.  The metaphor mapped ceremonies and practices to the “Capital A”, and teamwork, collaboration and vision to the “little a”.   We had enjoyed some rich discussions around the temptation to settle for proficiency with the “Capital A” because pushing into the “little a” was where it got hard.

AYE’s theme was “Human Systems in Action”, and I was very much looking forward to experiencing deep teaching on the “little a” side.   The first lesson I learnt was that I had gone for the wrong reasons.  I anticipated a week of “filling up the toolbox” with new coaching tools and techniques, and by the end of the second day I was feeling a little frustrated.  I was debriefing on the day with my wife, and the tone of the debrief was “I’m learning lots, but I’ve got no new tools I can put into practice”.  She looked over at me and asked whether I was missing the point.  Of course I hotly denied it at the time, but it raised a seed of doubt that started to grow as the sessions went by.

In the final session of the formal conference, it finally sank in.  It was a consulting masterclass with Jerry Weinberg, and he ran it as a series of case studies.  It was initiated  by asking us each to consider the thorniest problem we were currently facing as a consultant.   I was then introduced to Jerry’s technique of selecting the last person to raise their hand as the most fruitful case to examine and found myself in the 'consultee' chair next to Jerry.   Over the course of the next 20 minutes, I was turned inside out as he showed me the way in which my lack of belief in myself was the cause of the problem.    Whilst on the one hand it was incredibly useful, it was also an incredibly challenging experience being laid bare in front of 45 people. 

Over the following 2-3 hours, the reality of the power of AYE sank in as one after another people came up to me and thanked me for my courage in the hot-seat, commiserating with me on the pain of the experience whilst sharing the fashion in which they had benefited. 

A quote from Jerry’s book The Secrets of Consulting is the most fitting way to sum up my eventual AYE learnings – “Helping myself is even harder than helping others”. 

I didn’t learn any magical new secrets.  I didn’t learn any stunning new facilitation techniques.    The truth is there are no “big bang” revelations or magical secrets to Human Systems.  What I did was learn some new things about myself,  recognise some poor decisions I have made as a coach, and discover some new areas in which I need to grow in order to be more effective for my clients.

In the process, I made an incredible number of new friendships with people I look forward to learning from in the years to come.  If only every conference could be so fruitful!

Now that I've had a week to start to internalise it, I think the biggest insight for me lies in checkpointing myself as a coach.  I (along with all good coaches I know) spend a lot of time looking to fill up my toolbox with new techniques or deeper insights into existing ones.  I spend a lot less time searching for people who I trust to reveal flaws in my current insights.  

Thanks to Jerry, Esther, Johanna and Don for creating an environment where not only do they as facilitators hold the mirror up to attendees but also foster the trust and safety for us to share the mirror with each other.   

Escape Velocity with Agile – mastering the transition through Horizon 2

In Part 1, I proposed the alignment between the phases of an agile transformation and Mehrdad Baghai’s three investment horizons as follows:

• Early agile pilots equate to high risk horizon 3 investments
• Early strategic rollout equates to medium term horizon 2 investments
• Agile as the de-facto delivery method equates to horizon 1.

In this post, my focus will be on leveraging Moore’s thinking regarding effective transitions between horizons.  The final Escape Velocity chapter is titled  ‘Execution Power: Engineering the Escape’, and opens with the following statement: “The challenge is to deploy a next-generation initiative at scale, overcoming the inertial resistance of our current go-to-market system to do so.”

Moore describes an arc of execution where any initiative goes through 3 modes: Invention, Deployment and Optimization.  These by and large map onto the 3 investment horizons as follows.  A Horizon 3 initiative is purely invention.  Horizon 2 is a blend of invention and deployment with the balance shifting towards deployment as it nears Horizon 1, and Horizon 1 begins with some deployment but is primarily oriented towards optimization.

Two key themes resonate throughout the chapter.  The first is that a different style of management (and inherently a different set of managers) is required for each mode, and the second that effective transition between modes is the cornerstone to success – “each transition consists of a program to drive the organization to a tipping point so that what began under one set of managers is now fully taken up by another”.

The entire intent of a good agile adoption is to create a learning organisation with a culture of continuous improvement, which should make the transition from deployment to optimization trivial.   For me, the transition from invention to deployment is the focal point – beautifully summarized by Moore:

“… the handoff between inventors and deployers is unnatural because visionary inventors think their work is done as soon as the first instance of the new offer has been proved to work; pragmatist deployers are not willing to take responsibility for something until there is proven market momentum behind it.  This leaves the inventors fuming that no-one is taking up their offers while the deployers are rolling their eyes wondering who is ever going to clue these people in.  Absent any meaningful handoff, the deployers will cling to the low-growth legacy opportunities where their bread is buttered today”.

In driving this transition, Moore argues strongly the invention-mode requirement for a “fully integrated team in which all the mission critical functions – R&D, engineering, manufacturing, sales, services, and marketing report directly into a single entrepreneurial leader”.   He later emphasizes that the team orchestrating the transition must also not only be cross-functional but empowered … “Members of the team must be empowered to commit their functions to the new way of going – there can be no nonrowing observers on this boat.  Absent that capability to commit, cross-functional exercises degenerate into an endless series of meetings with no actionable outcomes other than to schedule the next meeting.”

In the context of an enterprise agile transformation, the functions represented may be different but are no less important to successful transition.  The functional lines must at minimum include governance, finance, release management, operations, enterprise architecture and legal.  In a heavily outsourced scenario, one must also argue for senior vendor representation in the group as part of the lean supplier transition from vendor to partner.

In a typical large enterprise, building high performance development teams is child’s play compared  with successfully re-aligning the corporate governance processes.   Agile transformation all too easily defines these functions as ‘outside the system-of-work’ and falls for the trap of localised optimisation.   The reality is true enterprise-scale success cannot exist without bringing the entire system of work into alignment.

My argument is that if you apply Moore’s ‘transition orchestration team’ concept to agile adoption, you must wind up with an agile working group formed along his lines.  Rather than a group of coaches and agile advocates attempting to drive change out into the governance line functions, you bring the line functions into the group. 

Inevitably, there will be a significant period where waterfall is still the horizon 1 delivery metaphor for the enterprise and agile is moving through horizon 2 maturity and the two compete for resource and influence.   If empowered representatives of the functional silos are embedded in the process throughout transition, the transition team not only understand the entire system of work but possess the influence required to successfully conceive and execute the change.  

The most powerful aspect of this approach is that you then seize upon the tacit knowledge creation cycle.  By working within the agile transition initiative, the line function representatives ‘learn by doing’.  They gain tacit experience of the underlying agile principals, and can drive their deployment into organisational process based on informed situational practice.  As the initiative moves from deployment mode to optimisation and the working group returns to its line function fold, the knowledge creation cycle is completed.

Achieving Escape Velocity with an Agile Transformation – Part 1

One of the things I always look forward to when attending a conference is hearing about the books which are inspiring the people who inspire me.  I can just about rate the conference by the number of books I’ve added to my reading list.   On that basis, the Colorado RallyOn conference in April scored highly.  I headed for the long flight back to Australia loaded up, and chose Geoffrey Moore’s Escape Velocity as the opening dish.

Given that the customer I was working with at the time was pushing strongly into agile portfolio management using the Scaled Agile Framework, I was hoping for rich new insights on the application of investment themes.  As I read, I was far from disappointed on the insight front but struggling with application.  It was easy to see how Rally was applying his thinking, and by extension I could see how to apply it in the small to medium enterprise space.  The trouble was that I primarily work in the large enterprise space but rarely far enough up the food chain to be influencing the kind of foundational business strategy the book addresses.

Nonetheless, I read on.  The material was so fascinating I couldn’t put it down, and resigned myself to filing the insights for future clients.  Unfortunately, I’m not very good at resigning … my subconscious kept searching for some way to apply it.  Eventually, I started to feel like I’d escaped the box.

In July, Rally’s Ronica Roth was in town and we got to talking about her recent internal coaches’ conference.  They’d had a half-day workshop on accelerating agile rollouts, and enjoyed some animated debates.  The key topic on the table was the tension between clients “wanting to be agile at scale, and wanting it now” and their preferred model of nurturing a core agile capability for clients before attempting to ramp up.   The moment seemed ripe, so I tried my thinking on Ronica.  What about applying Escape Velocity thinking to Agile transformations?  Her response was encouraging enough to send me putting pen to paper.

Moore’s book is focussed on addressing the imperative for companies to be constantly exploring new markets, products and services in response to the threats to existing offerings from global economy competitors.   He offers a framework for selecting, initiating and nurturing growth opportunities.  The “escape velocity” analogy lies in comparing the power of the earth’s gravity to prevent “escape to orbit” with the effect of procedural inertia on company’s attempts to seize on opportunities for radical transformation in the market.  His premise is that you need to incorporate specific “inertia counters” in your strategic portfolio planning model to achieve “escape velocity” for your company.

Underpinning his thinking is the application of Mehrdad Baghai’s “Three Horizons” model to portfolio planning.   The three horizons are as defined as follows:

• Horizon 1 investments are expected to contribute to material returns in the same fiscal year in which they are brought to market, thereby generating today’s cashflow
• Horizon 2 investments are expected to pay back significantly, but not in the year of their market launch
• Horizon 3 investments are investments in future businesses that will pay off in the out years beyond the current planning horizon. 

Moore explores in compelling detail the financial and operational tension between the three investment horizons.  In short, Horizon 1 investments tend to focus on preserving market life of existing products and generally fight an inevitable decline rather than targeting significant growth.    They dominate cashflow, and thus inevitably dominate demand for operational and financial support.  Horizon 2 investments, on the other hand, represent tomorrow’s reasonably sure opportunity.  They suffer from ‘making material demands on go-to-market resources … without generating corresponding material returns’.  In contrast, Horizon 3 investments are ‘long-bets’. 

The contrast Moore focuses on between Horizon 2 and Horizon 3 investments is the weight of expectation.  Based in large part on the contrast between their drain on resources and lack of realised returns, there is significant pressure on Horizon 2 initiatives to rapidly mature, whereas there is an acknowledged ‘experimental air’ to Horizon 3.

So, let’s pull this back to Agile Transformations.  Moore defines three types of innovation: Differentiation, Neutralisation and Productivity.  Agile falls neatly into the productivity category, although there is also an argument that for some companies it is necessary to neutralise the advantage gained by competitors who have already succeeded with agile adoption. In essence, it is a deliberate investment in a company’s ability to support business innovation through a mobilised, responsive and aligned IT delivery capability

There is an almost universal pattern to a corporate Agile adoption.   It begins with a nervous ‘toe in the water’ set of pilot projects.   Carefully selected for Agile suitability and given special privileges with corporate IT processes, these are used to test the water.  We can treat these first pilots as the “Horizon  3” phase of the investment.

By and large, the pilots are radical successes and the backers breathe a sigh of relief as they discover that ‘this Agile stuff’ is not just hype.  The transformation then moves into Horizon 2 and begins the bridge to the mainstream.  An Agile Working Group is formed to champion corporate adoption, coaches and trainers are engaged, aggressive ‘Agile adoption targets’ are set and the Agile Transformation is off.  

At this point, the tension between Horizons 1 and 2 sets in.  Governance, support, management and vendors are torn between supporting the still mainstream waterfall delivery processes and the burgeoning demands of more significant Agile initiatives.  It’s a little like contrasting dancing on the edge of the surf in bare feet to the shock of diving through that first wave.

Companies that successfully navigate this phase then move into Horizon 1 – Agile is the de-facto approach and optimisation begins. 

What I’ve both experienced and repeatedly heard is that the transition through Horizon 2 is often protracted, painful and eventually unsuccessful.   Moore has a great deal to offer on both the construction of Horizon 2 & 3 initiatives and more importantly the transitions between the 3 levels, and it is this that I will explore in Part 2 of this post.