Wednesday, 5 November 2014

Context Matters in SAFe


At Agile Australia this year I took some time out to talk with +Craig Smith+Tony Ponton and +Renee Troughton from The Agile Revolution about the Scaled Agile Framework (SAFe) and Impact Mapping.

You can read a summary of the discussion and listen to the podcast here: Context Matters in SAFe with Em Campbell-Pretty





Thursday, 30 October 2014

Is it SAFe to Scrum?

While I was hanging out on the West Coast of the U.S. earlier this month, I decided to take +Mike Cohn's Certified ScrumMaster (CSM) class. I have been using Scrum for a number of years, however my early agile education was from a more generic agile fundamentals angle and for no apparent reason I had never bothered to take a CSM class. When the opportunity to take Mike's class happened to match my travel schedule, it was too good an opportunity to pass up. I really enjoyed the two-day class, and, if you ever get the opportunity to learn Scrum from Mike, you should jump at it.

So what did I learn? Firstly, I learnt that I already knew a lot about Scrum. While I suspected this was the case, it was still nice to know it for sure. Secondly, after two days of talking Scrum, I am now completely convinced that Scaled Agile Framework (SAFe) is congruent with Scrum.

I had the opportunity to ask Mike about SAFe. Having read his blog post on LAFABLE, I didn't expect his views to be positive. Mike indicated that he felt SAFe was for enterprises that didn't really want to be agile. He highlighted SAFe practice of a two day planning event involving hundreds of people as particularly disconcerting. I can understand this. I think it is very hard to get your head around the Release Planning event until you have witnessed one. Concerns about this event are often raised in my Leading SAFe classes. My advice to students is always the same - get yourself invited to a Release Planning event. See it for yourself, then decide if you think it is valuable. (A student who recently took this advice, was blown away by the experience and echoed my view that you have to see it to believe it.)

Anyway, back to Scrum and SAFe. Clearly there are some differences. Scrum is silent on development practices. SAFe advocates leveraging XP. Scrum doesn't specify longer term planning be done on a cadence, although release planning appears to be a commonly accepted practice. However, on the whole, Scrum as it is outlined in SAFe seems to be the same Scrum one can learn in a CSM class. Both have a ScrumMaster, Product Owner and a development team. Both have daily scrums, sprint planning, sprint goals, sprint reviews and retrospectives.

Wednesday, 24 September 2014

The ART of the All-Hands Release Planning Meeting

“100 people in a planning meeting sounds like a contradiction in terms.”  Not exactly the supportive sentiment I was hoping to get from my parents. It was the weekend before the big event and I was trying to explain what we were attempting to my parents over dinner. Having freshly returned from +Jean Tabaka's Scaling Agile Collaboration Workshop at +RallyON, I was VERY focused on planning for the big day. Jean had said you should allow 2 hours of preparation for every hour of workshop and up to 5 times this for large planning meetings. Did she mean me personally as the facilitator or everyone involved? Had we done enough? Had I done enough? All was about to be revealed.

It was not the best start to the day as I rocked up 15 minutes late to my 7am pre meeting with the Release Train Engineer (RTE) to find her still working on slides for the morning session. (Not that I could judge, as I quickly dropped a handful of planning instruction slides into the back of the presentation.) Last minute changes were still arriving by text message from the CIO, including a change to the run order. “No!” said a loud voice in my head. The day hasn’t even started and my run sheet is already redundant.  Well, I guess that could be seen as a slight overreaction, but I was 0-2 at this point and I was starting to get concerned.

Thursday, 21 August 2014

Passing the Baton: The Role of Leadership in Sustainable Agile Transformations

Five years ago, before I had ever heard of an Agile Release Train, I was given a copy of Jim Collins’ book Good to Great by my line manager. Over the years I have read and re-read this book and it continues to be one of my favourites. I even recommended it to the EDW Book Club where we spent a number of hours dissecting the findings and considering how they might be applicable to launching an Agile Release Train.

Good to Great is the result of five years of research aimed at understanding the defining characteristics of “companies that made the leap from good results to great results”.  Jim Collins and his team identified seven concepts that were present in all the companies that had made the leap from good-to-great. One of the most compelling messages I took away from my first reading of this book was the concept of “Level 5 Leadership”.  That is, leaders who display the following behavioural patterns:
  • Setting up Successors for Success
  • A Compelling Modesty
  • Unwavering Resolve...To Do What Must Be Done
  • The Window and the Mirror
Good to Great concepts

Friday, 18 July 2014

Scaling Agile, Culture, Teams, and Tribes

Link to my interview with Noel Wurst of +Skytap about my upcoming Agile 2014 sessions:


Monday, 23 June 2014

Pitching the Pixar Pitch

In February 2013, +Gojko Adzic hosted a one day workshop with a number of Agile thought leaders who are passionate about “Building the Right Thing”, including +Mary Poppendieck+Jeff Patton+Karl Scotland, and +Chris Matts among others. After some discussion on the various techniques they had been using such as Impact Mapping, Story Mapping, Lean Canvas, Real Options and Feature Injection, the group decided to focus on the commonalities with a view to creating a shared message:


The idea that great results happen when people know why they are doing their work really resonated with me. I’m sure this is a large part of why I fell in love with impact mapping.  In Impact Mapping, “why” (aka the goal) is at the centre. Getting the goal right is the key to a good impact map, but it is not always easy. 

Tuesday, 27 May 2014

Time to catch another train...

The time I spent leading the EDW team at Telstra has been the most incredible experience of my life. I have worked with some truly extraordinary people who made every day fun (even when it was very challenging!) I will be forever grateful for the opportunity I was given, as a business person, to lead and grow a struggling delivery team into a world class Agile Release Train.

As the General Manager responsible for the launch of the EDW Release Train, I was invited to speak at conferences across Australia and the United States. I got to share our story and inspire others to take the next step in their agile journey. During my travels I met so many of my agile heroes, I felt like I was leading a truly charmed existence. Finding agile and the agile community has changed the course of my career.

So after almost ten years at Telstra, over three years of agile and two years of SAFe, I said goodbye to my beloved EDW Release Train. On my last day my fabulous team blew me away with their heartfelt goodbye. It was Unity Day with a farewell to Em and +Wayne twist. Things started out in their usual way with “shout outs” and a ridiculous game called Torpedo, the point of which was to “have fun”.


Monday, 5 May 2014

Release Train Engineer - Batman or the Wonder Twins?

A couple of months back I wrote about launching my first Agile Release Train and some of our specific challenges with creating the right organisational structure. In particular I pointed out that : “For us the Release Train Engineer (RTE) role as articulated in SAFe has never really emerged. “ Instead, the responsibilities spelt out in the SAFe Big Picture as belonging to the RTE have in our case ended up being split across the leads of the three service teams - Pipeline Services, Development Services and Deployment Services.

Initially we had envisaged the Development Services Manager would be the RTE, however it quickly became apparent that it would take a superhuman effort for one individual to take on all the responsibilities of an RTE, especially when your Agile Release Train is swimming against the tide in an organization that has yet to embrace Lean|Agile mindsets. Enter the role of the Pipeline Services lead, +Megan Anderson and her team.  These superheros stand shoulder to shoulder defending the front line every day. The pressure from the broader organisation to compromise on our values is constant and unrelenting. But they stand firm and protect the development teams.

Monday, 28 April 2014

You Want to Train Everyone? Don’t Be Ridiculous!

Those familiar with SAFe may have noticed that we did not launch our Agile Release Train with a Quick Start. One reason for this is that we started our train before the first SPC class was held and flying +Dean Leffingwell to Melbourne to launch our train exceeded my non existent consulting budget!  However, it was not just SAFe training that we overlooked. We provided no class room training at all to the newly formed train. We assumed most of the team had been on Agile Fundamentals and used Unity Day as an opportunity for learning through play.

Almost a full year after we launched our first Agile Release Train, I travelled to Boulder, Colorado for the SPC certification class being led by +Dean Leffingwell.  I returned from Boulder full of energy and bright ideas on how to improve our Release Train and towards the top of the list was running SAFe training for everyone. However, if last year had a theme it was deliver, deliver, deliver and taking time out to train people never really seemed practical. As the year came to a close and we started scheduling the Christmas break, my leadership team decided I should run SAFe Scrum XP the first two days of the new year. I squirmed. It had been 10 years since I had delivered any formal training. Did I still have what it takes? What if I made a fool of myself? While I was panicking, the team was planning and the next thing I knew it was a done deal!

Wednesday, 2 April 2014

Being an Agile Team of Agile Leaders

When introducing agile, it is easy for management to expect their teams to change while not truly understanding what this change means on a day to day practical level. Leaders runs the risk of confusing their understanding of the theory with a true appreciation of what it means to operate as an agile team. I often see this manifested in the traditional project plan, complete with a Gantt chart, that outlines how an organisation will transition to agile.

As part of establishing the EDW Release Train, our coach +Mark Richards encouraged my new leadership team to operate as an agile team. At first we mobilised around preparing for our first PSI planning event. We had a Kanban board with all the tasks that we needed to complete and daily stand ups, but we didn’t have the discipline to make the time to action the tasks! To this day +Mark loves to tell the story of our zero velocity first iteration! Personally, it never ceases to amaze me how difficult it is to get agile leaders to operate as an agile team. It would seem we were much better at instructing others on how to be agile than we were at walking the talk!



Tuesday, 25 March 2014

Communication Cadence - The Heartbeat of Scaled Agile

In my life as a business sponsor of software development programs I spent innumerable hours in program meetings - project status meetings, RAID meetings, Steering Committees, Governance meetings, “Come to Jesus meetings”, you name it. When I was appointed to my first role on the delivery side of the fence, I thought running these meetings was essential. After all every IT General Manager I had ever worked with followed this practice.

Everybody hated these meetings, particularly the three hour Monday morning Program Review. 25 people and a 100 page status report made for a long start to the week. The morning’s discussion would revolve around the true status of the Watermelon Projects (green on the outside and red on the inside) and the lack of action taken from one week to the next on the seemingly endless list of actions. From the day I inherited this meeting, coach +Mark Richards was on at me about getting rid of it.

Wednesday, 5 March 2014

Launching an Agile Release Train While Standing in a Waterfall

Some days I wonder if someone has put the EDW Release Train on a list of "must see" tourist attractions in Melbourne. We have a least two tour groups a month come and visit us to see how we have gone about scaling agile using the Scaled Agile Framework (SAFe). Some visitors are from within our company, others are from other IT shops in Melbourne, interstate or even occasionally from the US. Many of our local visitors are at the beginning of their agile journey and they always ask "Where should we start?". The answer, of course, is start where you are; which is exactly what we did.

Our implementation of SAFe occurred shortly following an organisational restructure in which I had been appointed to lead a newly formed organisation that was the amalgamation of three interwoven groups: two Program Management functions and a Solution Design & Build team that supplied people to the programs. These groups were also augmented with an outsourced offshore build and test capability. This newly consolidated EDW delivery organisation operated under multiple SDLCs - ranging from agile to waterfall, depending on which group was executing the delivery effort. For the sake of everyone's sanity, my first order of business was to settle on a single SDLC.

Tuesday, 25 February 2014

How I Fell in Love With Impact Mapping...

12 months ago my team was engaged to provide a very rough estimate for a large new reporting and analytics program.  Over the next 5 months we cycled back and forth until eventually the sponsor decided to proceed and nominated a “business lead” to work with us. Excited by the problem, I quickly reached out and invited the nominee to visit our site, meet the development team and understand the work in progress.  From this meeting we established that the program had a number of senior stakeholders with competing priorities, so I offered to help facilitate a workshop with the stakeholders to clarify the scope and priorities.  The offer was accepted and the workshop was held a few weeks later.

I'm sure you can imagine my surprise when the workshop attendees turned out to be external consultants, rather than the actual senior business stakeholders we had expected.  Surprises aside, the consultants were credible enough proxies for us to feel we were making good progress cobbling together high level scope and priorities.  Good enough, in fact, that we moved roughly the top priority scope items forward into a discovery phase, enabling us to produce a long and expensive plan to deliver about half the scope!

As the proverb says every cloud has a silver lining. Our unappealing plan led to an invitation to present (“explain”) to the senior business stakeholders at the program governance meeting. The presentation sparked a lively conversation about timing, priorities and scope. The program lead, responsible for getting the business case approved and funding released, requested a “deep dive” to understand who had requested each feature and associated benefit. Empathising with him as I recalled harrowingly similar situations in my past life as a business sponsor, I offered to facilitate the “deep dive” he requested.

Wednesday, 12 February 2014

Can You Be SAFe Without PI Planning?

The concept of a PI (Program Increment), is generally considered the corner stone of cadence in SAFe. In simple terms, +Dean recommends that a PI consists of between 4 and 6 two week sprints including a IP sprint (Innovation & Planning.) and each PI commences with a two day "all hands" release planning event during which a high level delivery plan is produced for the PI. As readers of this blog would already be aware, when we launched our first release train, we did not have enough funded development work in the pipeline to justify a full blown release planning event, so we invented Unity Day.

Given we could not use the PSI cadence initially we adopted a rolling wave planning approach. Late last year demand started to exceed supply for the first time in the brief history of the EDW Release Train. Our first response was to add an additional team to our Release Train. When a couple of months later we found we were still feeling severely capacity constrained, the concept of implementing PI Planning as per textbook SAFe became a regular topic of conversation at our leadership team lean coffee.

Saturday, 8 February 2014

Scaling Agile Data Warehousing

Use this link to download a free copy of my article on Scaling Agile Data Warehousing from the January 2014 issue of the Cutter IT Journal.


Monday, 27 January 2014

Unity Day - Creating a One Team Culture

It recently occurred to me that I have yet to share the history and context of Unity Day, our often referenced iteration kick off event. Given the creation of Unity Day is actually one of the pivotal moments in the history of the EDW Release Train, it is time to close this gap.

For me our first Unity Day marked the beginning of our cultural transformation. The idea was the result of a retrospective with my extended leadership team. It was only weeks after we had decided to establish an Agile Release Train and we had been preparing for our first PI / Release Planning workshop. In SAFe a PI is a fixed duration "super-sprint" in the range of 60-120 days. Each PI commences with a two day "all hands" release planning event, with full participation from both the Agile Release Train and its business stakeholders. During this session a high level delivery plan is produced for the PI. In our case, we did not have a funded backlog large enough to support a even a cut down one day PI planning event. At the time there was minimal demand for development on the EDW and we were barely keeping the full train occupied from one ten day sprint to the next.

After a series of rather amusing side conversations with my direct reports, where they each pulled me aside to explain we did not have enough demand in the pipeline, it was clear we were going to have to find another way. At our next leadership team stand up, I shared what I had learnt via the side conversations and acknowledged that a full day PI / Release Planning workshop was not in our immediate future. We agreed to retrospect on our journey to date before defining the way forward.

While reflecting on the demise of our first PI planning day, the team felt strongly that the biggest missed opportunity was team Unity. Sadly, despite most of the 100 people on EDW Release Train team having worked together on various aspects of EDW over the past couple of years, we didn't all know each others names! The PI planning day was going to be the first time we would bring the whole team together and it was something we had been excited about. And so Unity Day was born!