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.

The importance of Scaled Learning to Scaled Agile

I was facilitating a fishbowl discussion on Leadership at the recent LAST Conference when one of the participants suggested that we should take what we know about the importance of "Slack" to improvement in agile teams and plan in 20% slack for Agile Leaders to give them space to focus on improving their leadership.   I was focussing on facilitating rather than contributing at the time, but my immediate internal response was that most senior leaders I know are managed by their diaries.  Their opportunity to create this slack lies in exercising the choice to deliberately reserve space in their schedule for leadership rather than management.

"Deliberate choice" is the phrase that really sums up what I'm trying to explore in this post.  Regardless of your preferred flavour of Agile, at the team level a number of choices are made for you.  Some mechanism such as the sprint retrospective will exist to dictate investment in shared learning and improvement, and others such as standups, sprint planning and WIP visualisation to promote teamwork and "geting the team on the same page".

In my early Agile endeavours introducing Scrum and XP to small teams, I repeatedly experienced the oft-promoted phenomenon of "radical change".  Whilst I began in the "Shu" of blindly following the practices and ceremonies suggested by thought-leaders, I came to realise that this radical change came about through the provision of a "scaffolding" within which the team could self-organise and the deliberate choice to invest time in working as a team to reflect and improve.

In recent years, I have primarily been applying Agile in large high-formality enterprises pursuing scaled implementations.  My constantly-frustrated desire has been to find the secrets to achieving the same radical pace of change in these environments that I saw in my early days.  Whilst I found many inspirations in the writings of Highsmith, Larman and Vodde it has been Dean Leffingwell who has triggered my biggest breakthroughs with his focus on building the "self-organising program".

I often find myself in discussions which critique Dean's model as overly proscriptive and "process-heavy", but what I have found in recent months as I work with people applying it is that it provides the opportunity for scaled level "Shu Ha Ri".  Whilst in theory I have known the underlying principals, it has been in helping people apply the practices and learning through failure that the real breakthroughs have come in moving from being able to talk about the principals to being able to realise them.

I have come to believe that the purpose to creating a "Self-organising team" is to enable rapid learning across the team and constant tuning of dynamics and collaborative optimisation within it.  The scaffolding which permits self-organisation (such as Dean's Scaled Agile Framework) is not the end in itself, but the enabler for scaled learning.

In my last post, I wrote about a program leadership team sprinting their way towards their first PSI planning session.     Shortly after writing the post, the team concluded for a number of valid reasons that formal application of the PSI construct did not lie in the short-term future.   At the same time, there was universal agreement that alternative practices were needed to pursue the principals underlying the PSI in the interim – in particular the PSI planning session and the Program level shared learnings.

This moment in time provided a pivot point in learning for the program.  Where the pace of learning had been slowly and linearly increasing in the preceding 12 months, the learning curve has gone exponential in the last 3.  Following are 3 of the key contributors to this change.

Book Clubs

Whilst there’s nothing new in this idea, in my experience it’s typically introduced as an optional ‘brown-bag’ concept attracting the passionate to invest their own time.  In this context, the general manager felt so passionate about supporting shared learning that it was born as scheduled mandatory meetings on work-time.

The initial book club involved the senior leadership team and used Dean's Agile Software Requirements Book as the text.  Chapters were assigned to logical owners, and each session would cover 1 chapter with the presenter documenting their key insights on the Wiki and other attendees making sure they’d at least read the chapter to be able to contribute to the discussion.  The underlying theme was “What are the key insights, what are the underlying principals, how do we adapt them to apply to our world, and where are we doing well/poorly with current execution”. 

Despite initial push-back by many with over-crowded diaries, these sessions  have become a weekly highlight now.  Each time I attend, I get a warm glow as a coach as I listen to the participants debate improvements at a depth I could not have conceived 3 months ago.  Improvement stories are generated for a dedicated program improvement backlog with the GM acting as product owner.

This has been so impactful, it has spurred the start-up of two more book-clubs in recent days – one for the Scrummasters studying Lyssa Adkins' Agile Coaching book  and one for the tech leads to study Ken Collier's Agile Analytics.

The Innovation Challenge

On the improvement front, two things were painfully apparent.  One was the fact that the ‘improvement actions’ coming out of team retrospectives were the first things to be sacrificed when the following sprint came under pressure, and the other was the fact that teams weren’t learning from each other – the vast bulk of successful improvement was localised.  Inspired by some ideas I came across in the Rockefeller Habits, I pitched the idea of rewarding innovation to the GM and the innovation challenge was born. 

We created an ‘innovation wall’ opposite the kitchen with a space for every team.  Any innovation achieved during the sprint could be posted on the wall regardless of whether it involved removing waste, improving productivity, improving quality or changing the way the team worked together.  At the end of the sprint, the teams would dot-vote for “innovation of the sprint” and the winning team would receive $100 for team celebrations. 

Unity Day

This one is very much a case of saving the best till last.  The key goal of this was to tap into some of the “whole program in the room on the same page” benefits built into the PSI Planning concept.  It has been a wild success.  The session typically runs for an hour and a quarter first thing  on day 1 of each sprint with 70 odd attendees (and a ban on powerpoint).  The agenda varies a little in time allocation and sequencing, but the key elements are as follows:

• ·      Appreciations from the leadership
• ·      Voting on the innovation challenge
• ·      Agile learning activities
• ·      Report-ins from the huddles
• ·      Warnings and Tips from technical leadership
• ·      Upcoming work in the pipeline

Appreciations from the leadership

Cheerfully stolen from my friends at Rally, this is the opener for the session and involves 5 minutes for senior leadership to share good news stories and appreciations for teams either heard from customers or observed themselves in the past sprint.

Voting on the Innovation Challenge

Teams’ innovation sheets are plastered around the walls, and each team gets 1-2 minutes to talk to their key innovations for the sprint.   Contributions vary from team members teaching each other keyboard shortcuts and cross-skilling sessions to implementation of new design patterns and integrations with other applications.

Each team has a set of 8 dots (different colors/shapes for each team to prevent self-voting), and they’re given 5 minutes to wander around the room and dot-vote for their favourite innovation, following which the vendor sponsoring the award for that sprint hands over the goodies.

Despite some humorous attempts at rorting the system with one team promising to spend the whole reward on lollies for their team area and an open invite to others to share in the goodies, it’s become a great way of sharing learning and is now being followed up by brown-bag sessions for deep-dives into the winning innovations.

Agile Learning Activities

Being the shameless coach I am, I usually steal 20-30 minutes of the session to run some kind of game.  Teams are randomly formed, and we run learning activities such as the ball-point game, the penny game, and the agile airplane game.

Probably the most enjoyable moment so far in this segment was the mayhem as 80 or so paper airplanes were flight tested at the end of each iteration of the airplane game. 

Report-ins from the huddles

5 huddles run 2-3 times per week.  Scrum of scrums for the scrum-masters, and discipline huddles for tech leads, test leads, BI leads and ETL leads.  This is a short segment looking for 1-2 minutes of highlights on learnings from the huddle for the preceding sprint.

Warnings and tips from technical leadership

There are usually 2 sheets of butcher paper for this segment.  In short, “things to watch out for” and “things you might benefit from”.  It’s a consolidation of warnings of potential impacts (such as Olympics deployment embargos) and advice of newly available utilities and enablers.

Upcoming work in the pipeline

This segment is basically a heads up on pieces of work that are progressing through the program kanban and either kicking off that day or 1-2 sprints away.  It’s primarily aimed at keeping teams informed of what the near-term roadmap looks like and which teams are focussing on what areas. 

Conclusion

Teams leave the room, grab a coffee and get into Sprint planning.  

Back to the self-organising program

I started this post talking about "deliberate choice".   When you distill down the rambling, I'm talking about a deliberate choice to build "program as team of teams" and foster learning at the program level.  It's an investment decision.  Putting a team reward and recognition program in place to reward innovations is an investment.  Putting a program management team in a room once a week to study a book is an investment.  Putting 70 people in a room for an hour and a half to play agile games and get on the same page at the start of a sprint is an investment.

What are you investing in?  You're investing in creating a sense of team among teams, and in creating learning between teams rather than just within teams.   If you want radical change at scale, you have to break out of local optimisations into system optimisations.  It will only come about by creating a framework for self-organisation and investing in the time to build team and build a learning culture. 

Agile Leadership and learning by doing

One of the groups I am working with is adopting Dean Leffingwell’s Scaled Agile Framework – better known by them as the Agile Release Train.  For various reasons (not the least being that I’m not as compelling as Dean), they’re employing a gradual transition rather than an “all-in and no turning back quick-start”.

The group began by establishing program and portfolio backlogs and the kanban systems to support them as a process layer superimposed over the existing agile teams and their backlogs.  Once the initial dust settled, a virtual team was formed from the senior leadership group to plan and prepare for the first 2-day PSI Planning session.   During the first visioning workshop, a futurespective was used to create the plan.  It began with the following question

“What will it look like at the start of the first day when we walk into the room with over a hundred team members and stakeholders and how do we ensure success?” 

 From there, it moved back a week at a time as the topics of lead times, logistics, invitations, communications, funding and so forth were covered.   A “PSI Planning” backlog was created in Rally, cards went up on a kanban wall and the group was set to roll with 4 2-week sprints before the train left the station.

At the end of the first sprint, velocity was 0.  Most planned stories were unstarted, and nothing was finished.  What emerged, of course, was that all involved were busy managers with a “day job” and the time just didn’t exist in the day to make this happen as well.  So, a new 1 week “Sprint 0” was agreed where the only goal was for every member of the team to find things they could stop doing and/or delegate to make some capacity available.  Conveniently, I spent that week in the States getting lots of fresh tips and tricks from Dean in his certification class. 

Sprint 0 was reasonably successful, and the team recommenced a revised sprint 1.  I’d come back armed with lots of new insights from Dean, and the team had agreed there would be a scaled down internal-only “PSI Zero” planning which brought the goal down to something less scary and easier to grasp whilst raising the urgency.

Sprint 1 just concluded, and it’s fair to say the journey is still very convoluted and the velocity was still near zero in “accepted stories”.  But the reason I sat down to write this tonight is the retrospective that happened this afternoon.  One of our most creative scrum masters turned “What worked/What didn’t” into “Freaking Awesome/Shambolic Malaise”, and the insights were fascinating – following are a few that stood out.

Freaking Awesome

• Established a shared vision
• Common purpose across organisational teams
• It's become "our Release Train" rather than Dean's
• We've sharpened the focus, we know what "really has to happen" and we're not worrying about the rest because we know it will change as we learn
• Short term targets, adjusting the plan pragmatically and being able to let go as circumstances change
• Creating a common kanban wall
• We're learning from safe failure

Shambolic Malaise

• Poorly defined stories
• Lack of agreed acceptance criteria
• Stories were too big
• Too many different interpretations of what stories were meant to be
• Too many priorities
• Who was the product owner?

Key Action

Immediately introduce “program unity” time to bring the whole program together for a brief visioning session to kick off each sprint planning morning.

So why write all this, it’s all old hat?

When we teach Agile, we teach the reasons for visualising WIP, writing good stories, running short sprints, running retrospectives, and all those other good Agile things.  And we know that it’s not until people go back into their teams and start using the tools that they’ll really start learning.  It's also commonly held that it’ll usually take 2-3 sprints before it all starts to come together.

But we take the senior and middle managers, and we usually give them abbreviated training courses with a simulated experience.   Then we send them back into the office saying “lead Agile” but they never get the time using the tools to really “learn by doing”. 

This afternoon’s group have by and large been in senior leadership positions on an Agile delivery program for a year.  The retrospective and re-planning that accompanied it convinced me they’ve learnt more about applying Agile and continuous improvement from 3 sprints as a part-time virtual team than in the entire preceding year.

A seasoned program manager, the team leader came up to me later and said “I’ve crossed the line.  Not that I was necessarily a cynic before, but I really understand how this stuff is meant to be applied now and I believe”.

The challenge it leaves me with is this:

“How do I start by giving the leadership group a taste of ‘life on a learning team’ next time instead of waiting months?”  

PS Retrospective sanctity was not harmed by this post, the team concerned loved the writeup and were keen to share their journey :)