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 :)

Senior Management in the Fishbowl

One of the courses I regularly facilitate is “Agile Leadership”, a one day course for senior management and executives which aims to impart both fundamental understanding of practices and a sense of servant leadership at senior levels.  It is my favourite course and by far the most challenging.  I like it because it’s light on structure and gives the freedom to make it unique for each group, but that freedom also makes it a little like riding a wild horse (or a herd of them in some cases).

I’m always on the lookout for new facilitation ideas, but find that with some of the best you read the book and think “wow, that sounds great but could I really do it with a room full of senior management”.  One of the best things about good conferences is getting the chance to see other people put what you’ve read about into practice, and I find Jean Tabaka in particular fills me with inspiration every time I come into contact with her.

At the recent RallyOn conference, Jean facilitated a “fishbowl” to kick off the final day open space.    If you haven’t seen one, the purpose is to create intimate, deep and involving conversation with a large group of people.  5-6 chairs are place in a circle in the middle of the group and all but one of the chairs are seeded with people to start the conversation.  If you’re in the audience and want to join the conversation, you walk up and sit in the empty chair and someone else has to “vote themselves off the island” and vacate their chair.

When it started, there were 200 or so in the audience, and the 5 starting voices in the chairs were all serious thoughtleaders (Jean Tabaka, Christopher Avery, George Kembel, John Kembel and Ryan Martens).  I looked at it and thought “who on earth is going to take that empty chair knowing they have to displace people of that calibre”.  Jean seeded a conversation starter and sure enough, for 3-4 minutes it was just a bouncing conversation in the middle – but then the first brave voice joined it.  From then on it was almost surreal.  The conversation flowed, it was intimate, people joined and left every few minutes and the audience hung on every word.

So, of course I came home and started thinking about where I could use it.  In the leadership course, the afternoon is structured as a series of small group discussions.  An “agile dilemma” such as disempowered product owners is displayed, and the groups have 15 minutes or so to discuss how they would respond as senior leaders followed by a “debrief with a servant leadership topup”.  Sometimes the discussions are superb, and sometimes they’re far from it.  In some cases one of the tables just has the wrong dynamic to explore it fruitfully and sits silently after 5 minutes while other tables continue, in others people struggle with being asked to explore soft-skills when they’re expecting a recipe on how to manage agile programs. 

Normally, groups are small but I knew at the time I had a couple of large groups coming through and had been quite concerned over how to ensure a good afternoon of breakout discussions.  So I decided to try the fishbowl, and I loved it.  In the first course, it generated the richest conversation I had yet seen.  The focus in the room was intense as people concentrated on hearing the discussion, the discussion itself was intimate and engaged, the dynamic was great as people moved in and out of the conversation and I stood at the back of the room in awe.  What I loved most was that I had to add very little agile influence in the summary for each topic, the groups had drawn it out themselves.

So the second time I tried it, I decided I’d cheated by adding a debrief myself.  I made myself a participant just like everyone else in the class.  If I wanted to add something,  I moved into a chair.  When I was in the chair,  I added by questioning rather than by answering and exited as fast as I could.  In essence, I spent most of the afternoon where my only contribution as a facilitator rather than as part of the group was to pick the next scenario to discuss.  The result was so rich I was blown away. 

I spent the next few days trying to think through why it was so powerful.  Some answers were obvious.  Those with the most to contribute were able to speak to the whole room rather than just their table, but also to do it without “public speaking” or “presenting” – just naturally in conversation.  But the aspect I feel was most powerful was that the message did not come from “the agile guy at the front of the room”, it came from within.  Insights that would have been difficult to accept from me were far easier to accept from their own management group. 

All I did was provide a place, a time and an atmosphere for the right conversation to happen.  Thanks Jean for yet another inspiration.

Introduction

I’d like to thank Johanna Rothmann for providing the final nudge I needed to move from “thinking about blogging” to “starting a blog”.  We were at the final morning of the recent Rally On conference, and she had come over to offer some encouraging words after watching me somewhat nervously speak about servant leadership for executives on the preceding afternoon.   Much of the conversation revolved around why I didn’t blog or tweet, and 10 minutes later I’d run out of excuses.

Some background perspective

After spending my formative agile years in the traditional “small, innovative team” side of Agile, a period back in the large waterfall program world ignited my passion for understanding how to apply agile at scale, and since my return to agile it has been the focus of my endeavours. 

Between research, sharing with other agilistas and learning from my students and clients I have come to the belief that it boils down to two things:

• Establishing agile culture at the executive and middle management levels
• Pragmatic and situational adaptation of agile practices to find the right balance between the formality and process required at scale and the innovation enabled by self-organisation.

Through this blog, my hope is to share insights gleaned from the application of this belief and put a little back into a community that has taught me so much over the 12 years of my Agile journey.