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