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 PI 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.
While “Core Scrum” as articulated in the Scrum Guide doesn’t talk to scaling, Mike did provide some guidance on how to scale Scrum. This included a scrum of scrums, aligning sprint start and end dates, a shared product backlog , and scaling the product owner to include Product Line Owners and Chief Product Owners. All theses concepts are also included in SAFe, albeit in some cases with different names.
Accepting that there are some differences in terminology and that Scrum doesn't have a two-day release planning event, I left Mike's class bewildered at why so many members of the Scrum community are so opposed to SAFe. Perhaps it is the introduction of the portfolio level? It seems to me that the type of strategic planning enabled by the Portfolio level in SAFe in no way contradicts Scrum. I would simply observe that Scrum is focused on enabling software development teams and does not concern itself with how the organisation aligns its technology investments to business strategies and the consequential allocation of funds. I don't find this to be contradictory just different.
Perhaps my business lenses allows me to see things differently than those who grew up in IT. Whatever the reason, having now been through SAFe training with Dean Leffingwell and Scrum training with Mike Cohn, I just can’t see what all the fuss is about. After all, isn’t our highest priority “to satisfy the customer through early and continuous delivery of valuable software”?
“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, 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 7 am 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.
By 8 am, I was calm again. The room had been set up the afternoon before. The planning board, the feature kanban and the agenda were all up on the walls. The team tables were decorated with team avatars representing each of the newly formed teams. The RTE had chosen superhero groups as the theme for her Agile Release Train, and as is always the case with these things, the teams had taken a few liberties when choosing names - Los Pollos Hermanos, Fringe Division, The Matrix, Master Builders and the Justice League. Each table has a supply of Post-its, index cards, sharpies, blu tack and planning poker cards. As I added the final touch to each table (anti-stress scrum balls), the CIO entered and kicked a scrum ball the length of the room. Something tells me it is going to be a good day.
ART Planning Board
PI Planning Feature Kanban
As participants slowly begin to arrive, the CIO quite rightly points out that some music is in order, then quickly whips out his iPhone and plays “Everything is Awesome”. I play DJ for a little while, whilst the last-minute audiovisual adjustments are being made.
The CIO opens the event at 9:05 with an inspirational speech that sets the perfect tone for the day, reminding everyone that this first agile release train forms a part of the broader ITS strategy to: “Maximise Values, Minimise Time, Eliminate Waste and Engage the Team.” He was followed by the RTE, who set the context for the workshop and introduced the teams. I was next with a quick run-through of the agenda before introducing the business sponsor, who set the business context and shared her vision for the future of her line of business.
From there, the morning continued with a series of short, sharp feature overviews provided by the business. Then, it was time for the architecture briefing. Unfortunately, the architect in question was at home sick, so using the magic of Google Hangouts, he presented from home. This turned out to be a pointed reminder of the value of in-person communication. The poor architect, on the other end of a computer screen, was unable to read the room, and the audience was trapped listening to a 45-minute version of what was supposed to be a 15-minute architecture briefing. (At least we learnt from the experience, as banning remote presentations was one of the first decisions made when the team started preparing for the PI 2 planning event.)
With the room a little flat, we were keen to inject some energy before the teams started planning. My colleague had spent the morning offstage and had cooked up a plan - a whole of train version of the ballpoint game. While the idea has potential, I think it might need a little more refinement! However, fun, energy and much laughter had been injected back into the room, and we broke for lunch.
After lunch, it was time for the teams to get planning. It was not long before I realised just how underprepared we were. From what I hear, this is true of almost all trains at their first PI Planning event. It wouldn’t be until well after the two days had been and gone that I would get some perspective and remember that it was me, all those months ago, that suggested we needed to stop trying to predict how the train would work and instead learn by doing. As a learning experience for an Agile Release Train, the 2-day PI Planning event is invaluable.
Don’t confuse our under-preparedness with a lack of preparation. In the eight weeks leading up to the event, there was an extraordinary amount of preparation activity, in parallel with delivering on in-flight project commitments. Squads (aka agile teams) were formed, features were cut, backlogs were created and prioritised, everyone was trained, briefings were prepared, and the logistics for a two-day, 100-person workshop were put in place. In many ways, everything that could reasonably be done had been done.
In the first afternoon of planning, so many missed opportunities became obvious. Some of them had been foreseen, but not actioned; others took us more by surprise. In no particular order it became clear that it would have been preferable for:
the teams to have had time to form as teams before the event
both team members and business stakeholders to have had more input into the process of breaking down epics into features
the Scrum Masters to have had more facilitation tools in their kit bag
On the other hand, the energy was incredible. Like what I experienced with the PI-lite approach we took with the EDW Release Train, but somehow different. I suspect this difference was the inclusion of the business folk. Watching the teams collaborate with their business stakeholders, many of them for the first time, was magical. The draft plan walkthrough at the end of day one showed that all teams had made good progress, but we were probably slightly behind where we wanted to be. It was time for the teams to head home and the leadership team to reflect on the day and make some priority calls to inform the next day's activity.
After a short health break, the leadership team, made up of both business and IT folks, reconvened for the Management Review & Problem Solving session. The first order of business was to get everyone’s thoughts out into the open. It was time for Post-its, sharpies and silent writing. The topic was “What did we learn?” and the response from the leadership team was overwhelmingly positive. The value of the collaborative conversations enabled by the day was obvious to everyone. As you would expect, there were also a number of items that needed to be actioned either the next day or over the coming days.
Big Visible Agenda
Management Review & Problem Solving
The final part of the management review was a conversation about feature priorities. The discussion was rich, and the willingness of the leadership team to make compromises was the stuff of true servant leadership. It was 8 pm, we had ourselves a set of positive messages to deliver to the team, and it was time to head home for a well-earned rest.
Day two kicked off with a little more “Everything is Awesome” and a few words of encouragement from the CIO before getting on with the planning effort. We took a bit of a gamble and gave the teams all morning to plan, not just the 2 hours suggested by the standard SAFe agenda. Five teams new to agile, trying to plan a 12-week PI in two days was quite an ask, and we wanted to give them every chance to succeed.
By the final plan review, most teams had a pretty solid plan for at least the first few iterations. It was time to R.O.A.M. the program-level risks. As the teams had read through their plans, they had surfaced risks that were outside their control. The RTE had been collecting these, and it was time to get them all Resolved, Owned, Accepted or Mitigated. Talk about a leadership opportunity! As I read out each item, I watched the CIO, the business sponsor and other senior leaders take ownership of various risks on behalf of the teams. It was lean leadership in action. With the risks ROAMed, I asked the CIO and business sponsor to accept the risk profile for the PI, and we captured a photo of the two of them in front of the risk board.
Next up, it was time for the moment of truth - a walkthrough of the program board followed by the confidence vote. Having played back the integrated plan to the group, I asked each team, in turn, to provide a confidence vote for the plan, using a “Fist of Five” where:
5 = Very high confidence; will happen 4 = High confidence; should happen 3 = Good confidence; the team should be able to meet the objectives 2 = Little confidence; probably will not happen 1 = No confidence; will not happen
The first three teams all responded with a nice mix of 3s, 4s and 5s. By this point, I was feeling pretty good about the outcome. The fourth team thought it would be funny to all vote 1 and see my reaction. I am reliably informed I went white as a sheet, before they quickly changed their votes to 5s, much to my relief. The fifth team also returned votes in the 3 to 5 range, providing a full sweep. Now for the finishing touch - would the executives accept the plan? A photo of the CIO and business sponsor shaking hands in front of the program board sealed the deal.
To wrap up the event, in a true agile fashion, it was time to retrospect. Each table was asked to do a simple star-style retrospective - stop/start/do more/do less/keep. Again, the feedback was overwhelmingly positive, with improvement suggestions focussing on “stop playing the awesome song” and “time box the architects”. For me, a highlight was watching the business people go and sit with the teams they had been working with rather than returning to the business group tables at the back of the room. That’s when I knew we had started a change journey that had the potential to go beyond the delivery of software, to change the organisational culture.
A little taste of the PI planning event
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
I was reminded of this recently, after leaving the EDW Release Train. In the months since I said goodbye, I began to wonder if I had done enough to set my successor up for success. Was I just another “agile evangelist” leaving a raft of unsustainable ideas in my wake? While I had complete faith in the team I left behind, I was concerned that the organisation would close in on them. After all, the transformation that took place with the EDW team was for the most part unique and not replicated across the corporation.
I had some reason to be hopeful. Over the years I had observed that the “bright spot” that is the EDW Release Train inspire change in other parts of the organisation. For example, some groups across the broader department had started their own Unity Day, the practice of measuring team happiness had been adopted by various teams across the organisation and more Agile Release Trains had been launched in other lines of business. But it wasn’t enough.
As mentioned in previous blog posts the success of the train had led to an increase in demand for delivery. In the days following the announcement that I was leaving, the offshore vendor that used to be responsible for EDW delivery was re-engaged to assist with the increased demand. I don’t know what lead to that decision, but I have to wonder if the only thing that had been preventing such a decision being made before I resigned was the belief that I would fight it tooth and nail - which was a completely fair assumption! As it turned out, I was not the only champion of the EDW Release Train and the outsourcing decision was reversed almost as quickly as it was made.
I have not had the opportunity to visit the EDW Release Train since my tear filled last day with them at the end of April. The grape vine tells me they are continuing to grow and evolve. A new carriage (team) is being added to the train. The tradition of Unity Hour is ongoing, with new quirky ideas like the recent “Mr Strategic Delivery” competition. The project described in my blog on Impact Mapping has gone on to deliver on its promise. The progress towards flow, mentioned in my blog on SAFe without PSI planning, has resulted in the Epic and Feature kanbans being merged to help with visualising flow. And the tradition of growing leaders from within continues as existing team members step up into the leadership roles that have been vacated.
The research team behind Good to Great found that every sustained transformation was led by a leader that whose ambition was "for the greatness of the work and the company" and actively set their successors up for success. Whether you are a coach, manager, scrum master or team member, you all play a role in ensuring the improvements you champion are sustainable. There is nothing more disheartening for the teams you work with, than to be led to a better place only to find it is an illusion. In the case of the EDW Release Train the baton has been passed smoothly, the team continues to accelerate, and I look forward to following their story as they break new frontiers
In February 2013, Gojko Adzic hosted a one-day workshop with several Agile thought leaders 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 to create a shared message:
The idea that great results happen when people know why they are doing their work 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.
I was recently working with a group that was struggling to articulate the goal for their project. I felt going into the impact mapping workshop, I would need a powerful technique to get the stakeholders thinking about what they were hoping to achieve through the program of work they were about to launch. As I dug into my agile toolkit, I remembered a conversation I had recently had with a colleague. He had introduced the Pixar Pitch as an alternative to the Elevator Pitch in some of his Agile training courses, and he had been super excited about it and how rich the outputs were. Maybe I could use this approach too…
I messaged my colleague and tested the concept. “I’m thinking about using a Pixar Pitch to help clarify the vision before starting the impact map. I think it might make a good lead into the discussion about why / the goal. Thoughts?” His response: “It’s great value, but takes bravery. Be ready for the sniggers before the aha’s.” Sniggers?! What did he mean? I was about to facilitate a workshop with some very senior business people at my very new agile consulting gig! Then I decided I should practice what I preach. As Agile coaches, we push our clients out of their comfort zones daily. It was time for me to push myself out there.
At this juncture, I should probably pause and explain what a Pixar Pitch is. In his latest book, To Sell is Human, Daniel Pink outlines “six promising successors to the elevator pitch”, including the Pixar Pitch:
Once upon a time there was ___. Every day, ___. One day ___. Because of that, ___. Because of that, ___. Until finally ___.
The Pixar Pitch, as outlined by Daniel Pink, is an adaptation of Kenn Adams’ Story Spine:
Now, back to my Impact Mapping workshop. After setting the scene for the workshop Jean Tabaka style, I decided to rip the bandaid off and dive in feet first to the Pixar Pitch exercise. I explained that a Pixar Pitch was an alternative to the Elevator Pitch, and it was the formula used by Pixar to pitch their films. I then revealed to the group the Finding Nemo Pixar Pitch I had written up before the session and hidden behind a piece of butcher paper:
I’m unsure if anyone sniggered, but I saw a few amused smiles. Pushing through the potential embarrassment, I quickly asked the group to divide into two teams of five with an equal split of business and technology stakeholders. Then gave them 15 minutes to write their Pixar pitch.
I knew from my colleague that I should expect great results, but I never imagined how amazing the pitch written by the executive sponsor's team would be. With permission, I have shared it below:
Once upon a time... There was a very long queue at the University's student contact centre with lots of new students (some of whom were frustrated by the queue). Every day... Data management services received a Sisyphean pile of papers (which were received after much work logging papers + batched + dispatched....) and occasional papers would get lost, or data would be entered incorrectly. Sometimes huge boxes of papers dropped down from Singapore and other far away places. One day... The students rebelled! They demanded access to manage their enrolment online themselves - make this problem go away. We want access to Blackboard immediately, not after a few weeks! They also want credit to appear immediately, and wanted to know their timetable earlier so they could organise their work hours, child care and other parts of their life. ("Study is only part of my life!") Because of that... The University's numbers dropped, staff were leaving! "Yikes!" said the University! We better listen to the students and fix their problem once and for all. Because of that... The Academic Registrar and her team developed a roadmap, got funding and IT were engaged. And a spell was cast and made all of the enrolments process invisible - got the info they wanted, never had to go to the University's student contact centre, never heard of the Academic Registrar's team. Enrolment ongoing throughout their life cycle was seamless - they didn't need to be here physically to manage it. No more queues! Until finally... The only time they went to the University's student contact centre was to engage with them for high value services (and meeting other students who might become their future significant other).
While the business was not quite convinced of the value of the Pixar Pitch, they conceded it was good fun. From a technology standpoint, the delivery team loved it. It gave them the “why” they needed to get excited about the project. And from a facilitation standpoint, it leads us to the goal. And ever since then, I have used a Pixar Pitch to kick off my Impact Mapping workshops.
Please note: No clownfish were harmed in the creation of this blog post.
Presentation at Agile Australia 2014.
Are you lost in a sea of business requirements? Are you struggling to articulate the business value of your technology project? Do your user stories lack context? Is there a lack of alignment between your delivery teams and business stakeholders? If you answered yes to one or more of these questions, then this session is for you!
Impact Mapping is a facilitation technique that brings technologists and senior stakeholders together meaningfully to explore options. It exposes assumptions and helps shape a path from “We want everything” to “We want to make these impacts in this order”, avoiding the trap of solutions looking for problems.
This session provides an overview of how to create an Impact Map, shares some real-world examples of how impact mapping has helped support the delivery of software products and even provides an opportunity for you to start using the tool!
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 +Waynetwist. Things started out in their usual way with “shout outs” and a ridiculous game called Torpedo, the point of which was to “have fun”.
Apparently the joke was on me as we went from fun to more fun, depending on your perspective. Kanban Chanman (+David Chan) sat me and +Waynedown for one of his traditional fireside chats. I unfortunately was completely speechless. Every time I went to answer one of Kanban’s well rehearsed questions all I could do was try to fight back the tears.
What did you think would not work but then did?
What has been your proudest moment?
Of all the customer experiences you’ve had what has been the most ‘crazy’?
Of your own experiences what has been the most ‘fun’?
Any last words for the train. Where should we be looking next? How might we improve?
According to the team that was only one side of the story. Over the prior few days they had been capturing their version of events in a +Battino and +Innes feature film entitled “Sporadic Improvement”. This 15 minute mockumentary opened with footage of +Luke imitating Wayne, then moved on to +Megan imitating me! It was full of “in jokes” that filled the team with laughter at the film’s premier showing that morning. There were also some incredibly touching moments as people shared their memories of working with me and +Wayne. The film closed with the most heart wrenching farewell speech from my 2IC +Megan Anderson.
Note: This video contains a lot of in jokes and plenty of explicit language.
Not suitable for viewing by minors!
By this time it was becoming very clear to me that my team is clearly a sadistic bunch. With tears still streaming down my face, my boss of five years, +Julian Hebden was invited to take the floor and had his turn at making me cry.
The morning closed with a goodbye gift, wrapped in an A0 Scaled Agile Framework big picture. A polo shirt with “The Original and The Best EDW Release Train “ printed on the front and everyone’s avatar’s on the back. Again I was speechless.
During the course of the remainder of the day various members of the team dropped by as I packed up my office.
“Thank you for making me agile.”
“Thank you for changing what it is like to work here.”
“Thank you allowing me to be part of the journey.”
“Thank you for the opportunity.”
Thank you for the experience”
“Good Luck, Em.”
“Go and change the world!”
So it was with a very heavy heart that I said goodbye to my amazing team. Their willingness to “drink the Kool-Aid” and come on this wild ride to launch Australia’s first SAFe Agile Release Train is something I will never be able to thank them enough for. It was an absolute pleasure to work with such a dedicated, driven and fun group of people. I can only hope that I am so lucky as to get an opportunity to work with such a great team again one day.
Goodbye card from the EDW Release Train
After two years at the helm, I leave the EDW Release Train in the very capable hands of my friend and long term lieutenant +Megan Anderson. Thank you Megan for supporting me and the team through what has been a very emotional time. Look after my team and keep fighting the good fight.
As for me, its onwards and upwards. My “Adventures in Scaling Agile” will continue. I have joined forces with my good friend and ex-coach +Mark Richards to form an Agile Coaching and Training consultancy, Context Matters, with the aim of helping large Enterprises with Agile Transformations and hopefully change a few more lives for the better.
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 spelled 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 Release Train Engineer. 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 organisation that has yet to embrace a Lean-Agile mindset. Enter the role of the Pipeline Services lead and her team. These superheroes 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.
Every day, it is that same conversation:
“No, we will not pressure the development team to reduce the estimate. You need to trust the team. If you do not have enough funding consider de-prioritsing some features.”
“No, the team will not work every weekend between now and Christmas. We only work at a sustainable pace. If your project is critical let’s collaborate with other stakeholders to have your features prioritised appropriately.”
“No, we will not throw more “resources” at the problem. Nine women cannot make a baby in one month!”
“No, you cannot “buy” teams. If your Epic is important to the company you will need to have it prioritised accordingly.”
“Yes, the plan has changed. We have learnt more about your needs.”
“Yes, the plan has changed. We have been unable to get time with the business feature owner. If this is important to you, you will make the right people available to support the team.”
(Just writing this list has reinforced the importance of training everyone - including your business stakeholders and the other technology groups you work with.)
If you are fighting on the front line every day, it is difficult to find the time and energy to be the facilitator of ART ceremonies and the champion of continuous improvement. I was trading notes on this conundrum recently with a colleague, and we reached the following conclusion:
In large enterprises where agile is starting out and the people on your first agile release trains are in the minority and traditional mindsets are the norm, splitting the RTE role into two may well be a better place to start for the sanity of the RTE and those who are dependent on him or her.
In other words, launching an Agile Release Train while standing in a waterfall presents two key challenges: (1) how to grow a high-performing team of teams and (2) how to protect the train and/or grow the enterprise. If these two challenges fall to just one person, even a superhero is going to need to compromise the amount of their attention given to one or the other. As Dean Leffingwell says, “Nothing beats an agile team”. When the teams are new to agile, the organisation needs to make a serious investment in nurturing those teams to become unbeatable. In an Agile Release Train of 50 - 125 people, this is a big job. On the other hand, in an organisation new to agile, the first agile release train runs the risk of being run off the tracks by the traditional mindsets of the governing bodies and dependent technology teams.
Of course, like every compromise, this scenario creates its own challenge as each side of the two-headed RTE struggles to recognise the value of the other. Inevitably, while Pipeline Services struggled heroically to buffer the train from organisational pressures, there was always leakage. Their success, in some ways, contributed to the tension, as the development teams were largely unaware of just how much they were being shielded. While the development teams were striving to empathise with their customers, their ability to build empathy for what many still perceived as a “project management layer” was often neglected. In creating a responsibility split of “grow the teams” and “protect the teams”, there will inevitably be tension between the two mandates when it comes to separating the crisis of today from the promise of tomorrow.
Given my overarching context, my mission was to assist my leadership team in navigating this tension. Recently, I found some valuable insights with respect to the cause of some of the tension while reading Adam Grant’s Give and Take. In a chapter dedicated to exploring “Collaboration and the Dynamics of Giving and Taking Credit”, he introduces the concept of responsibility bias from the work of Canadian psychologists Michael Ross and Fiore Sicoly. Responsibility bias occurs when we exaggerate our own contribution relative to others. While in some instances, this can be ego-driven, it is also a natural byproduct of information discrepancy. “We have more access to information about our own contribution than the contributions of others. We see all of our own efforts, but we only witness a subset of our partners’ efforts. When we think about who deserves the credit, we have more knowledge of our own contributions.”
Occasionally, I facilitated a retrospective and empathy mapping workshop with the leadership team as tensions had reached “boiling point”. Looking back, I suspect it would have been helpful to have a continuous cadence of retrospectives. That said, they have started to solve the problem for themselves in recent months. Recently, the Pipeline Services leader commented on the insights that have emerged from encouraging her Project Portfolio Managers to spend time sitting out with the teams. Having the development teams absorb osmotically the number of times the Pipeline team says “no” to the machine has been very powerful.
In closing, I still think we made the right call in splitting the RTE role, and I would do it again. However next time I will be conscious that “responsibility bias is a major source of failed collaborations” and put the right rituals in place to help these highly effective independent superheroes become an even more effective pair of Wonder Twins.
