tag:blogger.com,1999:blog-70303978146075118682024-03-19T02:24:05.351-07:00The ART of SAFeApplying Lean and Agile techniques at scale to bring about effective, sustainable improvement in Culture, Execution and Business Results Mark Richardshttp://www.blogger.com/profile/12477809828045353101noreply@blogger.comBlogger59125tag:blogger.com,1999:blog-7030397814607511868.post-56927693544602953502023-10-12T22:57:00.002-07:002023-10-12T23:47:07.454-07:00Introducing our new collaboration - Shaping Agility<p>In 2015, Martin Burns had a vision. A passionate agilist and early adopter of and advocate for SAFe, he felt strongly that the community needed a way to come together and collaborate to shape the evolution of the framework. With the help of his wife <a href="http://linkedin.com/in/lucyburns" target="_blank">Lucy</a> and the support of <a href="https://scaledagile.com/" target="_blank">Scaled Agile Inc</a>, he activated this by creating and hosting the first <a href="https://www.safeleadershipretreat.com/" target="_blank">SAFe Leadership Retreat</a> in Crieff, Scotland. He was seeking “<i>An event that brings experienced leaders together to build the community and creatively take SAFe forward</i>.” </p><p>Given the general application of <a href="https://scaledagileframework.com/" target="_blank">SAFe</a> in large enterprise and the prevailing ‘partner consultancy’ based model, creating an environment where both consultants and practitioners came together to transcend boundaries and share was no mean feat. But Martin’s seemingly boundless energy made it a reality. Forty people gathered for 2 days of unconference and amazing collaboration and friendship building.</p><table align="center" cellpadding="0" cellspacing="0" class="tr-caption-container" style="margin-left: auto; margin-right: auto;"><tbody><tr><td style="text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgOaOiELV_y705TfzlRXSgkdROEHPatNdw1xu3iVPQxPce1EEObDN6u-V3Xj2YNNA-DvcgaxjiKOoWkAPiJoUCK7fiyBg1CkXJHYgG8Uyi2yHvRpRiwvzD2rPID7JuvxOLUEfsl6qyGHstDZVZ1T_cBeHH-vmVGnjwNO63fCvtbn1NaF10semx6VR2KBCSU/s2937/crieff.png" style="margin-left: auto; margin-right: auto;"><img border="0" data-original-height="2076" data-original-width="2937" height="452" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgOaOiELV_y705TfzlRXSgkdROEHPatNdw1xu3iVPQxPce1EEObDN6u-V3Xj2YNNA-DvcgaxjiKOoWkAPiJoUCK7fiyBg1CkXJHYgG8Uyi2yHvRpRiwvzD2rPID7JuvxOLUEfsl6qyGHstDZVZ1T_cBeHH-vmVGnjwNO63fCvtbn1NaF10semx6VR2KBCSU/w640-h452/crieff.png" width="640" /></a></td></tr><tr><td class="tr-caption" style="text-align: center;">Photos courtesy of <a href="http://linkedin.com/in/philgardiner" target="_blank">Phil Gardiner</a>, unofficial Retreat photographer</td></tr></tbody></table><p>We regathered in Banff, Canada in 2016 and then returned to Scotland for 3 days in Edinburgh in 2017. The conversations were rich, the friendships deepened, and the sense of community continued to grow. The influence on the framework was also tangible – <a href="https://scaledagileframework.com/essential-safe" target="_blank">Essential SAFe</a> being a great example of something created in a breakout session entailing an intense discussion about how much you could remove from SAFe without breaking it. </p><p>Sadly, in 2019 Martin passed away and the world lost an amazing human being. Although the SAFe Leadership Retreat disappeared without Martin’s energy, the community he’d inspired lived on. At every <a href="https://safesummit.com/" target="_blank">SAFE Summit</a>, SPCT or Fellows gathering you’d find clusters of people who’d formed community at a Leadership Retreat gathered, sharing in deep conversation, reminiscing on the retreats, lamenting their absence in our lives and talking about how bring it back to life. </p><p>The first post-COVID <a href="https://scaledagile.com/blog/2022-safe-summit-recap/" target="_blank">SAFe Summit in Denver</a> last year was no exception. One of the retreat buddies I reconnected with was <a href="http://linkedin.com/in/wolfgang-brandhuber-a30300ab" target="_blank">Wolfgang Brandhuber</a>. He had been doing a lot of work on <a href="https://scaledagileframework.com/large-solution/" target="_blank">Large Solution</a> and wanted to share some of his thinking about a structure somewhere between an ART and a Team called a Solution Area. We found a spare flipchart, and an hour later we’d figured out this was almost identical to what I called an ‘Agile Release Tram’ and agreed that we should leverage the fact COVID had taught us virtual collaboration and keep the discussion going once we got home. We started weekly calls, and it was fun. We were back to the types of conversations we used to have time for at the Retreat, but without the 24 hours on a plane! <a href="http://linkedin.com/in/saahilpanikar" target="_blank">Saahil Panikar</a> started to join us, and this series culminated in the events I shared in my ‘<a href="http://www.agilenotanarchy.com/2023/05/emerging-from-covid-seclusion.html" target="_blank">Emerging from Seclusion</a>’ post in May. </p><p>As I wrote the ‘seclusion post’ I was sitting in Mexico on a writing retreat. What I didn’t mention was that I was spending a couple of hours a day chatting to ‘fellow <a href="https://scaledagileframework.com/contributors/" target="_blank">Fellow</a>’ <a href="http://linkedin.com/in/ericwilleke" target="_blank">Eric Willeke</a>. I’d been so energized by my collaboration with Wolfgang and Saahil that somewhere on the train between Munich and Prague I’d dreamed up the idea of deliberately creating a collaboration community. I didn’t know what it looked like, but I did know it involved a Discord community server and lots of collaboration and creation. Serendipitously, Eric had reached a point in his ’year of not working’ where he was starting to think about what a return looked like. We’d both shared the Leadership Retreat experience, both enjoyed engaging with others who could stretch our thinking and both felt very values-driven in our creative intent. Further, if there was one person in the world I knew could challenge my thinking on pretty much anything in the world of Enterprise Agility it was Eric!</p><p>What quickly emerged was the idea of creating a community which provided a shared platform to enable collaboration between thought leaders. The backdrop to our conversation was an amazing book Eric had pointed me to: Jacqueline Novogratz’s ‘<a href="https://amzn.asia/d/hMP6VkT" target="_blank">Manifesto for a Moral Revolution</a>’. We knew the community needed to be purpose-driven, even if our purpose paled in comparison to “<i>changing the way the world tackles poverty</i>”. Eric’s purpose of ‘Creating a stress-free world of work in pursuit of a kinder, more abundant world of humans’ aligned incredibly strongly with my ‘Create a world where people are excited to come to work and fulfilled by the outcomes they’re a part of creating’, so we had a foundation for the journey ahead.</p><p>In true agile fashion, we embarked on an iterative process. We wanted a ‘collaboration rather than a company’, so we began by testing our ability to generate routine collaboration and generative discussion via our Discord community. Novogratz suggests that “<i>if you are a change agent, then you are by definition a nonconformist</i>”. Eric and I both love to ‘live on the edge’ teasing at the boundaries of ‘SAFe Canon’ and our other founding members Wolfgang and Saahil were no strangers to living on the edge either so when it came to picking a name Eric’s ownership of the shapingagility.com domain made life easy – we became ‘<a href="http://shapingagility.com" target="_blank">Shaping Agility</a>’. </p><p>Next came livestreaming. We didn’t want to share polished content, we wanted to share the process of creation. In '<a href="https://amzn.asia/d/i93FhoU" target="_blank">The 5th Discipline</a>', Peter Senge suggests that the discipline of working with mental models “<i>includes the ability to carry on ‘learningful’ conversations that balance enquiry and advocacy, where people expose their own thinking effectively and make that thinking open to the influence of others</i>”. This was what we wanted, not just between those of us in the inner community but between us and the broader community of change agents and practitioners. </p><p>We started with a <a href="https://www.twitch.tv/shapingagility" target="_blank">Shaping Agility channel</a> on Twitch.tv, the dominant streaming platform in the world of e-sports. This was brand new territory for me, and I’ll confess I learnt more from my two daughters (who both stream their gaming) than my more traditional forms of research. We’d been holding a regular Saturday session with whoever could make it and we started streaming them. My daughter <a href="http://linkedin.com/in/samantha-richards-1b957b232" target="_blank">Sammi</a> is an audio engineer by day and helped us figure out the technology in between giggling at my ineptitude and after a couple of sessions where she was our only audience and we struggled our way through managing both the stream and the conversation it felt like it was starting to gel. </p><p>Next came persisting the broadcasts. Balancing the Australian/European/US timezones meant our conversations happened at very weird times and we needed a way for people to ‘catch what they’d missed in the middle of the night’. So, we created the <a href="https://www.youtube.com/@ShapingAgility" target="_blank">Shaping Agility Youtube channel</a> and after a few video editing tutorials I started editing out the glaring flaws in our streams and posting them. We shared them with a few friends and colleagues for feedback and our community started to grow.</p><p>Two things were happening for me over this time. Firstly, I was loving the learning journey of bringing this community to life and our learning cycles on making it work. We could feel a high performing team emerging even though we all ran our own companies with our own separate offerings. We looked forward to our conversations, we laughed, we debated, we learnt, we improved. </p><p>Secondly, the creative energy was flowing back into my personal work. I’d created a one-day experiential course back in 2015 called ‘Experiencing SAFe’ and despite many good intentions had created nothing bigger than a workshop since. All of a sudden I was in the thick of creating and delivering a ‘Lean Portfolio Management bootcamp’. I’d be in a discussion with Eric and he’d reference a book I hadn’t read and I’d race off to read and fill the gap. The process that began in May is now most definitely running at full steam. Meanwhile Eric has launched the pilot of his cohort-based mentoring program for leading change – <a href="https://www.unleashingscale.com/leading-change" target="_blank">Unleashing Scale</a>.</p><p>As I write this, we’re shaping the next iteration. We're playing with ideas for extra shows for the stream. Wolfgang is preparing to launch a 64-part series on Large Solution, while <a href="http://linkedin.com/in/michael-casey-abp" target="_blank">Michael Casey</a> and <a href="http://linkedin.com/in/davideva1" target="_blank">Dave Eva</a> joined Eric, Wolfgang and I this morning for the <a href="https://www.twitch.tv/videos/1949332982" target="_blank">first episode of a weekly bookclub</a> study series on The 5th Discipline.</p><p>The decision to go a little more public also prompted a big backlog refinement session. Among other things, we're going to need a website rather than a redirect to twitch and an approach to engaging more broadly with those who have feedback on the ideas we stream. We had a bare minimum of stuff we needed to articulate more clearly before this post went live, assembled it on a Miro and decided that the lightest weight version of it was <a href="https://www.youtube.com/watch?v=yb7Ncru3RyI" target="_blank">a stream to share</a> (and a learning lesson on audio levels for Eric's first time being the host).</p><p>I hope you'll enjoy joining us on the learning journey as much as we're enjoying learning together.</p><table align="center" cellpadding="0" cellspacing="0" class="tr-caption-container" style="margin-left: auto; margin-right: auto;"><tbody><tr><td style="text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEi5C1IaYeXaa3UtqrWlGftPoardeiz8ep9VGBm2U2T9bzwrKZZcDWh71URoSyrH7vLQoxFWGiWqH16PlfSOqVwsmz0tDqFxBZxXB1omeygBS1fRhzoZ1xHoDEc2WlXD4p0ix9Gg8V002DX-dfL7Gb5PIVBnkKiIe48ZlLhvPN16IHhbtKBAi4qWY05Z9hyphenhyphen8/s2048/IMG_0007.jpeg" style="margin-left: auto; margin-right: auto;"><img border="0" data-original-height="2048" data-original-width="1820" height="640" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEi5C1IaYeXaa3UtqrWlGftPoardeiz8ep9VGBm2U2T9bzwrKZZcDWh71URoSyrH7vLQoxFWGiWqH16PlfSOqVwsmz0tDqFxBZxXB1omeygBS1fRhzoZ1xHoDEc2WlXD4p0ix9Gg8V002DX-dfL7Gb5PIVBnkKiIe48ZlLhvPN16IHhbtKBAi4qWY05Z9hyphenhyphen8/w568-h640/IMG_0007.jpeg" width="568" /></a></td></tr><tr><td class="tr-caption" style="text-align: center;">In memory of Martin Burns, sorely missed and never forgotten!</td></tr></tbody></table><br /><p><br /></p>Mark Richardshttp://www.blogger.com/profile/12477809828045353101noreply@blogger.com1tag:blogger.com,1999:blog-7030397814607511868.post-12146249150853551432023-05-26T12:17:00.001-07:002023-05-26T12:17:41.580-07:00Release Train Engineers (RTEs) - The Power or the Passion<h2 style="text-align: left;">Foreword</h2><p>The Release Train Engineer (RTE) is a (arguably THE) pivotal role in the success of a SAFe implementation, so over the course of my book research in 2019 I interviewed RTEs at every organization I visited. Whilst this was a great way to learn the “true state and current pain points of the implementation at the coal-face” it had the side-effect of challenging my beliefs about the characteristics of a great RTE. As I processed my notes from the study trip I formed the idea of writing a post on identifying and selecting great RTEs but it went onto my writing backlog to collect dust during COVID.</p><p>Last week in Prague I bumped into one of the truly inspiring RTEs from my study and as we caught up on her journey since then I shared with her the concept of this post and she challenged me – “why didn’t you write it”. Em Sperring – this one’s for you!</p><p><span></span></p><a name='more'></a><h2 style="text-align: left;">Introduction</h2><p></p><p>When I first began coaching SAFe back in 2011, I interpreted the RTE role as the “ART-level Scrum Master” so naturally looked for strong, experienced Scrum Masters. This gave great momentum building the “high performing self-organizing team of self-organizing teams”, but in the typically turbulent early days of an ART’s life they often struggled to manage the politics and external pressure on the ART. Building their awareness and skillset to navigate the pressure and constraints from the enterprise was a long journey and one many of them had no interest in. </p><p>Often, technology middle management or Program Managers were perceived as the true “Delivery leads” and remained outside the “agile system of work” – relegating the RTE’s to glorified admin assistants and event organisers but excluding them from the significant decisions. I eventually pivoted and started looking for middle management or program management candidates on the basis it was easier to coach them on the “lean/agile parts of the role” as they worked “in the agile system of work” than to grow the Scrum Masters in the “enterprise system of work” parts of the role. Being brutally honest, many had the same lack of interest in their agile gaps as the Scrum Masters had in their strategic gaps but on balance it felt like the better approach and I stuck to it with a reasonable success rate.</p><p>The focus of my study was “organizations I hadn’t coached”, and I found most RTE’s I interviewed came from the “Scrum Master/Coach” background, were in pain, and tended to suffer the same relegation consequences I’d observed in my early SAFe life. However, a number of them were incredibly passionate and relentless in finding every opportunity no matter how small to nurture their teams and grow their ART – and I realised I’d adopted a blanket stance rather than looking at case-by-case trade-offs. </p><span><!--more--></span><h2 style="text-align: left;">Approaching the identification and selection of an RTE</h2><p>I characterised the two flavours of RTE as “<b>Power</b>” (traditional background) and “<b>Passion</b>” (agile background) and developed a decision-making framework to aid in the identification and selection of Release Train Engineers. It is based on the superlative “WRAP” framework presented in “Decisive: How to make better choices in life and work” by Chip and Dan Heath:</p><p></p><ul style="text-align: left;"><li><b><span style="font-size: medium;">W</span></b>iden your options</li><li><b><span style="font-size: medium;">R</span></b>eality Test your assumptions</li><li><b><span style="font-size: medium;">A</span></b>ttain Some Distance</li><li><b><span style="font-size: medium;">P</span></b>repare to be Wrong</li></ul><p></p><span><!--more--></span><h3 style="text-align: left;">“Widen our Options” when identifying candidates</h3><p>Be open to candidates from both a Power and a Passion background</p><p></p><ul style="text-align: left;"><li><b>Power</b> - Typically a Program Manager or Technology Middle Management</li><li><b>Passion</b> – Typically an experienced Scrum Master or Agile Coach turned practitioner</li></ul><p></p><h3 style="text-align: left;">“Reality Test our Assumptions” during the selection process. </h3><p>It’s useful to have a framework of assumptions to test, so in the two images below you’ll find my assumption framework:</p><div class="separator" style="clear: both; text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhV-CkQKQOpUaJJ2kjSD8UXQiCtwP-ueWVjSacMOhrgMWGHvNMN1H4JmiHnzMwqWQALUuocm_FBoJ9cw5HxCddYZQ1_TNqjP7P6Tf7GxqZxaIMplHDGFGkFyNaoB6dI019xU_xLtCtMshJEwTEgjoAyzkqHcwpFD80ZgWDAS0h0WJBjnX9rQIM1KxldDA/s2102/Screen%20Shot%202023-05-26%20at%201.01.38%20pm.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" data-original-height="1486" data-original-width="2102" height="453" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhV-CkQKQOpUaJJ2kjSD8UXQiCtwP-ueWVjSacMOhrgMWGHvNMN1H4JmiHnzMwqWQALUuocm_FBoJ9cw5HxCddYZQ1_TNqjP7P6Tf7GxqZxaIMplHDGFGkFyNaoB6dI019xU_xLtCtMshJEwTEgjoAyzkqHcwpFD80ZgWDAS0h0WJBjnX9rQIM1KxldDA/w640-h453/Screen%20Shot%202023-05-26%20at%201.01.38%20pm.png" title="Power Assumptions" width="640" /></a></div><div class="separator" style="clear: both; text-align: center;"><br /></div><div class="separator" style="clear: both; text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhRGgUHqtJR51i3jdOcWQyeo5xaAPt3Vx3MOJKRWMXH9s_FCSo_3ieEIT_VNMK2624qj-ofvJGuec8OIP6kf3udxOpkUWG_-QtWhnqEEXvopUsXOLCEI0rE-nkhh4ZG6Q2eBW-KU5GLP5la9phWvoraSPj0khpXmMH7LpQChvHcdNtdPwfltBHeJy8DWg/s2090/Screen%20Shot%202023-05-26%20at%201.15.06%20pm.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" data-original-height="1482" data-original-width="2090" height="454" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhRGgUHqtJR51i3jdOcWQyeo5xaAPt3Vx3MOJKRWMXH9s_FCSo_3ieEIT_VNMK2624qj-ofvJGuec8OIP6kf3udxOpkUWG_-QtWhnqEEXvopUsXOLCEI0rE-nkhh4ZG6Q2eBW-KU5GLP5la9phWvoraSPj0khpXmMH7LpQChvHcdNtdPwfltBHeJy8DWg/w640-h454/Screen%20Shot%202023-05-26%20at%201.15.06%20pm.png" title="Passion Assumptions" width="640" /></a></div><br /><div class="separator" style="clear: both; text-align: center;"><br /></div><p style="text-align: left;"><b>Candidates are people, not stereotypes</b>. The evaluation process should be looking to either validate or invalidate the assumption framework, in particular testing willingness/interest in compensating for gaps. Shout-outs to Simon Douglas, Antonio Gomes and Catherine Haugh as 3 standout examples of assumption busters in the Power category and Chris Innes as an assumption buster in the Passion category.</p><h3 style="text-align: left;">“Attain some Distance” when shortlisting</h3><p>Step back and evaluate the candidate and trade-offs holistically. Consider the mitigations you will have available:</p><p></p><ul style="text-align: left;"><li>Sample <b>Power-gap Mitigations</b></li><ul><li>Is your organization’s business agility sufficiently matured to lessen the need?</li><li>Will there be a deeply engaged senior leader supporting the ART and the RTE?</li><li>To what extent does the LACE have the toolkit to assist the candidate in rapidly filling the gaps?</li></ul><li>Sample <b>Passion-gap Mitigations</b></li><ul><li>Do you have a strong, experienced cadre of Scrum Masters for the ART?</li><li>What level/style of coaching support will be available to the RTE?</li><li>To what extent have the LACE and the People team established role expectations and supporting infrastructure around the passion aspects of the role?</li></ul><li>Sample <b>General Mitigations</b></li><ul><li>What is the demonstrated and validated thirst to learn of the candidate</li></ul></ul><p></p><h3 style="text-align: left;">“Prepare to be wrong” when selecting</h3><p>Establish “tripwires” – conditions to be monitored which might cause you to re-evaluate your decision and likely actions to be taken if the tripwire is triggered. </p><span><!--more--></span><h3 style="text-align: left;">Finally, be prepared to step completely out of the box</h3><p>I have observed two innovative patterns that solve very elegantly for the challenge:</p><p>The first was shared with me by a very seasoned, passionate RTE from Fedex at the alpha-test of the RTE course years ago in Boulder. I have forever wished I had taken a note of his name and maintained the connection. Their LACE had a program where they identified their “wunderkind RTE’s” and used them to establish ARTs. The wunderkind would go “2-up” in the role with the new RTE, pairing with them to launch the ART, make it through the first PI and mentor the early journey, then step away to find their next ART.</p><p>The second was the solution we employed with our very first ART back in 2011 (and I’ve leveraged a few times since). We ran with a pair of RTE’s – one outward focused from a power background and one inward focused from a passion background. Megan Anderson (now technology COO at ANZ Bank) was our outward RTE from a Program and Change Management background and Wayne Palmer (now CDO at Tecknuovo) was our inward RTE from a ScrumMaster background. Megan marched the halls of the waterfall enterprise in which we were attempting to be agile and kept our fledgling ART alive politically while Wayne relentlessly focused on visual management, flow, collaboration and continuous improvement of the teams. The two had some glorious conflicts on a weekly and sometimes daily basis but we had now SAFe Fellow Em Campbell Pretty as their line manager to keep the peace and maintain the balance between passion and pragmatism and saw amazing results.</p><p>The one key piece of advice I can give if you employ the pair solution is to ensure the outward and inward RTE’s are peers from a seniority perspective. You need both voices in any significant decision to maintain balance.</p><p><br /></p><p><br /></p><p><br /></p>Mark Richardshttp://www.blogger.com/profile/12477809828045353101noreply@blogger.com2tag:blogger.com,1999:blog-7030397814607511868.post-37362881919643212112023-05-23T13:14:00.005-07:002023-05-23T13:14:49.755-07:00Emerging from COVID Seclusion: Revitalizing the Blog and New Endeavors<h4 style="text-align: left;"> Introduction: </h4><p style="text-align: left;">Over the past few months, I have gradually emerged from my COVID-induced seclusion. I embarked on collaborations, traveled to teach in Germany and speak at the SAFe Summit in Prague, visited clients and old friends in London, and currently find myself in Punta de Mita, Mexico, where I'm writing this blog post. As I reconnect with people, I am often asked about the whereabouts of my book and my dormant blog. With a lot of writing ahead of me in the coming weeks, I've decided to dust off the blog and explain the reasons behind its silence.</p><div class="separator" style="clear: both; text-align: center;"><p style="clear: both; text-align: left;">In 2019 I took a semi-sabbatical year to dedicate myself to the book I had been contemplating for years. Its working title was "The ART of SAFe: The Secret to Creating and Sustaining High Performing Agile Release Trains." I believed that I had already written more than half of the book through my blog posts, but it needed refreshing, organization into a coherent narrative, and some content gaps filled. Consequently, I decided to pause the blog temporarily to focus my energy on the book and determine the distinction between content for the blog and content for the book.</p><h4 style="clear: both; text-align: left;">A Shift in Perspective: </h4><p style="clear: both; text-align: left;">However, I made the mistake of undertaking a study trip. I sought to validate the beliefs I had formed while working with my own clients by studying other large SAFe implementations. Through the generous help of friends and contacts, I had the opportunity to observe their worlds and exchange some free consulting for a glimpse "under the covers" of their organizations.</p><p style="clear: both; text-align: left;">While my initial belief was that the true purpose of the Agile Release Train (ART) was to activate and equip ART-level leaders and stakeholders in creating an ecosystem for their teams to thrive and align with high-performing agile teams, my perspective changed. I realised that ARTs were not the primary challenge – truth be told they’re the “recipe part of SAFe”. Instead, it became evident that what we truly needed was an organization-wide ecosystem capable of fostering an environment (or as Dr. Deming would say, a "System of Work") where ARTs could flourish.</p><p style="clear: both; text-align: left;">Everywhere I looked, I encountered organizations that had been on their SAFe journey for a couple of years, most with over 20 ARTs in place. However, they were hampered by complexity, politics, difficulties in organizing around value, and challenges in evolving their funding, assurance, and other enterprise-level processes.</p><h4 style="clear: both; text-align: left;">Shifting Focus and the "Wrong Book": </h4><p style="clear: both; text-align: left;">Consequently, I decided not to write the "wrong book." In truth, my former customer and later colleague, Em Campbell Pretty, published an excellent book on that topic ("The ART of Avoiding a Train Wreck") while I was conducting my research. </p><p style="clear: both; text-align: left;">I went back to the drawing board, realizing that this was a much more complex problem. Although I had written a small amount on the subject and gained numerous insights that were yet to be synthesized, I needed an overarching strategy. While grappling with this challenge, I taught Luke Hohmann's Agile Product Management course, which led to an "aha" moment. I realized that I could approach an organization's path to enterprise agility through the lens of Moore's Product Management theory. Organizations either struggled to cross the chasm due to gaps in their agile approach's "whole product" hindering adoption by the pragmatists in the Early Majority, or they successfully crossed the chasm based on executive mandate only to become stuck in the Early Majority Tornado due to the same gaps.</p><h4 style="clear: both; text-align: left;">The Metaphor and Writing Struggles: </h4><p style="clear: both; text-align: left;">I had found a metaphor for the book, but there was a tiny problem. I had always written about "things I'd applied enough times to synthesize into patterns," and I had never coached a SAFe implementation using a Product Management metaphor. Additionally, the advent of COVID and lockdowns had a profound personal impact on me. My creative energy waned, and my focus shifted toward simply surviving the circumstances and supporting my clients. </p><p style="clear: both; text-align: left;">Despite the challenges, I continued experimenting and learning, engaging in user testing. I quickly realized that while the Product Management metaphor provided a strong framework for my thinking and resonated with other thought leaders like Eric Willeke, it was not suitable for my clients. This should have been obvious, considering that effective Product Management is a key challenge for most enterprises.</p><h4 style="clear: both; text-align: left;">Regaining Momentum: </h4><p style="clear: both; text-align: left;">Fast forward to 2023, and I have conducted enough experiments to have a wealth of new material ready to write about. Along the way, I also gathered a substantial amount of ART-level content that belongs in the blog rather than the book. However, I had yet to regain my writing mojo, despite theoretically living in an "after-COVID" world.</p><p style="clear: both; text-align: left;">Then, luck came in the form of Wolfgang Brandhuber. We spent 2 hours in a hallway at the 2022 Denver SAFe Summit delving into how his theories on "Large Solution" intersected with my concepts of "Agile Release Trams" and "Loosely Coupled ARTs." Wolfgang reached out to me in early February, suggesting that we continue our conversation, which led to weekly calls and idea-sharing sessions. Soon after, Saahil Panikar joined our collaboration, and our weekly two-hour sessions became the highlight of my week. We began exploring the possibility of merging our work and creating a two-day course to teach in Germany, just before the Prague SAFe Summit.</p><p style="clear: both; text-align: left;">My creativity started flowing again out of necessity, as I needed to synthesize concepts in order to teach them. Simultaneously, I worked with the incredible Rebecca Davis to prepare my talk on leveraging the power of change managers in pursuit of the flow of value for the Prague Summit.</p><h4 style="clear: both; text-align: left;">Looking Ahead:</h4><p style="clear: both; text-align: left;">I’m writing and creating again and loving it. And the lessons COVID forced me to learn about virtual collaboration are bearing fruit as we start to extend the conversation around creative collaboration in the community. You can expect to see a few things from me in the rest of 2023:</p><p style="clear: both; text-align: left;"></p><ul style="text-align: left;"><li>Quite a few blog posts</li><li>Some very different stuff as our “creative collaboration community” takes shape</li><li>Material Progress on the book (finally)</li></ul><p></p><div style="text-align: left;"><br /></div></div>Mark Richardshttp://www.blogger.com/profile/12477809828045353101noreply@blogger.com1tag:blogger.com,1999:blog-7030397814607511868.post-20195465801831752352019-07-25T06:01:00.000-07:002019-07-25T06:01:08.899-07:00My visit to the birthplace of LeanAs I write, I’m sitting on the Shinkansen Bullet train from Kyoto to Tokyo, my head full of insight and inspiration from a week spent ticking a big item off my bucket list – a lean study tour of Japan. It was wonderful to share this experience with my entire leadership team, and I cannot recommend it highly enough to anyone who is or aspires to be a Lean|Agile change agent. My hope in the following article is to share enough about the experience to inspire you to make the pilgrimage, and just a couple of the many ways in which it has challenged and changed me.<br />
<br />
After a great deal of Googling, we elected to join a tour run by <a href="http://shinkamanagement.com/" target="_blank">Shinka Management</a>, an Australian company who specialises in assisting the exchange of knowledge of Lean and TPS between Japan and the rest of the world both through hosting Japanese visits and delivering consulting and training services abroad. <br />
<br />
Our week began in Tokyo on Sunday afternoon, where we were delighted to discover we were the only Australian members of the tour group of 20 and meet our core hosts Paul, Eri and Dave. After some introductions, we were taken through a detailed look at the week ahead and treated to an introduction to Japanese business etiquette before heading off to continue the conversation over dinner (the trip includes all meals, travel and accommodation). <br />
<br />
Monday morning began with a series of trains and buses efficiently moving us towards our first destination in Gifu prefecture and accompanied by highlights of the pervasiveness of visual management in Japan demonstrated in the public transport system. The learning then began in earnest at Shinka’s training centre where we were introduced to Hattori Sensai, a 30-year Toyota Veteran who delivered the bulk of our classroom training for the week. <br />
<br />
Less than 5 minutes into the introduction I had my first new Toyota insight as we came to understand that Hattori Sensai was a “Jishuken” leader, one of a handful of TPS experts that moved from plant to plant within Toyota implementing rapid and concentrated kaizen improvements (humorously translated to us as “Kaizen ninja”). This was not a term I’d read in any Lean book, and as I came to understand their role I struggled to understand how we’d missed it. Those who demonstrate early aptitude for Kaizen are enrolled in the Jishuken development program, and then play a key role both as “those sent to solve the hardest problems” and also to act as “kaizen sharing agents” bridging the company boundaries within Toyota (My previous view of “Toyota as one company” was dismantled as I learnt they were actually many companies under one umbrella with distinct differences). Dave provided superb translation as Hattori Sensai shared numerous insights about the TPS way of thinking and his experience consulting with non-Japanese companies attempting to adopt lean. I very quickly discovered that the many “Lean books” I had read tended to talk about the author’s insights into “a part of Toyota at a given point in time”, and gaining understanding of cultural and historical context was critical particularly when it came to adaptation.<br />
<table align="center" cellpadding="0" cellspacing="0" class="tr-caption-container" style="margin-left: auto; margin-right: auto; text-align: center;"><tbody>
<tr><td style="text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEj7Bf9XNbOCjZS1WOMfUxDJyq_riHb11AJlTlw6GAGvoSL2rngMAGiqdJpUf2Gw8NYhmGyjvnnCR3M9L4SZCC8tJdeOJF0f-dUZ8l6acUWNfUfJD0a8pxBBFYX7Da6OaKqS8bLlQWpmvfYq/s1600/Hattori+and+Paul+at+the+Whiteboard.jpg" imageanchor="1" style="margin-left: auto; margin-right: auto;"><img border="0" data-original-height="301" data-original-width="451" height="266" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEj7Bf9XNbOCjZS1WOMfUxDJyq_riHb11AJlTlw6GAGvoSL2rngMAGiqdJpUf2Gw8NYhmGyjvnnCR3M9L4SZCC8tJdeOJF0f-dUZ8l6acUWNfUfJD0a8pxBBFYX7Da6OaKqS8bLlQWpmvfYq/s400/Hattori+and+Paul+at+the+Whiteboard.jpg" width="400" /></a></td></tr>
<tr><td class="tr-caption" style="text-align: center;">Hattori Sensai illustrating transport oriented supply chain optimisation</td></tr>
</tbody></table>
<div>
<div>
We then proceeded to our first factory visit for the tour – Gifu Auto Body which did final body assembly for the HiAce line and some larger vehicles. This was the plant where Hattori Sensai had spent the majority of his working life, and his intimate working knowledge enriched the insights immensely as well as providing numerous moments of humour as he “felt the pulse on the gemba” and collared people on the floor who had worked for him to give them a bit of stick over issues he was seeing. Here I had my second real insight into Toyota. I had a picture in my head of a factory that felt like a hugely automated laboratory. I came to understand that Toyota valued ingenuity over infrastructure investment, and the vast majority of their kaizen was about stretching what they had (<a href="https://www.cnbc.com/2018/04/13/elon-musk-admits-humans-are-sometimes-superior-to-robots.html" target="_blank">some advice they offered Elon Musk which he ignored and learnt the hard way</a>). We then returned for a little more training before concluding the day with more chat over dinner.</div>
<div>
<br /></div>
<div>
Tuesday was again a mix of classroom training and site visits. We visited <a href="http://www.isz.co.jp/en/company/group.html" target="_blank">Metal One Isuzu</a>, an incredibly impressive steel-processing plant. They run a model of “Factory as a showroom”. Salespeople invite prospective clients to the factory, then shut up and allow the factory itself and the operators (all of whom are trained in customer service) to inspire confidence. At this point, we were starting to understand how much “attention to every detail, no matter how minor” pervaded the way of working. There was a huge amount of stress on safety, and my favourite moment of the tour involved the “operator-designed and made” safety awareness experiences and the follow-up story from our host Paul. The factory uses different coloured helmets to indicate role on the floor (as visitors we were in light green). Each staff helmet has three small safety cross stickers on the side. As part of Isuzu’s safety culture, if a staff member observed a colleague violating a safety standard or taking an unsafe action they were required to talk to their colleague about it and remove a sticker from their helmet. The loss of all three stickers would result in the helmet being traded for a pink helmet and safety bib, which was to be worn for a period until the unsafe behaviour had stopped.</div>
</div>
<table align="center" cellpadding="0" cellspacing="0" class="tr-caption-container" style="margin-left: auto; margin-right: auto; text-align: center;"><tbody>
<tr><td style="text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhq1qRAqf_iu6jV5EDoOOFVnAfs1lAWMAs_Qi8H0jY0LheEqIjksmO1XRpuPbb0Z0jZpjBbTH5C4bnqY64sbX6gTS7okVStW2W1TPlUhR12NFfqvoOsvquFOc8NQgb_NshzLkDc37hHBhCv/s1600/Metal+One+Isuzu.jpg" imageanchor="1" style="margin-left: auto; margin-right: auto;"><img border="0" data-original-height="146" data-original-width="695" height="134" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhq1qRAqf_iu6jV5EDoOOFVnAfs1lAWMAs_Qi8H0jY0LheEqIjksmO1XRpuPbb0Z0jZpjBbTH5C4bnqY64sbX6gTS7okVStW2W1TPlUhR12NFfqvoOsvquFOc8NQgb_NshzLkDc37hHBhCv/s640/Metal+One+Isuzu.jpg" width="640" /></a></td></tr>
<tr><td class="tr-caption" style="text-align: center;">Visual Management Boards, the factory floor and the dreaded Pink Helmet at Metal One Isuzu</td></tr>
</tbody></table>
<div>
<br /></div>
<div>
Tuesday also gave us a session with another of Shinka’s ex-Toyota people, Hyoda Sensai (who had managed the Gifu Auto Body plant and had also served as a Jishuken leader). The session with him flew by, focusing on leadership and the role of management. At this point, “a constant sense of danger” at last became crystal clear for me. Hyoda Sensei stressed how easy it was to allow waste in the good times, which tended to result in crises during bad times. Balancing a water bottle on the edge of a table, he asked us to imagine that we were the bottle and the drop from the table to the floor was a cliff. We were then asked how hard we would fight to maintain our balance and find inventive ways to avoid the drop. After a moment he then moved the bottle back to the middle of the table and repeated the question. Of course, the urgency had disappeared. The moral of the story was that a key responsibility of management was to create challenging situations for their teams to maintain that constant sense of danger.</div>
<div>
<br /></div>
<table align="center" cellpadding="0" cellspacing="0" class="tr-caption-container" style="margin-left: auto; margin-right: auto; text-align: center;"><tbody>
<tr><td style="text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEihboUGJ5fPBbmIB7RJRT_JjMry4gqaIqTaYBRZ70UaCwXdpw_haCppj26YaJb1FzvvJpkS9t4l45dpeImgFqKBr2gnjFZInYgvtH84Mi3HSojhRXCHWBveafi7OZz9AkUBFDkM-laMqJhr/s1600/Hyoda+Sensai.jpg" imageanchor="1" style="margin-left: auto; margin-right: auto;"><img border="0" data-original-height="301" data-original-width="451" height="426" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEihboUGJ5fPBbmIB7RJRT_JjMry4gqaIqTaYBRZ70UaCwXdpw_haCppj26YaJb1FzvvJpkS9t4l45dpeImgFqKBr2gnjFZInYgvtH84Mi3HSojhRXCHWBveafi7OZz9AkUBFDkM-laMqJhr/s640/Hyoda+Sensai.jpg" width="640" /></a></td></tr>
<tr><td class="tr-caption" style="text-align: center;">Hyoda Sensai illustrates the "constant sense of danger"</td></tr>
</tbody></table>
<div>
Wednesday brought a visit to Suzaki Industries in the morning. As well as other clients, Suzaki is a tier 2/3 supplier to Toyota. Our connection to supply-chain thinking began with a view of a truckload of steel from Isuzu being unloaded, and proceeded to be led by Chairman Suzaki. His introductory speech contrasted the joy of working with Toyota as a pull-based customer to the challenges of his push-based customers before proceeding with a fascinating walk through the plant and incredible insights into their use of Kanban and endless kaizen-based ingenuity. We concluded the tour with an hour in a team-room where Mr Suzaki explained how when the bubble burst in Japan in the late 80’s his company was on the brink of disaster. Until then, the view in Japan had been that manufacturing demand would continue to grow endlessly and many companies had allowed themselves to “grow fat” and let waste creep in. He had massively overinvested in automation to support production expansion, and when demand shrank overnight due to a massive exchange rate shift he had a factory full of machinery that would never pay for itself. He described his “Rescue” by Toyota – not in the form of a financial bail-out, but through mentoring. They informed him they relied on him as a quality supplier and wanted to ensure he succeeded and proceeded to invite him for intensive mentoring at Gifu Auto Body (one of those mentors being Hyoda Sensai). Yet again the resounding message was “ingenuity over automation” as he described how much less automation was present in his factory today then 30 years ago.</div>
<div>
<br /></div>
<table align="center" cellpadding="0" cellspacing="0" class="tr-caption-container" style="margin-left: auto; margin-right: auto; text-align: center;"><tbody>
<tr><td style="text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEh9ANA6mIEXH7m2fANoEKKlB4WyBF9gM4-4VJPwOM47Asvzfu9uwJ8Cz-9v3yiMwjyjPP8O3cHlMCmo0NBTytM8eP02h4tK9ejXNNmjnpnni9J7eMe7djGmFXj59xNUGSYcaA0jJdsAUm21/s1600/Suzaki.jpg" imageanchor="1" style="margin-left: auto; margin-right: auto;"><img border="0" data-original-height="95" data-original-width="443" height="136" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEh9ANA6mIEXH7m2fANoEKKlB4WyBF9gM4-4VJPwOM47Asvzfu9uwJ8Cz-9v3yiMwjyjPP8O3cHlMCmo0NBTytM8eP02h4tK9ejXNNmjnpnni9J7eMe7djGmFXj59xNUGSYcaA0jJdsAUm21/s640/Suzaki.jpg" width="640" /></a></td></tr>
<tr><td class="tr-caption" style="text-align: center;">Chairman Suzaki explains production scheduling (left), kanban tickets (centre) and standard work definitions (right)</td></tr>
</tbody></table>
<div>
The afternoon provided an incredible simulation humorously led by Hattori Sensai to help us put the notion of standard work and kaizen problem-solving into practice, in particular highlighting the risk of attempting to improve before you understand the outcome you’re trying to achieve. By this stage, I’d come to another of my paradigm shifts in understanding. After years of believing that Kaizen was “about the 1%”, both of our sensai had stressed the belief among the Jishuken leaders that “you could always get at least 30% improvement in a kaizen initiative” (notwithstanding that this is usually achieved by adding up many 1%’ers).</div>
<div>
<br /></div>
<table align="center" cellpadding="0" cellspacing="0" class="tr-caption-container" style="margin-left: auto; margin-right: auto; text-align: center;"><tbody>
<tr><td style="text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgOmEZgCBoZVFYhpbr3KWrJKGK83olSEuT6F5-lMeLs4gDiut670CxCqmKSXUBScAit3xHB3lTUvC1yLzz42gICiCPynnTI2LoAsJem5th4WnNtvsWWeNbvjHUEb7mJ3mIdxI07vCKGe2Y-/s1600/Kaizen.jpg" imageanchor="1" style="margin-left: auto; margin-right: auto;"><img border="0" data-original-height="148" data-original-width="454" height="208" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgOmEZgCBoZVFYhpbr3KWrJKGK83olSEuT6F5-lMeLs4gDiut670CxCqmKSXUBScAit3xHB3lTUvC1yLzz42gICiCPynnTI2LoAsJem5th4WnNtvsWWeNbvjHUEb7mJ3mIdxI07vCKGe2Y-/s640/Kaizen.jpg" width="640" /></a></td></tr>
<tr><td class="tr-caption" style="text-align: center;">The Coactivation team experiences a rather different type of Kaizen</td></tr>
</tbody></table>
<div>
<!--[if gte mso 9]><xml>
<o:OfficeDocumentSettings>
<o:RelyOnVML/>
<o:AllowPNG/>
</o:OfficeDocumentSettings>
</xml><![endif]-->
<!--[if gte mso 9]><xml>
<w:WordDocument>
<w:View>Normal</w:View>
<w:Zoom>0</w:Zoom>
<w:TrackMoves/>
<w:TrackFormatting/>
<w:PunctuationKerning/>
<w:ValidateAgainstSchemas/>
<w:SaveIfXMLInvalid>false</w:SaveIfXMLInvalid>
<w:IgnoreMixedContent>false</w:IgnoreMixedContent>
<w:AlwaysShowPlaceholderText>false</w:AlwaysShowPlaceholderText>
<w:DoNotPromoteQF/>
<w:LidThemeOther>EN-AU</w:LidThemeOther>
<w:LidThemeAsian>X-NONE</w:LidThemeAsian>
<w:LidThemeComplexScript>X-NONE</w:LidThemeComplexScript>
<w:Compatibility>
<w:BreakWrappedTables/>
<w:SnapToGridInCell/>
<w:WrapTextWithPunct/>
<w:UseAsianBreakRules/>
<w:DontGrowAutofit/>
<w:SplitPgBreakAndParaMark/>
<w:EnableOpenTypeKerning/>
<w:DontFlipMirrorIndents/>
<w:OverrideTableStyleHps/>
</w:Compatibility>
<m:mathPr>
<m:mathFont m:val="Cambria Math"/>
<m:brkBin m:val="before"/>
<m:brkBinSub m:val="--"/>
<m:smallFrac m:val="off"/>
<m:dispDef/>
<m:lMargin m:val="0"/>
<m:rMargin m:val="0"/>
<m:defJc m:val="centerGroup"/>
<m:wrapIndent m:val="1440"/>
<m:intLim m:val="subSup"/>
<m:naryLim m:val="undOvr"/>
</m:mathPr></w:WordDocument>
</xml><![endif]--><!--[if gte mso 9]><xml>
<w:LatentStyles DefLockedState="false" DefUnhideWhenUsed="false"
DefSemiHidden="false" DefQFormat="false" DefPriority="99"
LatentStyleCount="376">
<w:LsdException Locked="false" Priority="0" QFormat="true" Name="Normal"/>
<w:LsdException Locked="false" Priority="9" QFormat="true" Name="heading 1"/>
<w:LsdException Locked="false" Priority="9" SemiHidden="true"
UnhideWhenUsed="true" QFormat="true" Name="heading 2"/>
<w:LsdException Locked="false" Priority="9" SemiHidden="true"
UnhideWhenUsed="true" QFormat="true" Name="heading 3"/>
<w:LsdException Locked="false" Priority="9" SemiHidden="true"
UnhideWhenUsed="true" QFormat="true" Name="heading 4"/>
<w:LsdException Locked="false" Priority="9" SemiHidden="true"
UnhideWhenUsed="true" QFormat="true" Name="heading 5"/>
<w:LsdException Locked="false" Priority="9" SemiHidden="true"
UnhideWhenUsed="true" QFormat="true" Name="heading 6"/>
<w:LsdException Locked="false" Priority="9" SemiHidden="true"
UnhideWhenUsed="true" QFormat="true" Name="heading 7"/>
<w:LsdException Locked="false" Priority="9" SemiHidden="true"
UnhideWhenUsed="true" QFormat="true" Name="heading 8"/>
<w:LsdException Locked="false" Priority="9" SemiHidden="true"
UnhideWhenUsed="true" QFormat="true" Name="heading 9"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="index 1"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="index 2"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="index 3"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="index 4"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="index 5"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="index 6"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="index 7"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="index 8"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="index 9"/>
<w:LsdException Locked="false" Priority="39" SemiHidden="true"
UnhideWhenUsed="true" Name="toc 1"/>
<w:LsdException Locked="false" Priority="39" SemiHidden="true"
UnhideWhenUsed="true" Name="toc 2"/>
<w:LsdException Locked="false" Priority="39" SemiHidden="true"
UnhideWhenUsed="true" Name="toc 3"/>
<w:LsdException Locked="false" Priority="39" SemiHidden="true"
UnhideWhenUsed="true" Name="toc 4"/>
<w:LsdException Locked="false" Priority="39" SemiHidden="true"
UnhideWhenUsed="true" Name="toc 5"/>
<w:LsdException Locked="false" Priority="39" SemiHidden="true"
UnhideWhenUsed="true" Name="toc 6"/>
<w:LsdException Locked="false" Priority="39" SemiHidden="true"
UnhideWhenUsed="true" Name="toc 7"/>
<w:LsdException Locked="false" Priority="39" SemiHidden="true"
UnhideWhenUsed="true" Name="toc 8"/>
<w:LsdException Locked="false" Priority="39" SemiHidden="true"
UnhideWhenUsed="true" Name="toc 9"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="Normal Indent"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="footnote text"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="annotation text"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="header"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="footer"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="index heading"/>
<w:LsdException Locked="false" Priority="35" SemiHidden="true"
UnhideWhenUsed="true" QFormat="true" Name="caption"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="table of figures"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="envelope address"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="envelope return"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="footnote reference"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="annotation reference"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="line number"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="page number"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="endnote reference"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="endnote text"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="table of authorities"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="macro"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="toa heading"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="List"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="List Bullet"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="List Number"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="List 2"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="List 3"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="List 4"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="List 5"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="List Bullet 2"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="List Bullet 3"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="List Bullet 4"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="List Bullet 5"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="List Number 2"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="List Number 3"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="List Number 4"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="List Number 5"/>
<w:LsdException Locked="false" Priority="10" QFormat="true" Name="Title"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="Closing"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="Signature"/>
<w:LsdException Locked="false" Priority="1" SemiHidden="true"
UnhideWhenUsed="true" Name="Default Paragraph Font"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="Body Text"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="Body Text Indent"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="List Continue"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="List Continue 2"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="List Continue 3"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="List Continue 4"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="List Continue 5"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="Message Header"/>
<w:LsdException Locked="false" Priority="11" QFormat="true" Name="Subtitle"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="Salutation"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="Date"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="Body Text First Indent"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="Body Text First Indent 2"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="Note Heading"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="Body Text 2"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="Body Text 3"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="Body Text Indent 2"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="Body Text Indent 3"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="Block Text"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="Hyperlink"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="FollowedHyperlink"/>
<w:LsdException Locked="false" Priority="22" QFormat="true" Name="Strong"/>
<w:LsdException Locked="false" Priority="20" QFormat="true" Name="Emphasis"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="Document Map"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="Plain Text"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="E-mail Signature"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="HTML Top of Form"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="HTML Bottom of Form"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="Normal (Web)"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="HTML Acronym"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="HTML Address"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="HTML Cite"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="HTML Code"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="HTML Definition"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="HTML Keyboard"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="HTML Preformatted"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="HTML Sample"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="HTML Typewriter"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="HTML Variable"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="Normal Table"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="annotation subject"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="No List"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="Outline List 1"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="Outline List 2"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="Outline List 3"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="Table Simple 1"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="Table Simple 2"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="Table Simple 3"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="Table Classic 1"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="Table Classic 2"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="Table Classic 3"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="Table Classic 4"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="Table Colorful 1"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="Table Colorful 2"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="Table Colorful 3"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="Table Columns 1"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="Table Columns 2"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="Table Columns 3"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="Table Columns 4"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="Table Columns 5"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="Table Grid 1"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="Table Grid 2"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="Table Grid 3"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="Table Grid 4"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="Table Grid 5"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="Table Grid 6"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="Table Grid 7"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="Table Grid 8"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="Table List 1"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="Table List 2"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="Table List 3"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="Table List 4"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="Table List 5"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="Table List 6"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="Table List 7"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="Table List 8"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="Table 3D effects 1"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="Table 3D effects 2"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="Table 3D effects 3"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="Table Contemporary"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="Table Elegant"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="Table Professional"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="Table Subtle 1"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="Table Subtle 2"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="Table Web 1"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="Table Web 2"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="Table Web 3"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="Balloon Text"/>
<w:LsdException Locked="false" Priority="39" Name="Table Grid"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="Table Theme"/>
<w:LsdException Locked="false" SemiHidden="true" Name="Placeholder Text"/>
<w:LsdException Locked="false" Priority="1" QFormat="true" Name="No Spacing"/>
<w:LsdException Locked="false" Priority="60" Name="Light Shading"/>
<w:LsdException Locked="false" Priority="61" Name="Light List"/>
<w:LsdException Locked="false" Priority="62" Name="Light Grid"/>
<w:LsdException Locked="false" Priority="63" Name="Medium Shading 1"/>
<w:LsdException Locked="false" Priority="64" Name="Medium Shading 2"/>
<w:LsdException Locked="false" Priority="65" Name="Medium List 1"/>
<w:LsdException Locked="false" Priority="66" Name="Medium List 2"/>
<w:LsdException Locked="false" Priority="67" Name="Medium Grid 1"/>
<w:LsdException Locked="false" Priority="68" Name="Medium Grid 2"/>
<w:LsdException Locked="false" Priority="69" Name="Medium Grid 3"/>
<w:LsdException Locked="false" Priority="70" Name="Dark List"/>
<w:LsdException Locked="false" Priority="71" Name="Colorful Shading"/>
<w:LsdException Locked="false" Priority="72" Name="Colorful List"/>
<w:LsdException Locked="false" Priority="73" Name="Colorful Grid"/>
<w:LsdException Locked="false" Priority="60" Name="Light Shading Accent 1"/>
<w:LsdException Locked="false" Priority="61" Name="Light List Accent 1"/>
<w:LsdException Locked="false" Priority="62" Name="Light Grid Accent 1"/>
<w:LsdException Locked="false" Priority="63" Name="Medium Shading 1 Accent 1"/>
<w:LsdException Locked="false" Priority="64" Name="Medium Shading 2 Accent 1"/>
<w:LsdException Locked="false" Priority="65" Name="Medium List 1 Accent 1"/>
<w:LsdException Locked="false" SemiHidden="true" Name="Revision"/>
<w:LsdException Locked="false" Priority="34" QFormat="true"
Name="List Paragraph"/>
<w:LsdException Locked="false" Priority="29" QFormat="true" Name="Quote"/>
<w:LsdException Locked="false" Priority="30" QFormat="true"
Name="Intense Quote"/>
<w:LsdException Locked="false" Priority="66" Name="Medium List 2 Accent 1"/>
<w:LsdException Locked="false" Priority="67" Name="Medium Grid 1 Accent 1"/>
<w:LsdException Locked="false" Priority="68" Name="Medium Grid 2 Accent 1"/>
<w:LsdException Locked="false" Priority="69" Name="Medium Grid 3 Accent 1"/>
<w:LsdException Locked="false" Priority="70" Name="Dark List Accent 1"/>
<w:LsdException Locked="false" Priority="71" Name="Colorful Shading Accent 1"/>
<w:LsdException Locked="false" Priority="72" Name="Colorful List Accent 1"/>
<w:LsdException Locked="false" Priority="73" Name="Colorful Grid Accent 1"/>
<w:LsdException Locked="false" Priority="60" Name="Light Shading Accent 2"/>
<w:LsdException Locked="false" Priority="61" Name="Light List Accent 2"/>
<w:LsdException Locked="false" Priority="62" Name="Light Grid Accent 2"/>
<w:LsdException Locked="false" Priority="63" Name="Medium Shading 1 Accent 2"/>
<w:LsdException Locked="false" Priority="64" Name="Medium Shading 2 Accent 2"/>
<w:LsdException Locked="false" Priority="65" Name="Medium List 1 Accent 2"/>
<w:LsdException Locked="false" Priority="66" Name="Medium List 2 Accent 2"/>
<w:LsdException Locked="false" Priority="67" Name="Medium Grid 1 Accent 2"/>
<w:LsdException Locked="false" Priority="68" Name="Medium Grid 2 Accent 2"/>
<w:LsdException Locked="false" Priority="69" Name="Medium Grid 3 Accent 2"/>
<w:LsdException Locked="false" Priority="70" Name="Dark List Accent 2"/>
<w:LsdException Locked="false" Priority="71" Name="Colorful Shading Accent 2"/>
<w:LsdException Locked="false" Priority="72" Name="Colorful List Accent 2"/>
<w:LsdException Locked="false" Priority="73" Name="Colorful Grid Accent 2"/>
<w:LsdException Locked="false" Priority="60" Name="Light Shading Accent 3"/>
<w:LsdException Locked="false" Priority="61" Name="Light List Accent 3"/>
<w:LsdException Locked="false" Priority="62" Name="Light Grid Accent 3"/>
<w:LsdException Locked="false" Priority="63" Name="Medium Shading 1 Accent 3"/>
<w:LsdException Locked="false" Priority="64" Name="Medium Shading 2 Accent 3"/>
<w:LsdException Locked="false" Priority="65" Name="Medium List 1 Accent 3"/>
<w:LsdException Locked="false" Priority="66" Name="Medium List 2 Accent 3"/>
<w:LsdException Locked="false" Priority="67" Name="Medium Grid 1 Accent 3"/>
<w:LsdException Locked="false" Priority="68" Name="Medium Grid 2 Accent 3"/>
<w:LsdException Locked="false" Priority="69" Name="Medium Grid 3 Accent 3"/>
<w:LsdException Locked="false" Priority="70" Name="Dark List Accent 3"/>
<w:LsdException Locked="false" Priority="71" Name="Colorful Shading Accent 3"/>
<w:LsdException Locked="false" Priority="72" Name="Colorful List Accent 3"/>
<w:LsdException Locked="false" Priority="73" Name="Colorful Grid Accent 3"/>
<w:LsdException Locked="false" Priority="60" Name="Light Shading Accent 4"/>
<w:LsdException Locked="false" Priority="61" Name="Light List Accent 4"/>
<w:LsdException Locked="false" Priority="62" Name="Light Grid Accent 4"/>
<w:LsdException Locked="false" Priority="63" Name="Medium Shading 1 Accent 4"/>
<w:LsdException Locked="false" Priority="64" Name="Medium Shading 2 Accent 4"/>
<w:LsdException Locked="false" Priority="65" Name="Medium List 1 Accent 4"/>
<w:LsdException Locked="false" Priority="66" Name="Medium List 2 Accent 4"/>
<w:LsdException Locked="false" Priority="67" Name="Medium Grid 1 Accent 4"/>
<w:LsdException Locked="false" Priority="68" Name="Medium Grid 2 Accent 4"/>
<w:LsdException Locked="false" Priority="69" Name="Medium Grid 3 Accent 4"/>
<w:LsdException Locked="false" Priority="70" Name="Dark List Accent 4"/>
<w:LsdException Locked="false" Priority="71" Name="Colorful Shading Accent 4"/>
<w:LsdException Locked="false" Priority="72" Name="Colorful List Accent 4"/>
<w:LsdException Locked="false" Priority="73" Name="Colorful Grid Accent 4"/>
<w:LsdException Locked="false" Priority="60" Name="Light Shading Accent 5"/>
<w:LsdException Locked="false" Priority="61" Name="Light List Accent 5"/>
<w:LsdException Locked="false" Priority="62" Name="Light Grid Accent 5"/>
<w:LsdException Locked="false" Priority="63" Name="Medium Shading 1 Accent 5"/>
<w:LsdException Locked="false" Priority="64" Name="Medium Shading 2 Accent 5"/>
<w:LsdException Locked="false" Priority="65" Name="Medium List 1 Accent 5"/>
<w:LsdException Locked="false" Priority="66" Name="Medium List 2 Accent 5"/>
<w:LsdException Locked="false" Priority="67" Name="Medium Grid 1 Accent 5"/>
<w:LsdException Locked="false" Priority="68" Name="Medium Grid 2 Accent 5"/>
<w:LsdException Locked="false" Priority="69" Name="Medium Grid 3 Accent 5"/>
<w:LsdException Locked="false" Priority="70" Name="Dark List Accent 5"/>
<w:LsdException Locked="false" Priority="71" Name="Colorful Shading Accent 5"/>
<w:LsdException Locked="false" Priority="72" Name="Colorful List Accent 5"/>
<w:LsdException Locked="false" Priority="73" Name="Colorful Grid Accent 5"/>
<w:LsdException Locked="false" Priority="60" Name="Light Shading Accent 6"/>
<w:LsdException Locked="false" Priority="61" Name="Light List Accent 6"/>
<w:LsdException Locked="false" Priority="62" Name="Light Grid Accent 6"/>
<w:LsdException Locked="false" Priority="63" Name="Medium Shading 1 Accent 6"/>
<w:LsdException Locked="false" Priority="64" Name="Medium Shading 2 Accent 6"/>
<w:LsdException Locked="false" Priority="65" Name="Medium List 1 Accent 6"/>
<w:LsdException Locked="false" Priority="66" Name="Medium List 2 Accent 6"/>
<w:LsdException Locked="false" Priority="67" Name="Medium Grid 1 Accent 6"/>
<w:LsdException Locked="false" Priority="68" Name="Medium Grid 2 Accent 6"/>
<w:LsdException Locked="false" Priority="69" Name="Medium Grid 3 Accent 6"/>
<w:LsdException Locked="false" Priority="70" Name="Dark List Accent 6"/>
<w:LsdException Locked="false" Priority="71" Name="Colorful Shading Accent 6"/>
<w:LsdException Locked="false" Priority="72" Name="Colorful List Accent 6"/>
<w:LsdException Locked="false" Priority="73" Name="Colorful Grid Accent 6"/>
<w:LsdException Locked="false" Priority="19" QFormat="true"
Name="Subtle Emphasis"/>
<w:LsdException Locked="false" Priority="21" QFormat="true"
Name="Intense Emphasis"/>
<w:LsdException Locked="false" Priority="31" QFormat="true"
Name="Subtle Reference"/>
<w:LsdException Locked="false" Priority="32" QFormat="true"
Name="Intense Reference"/>
<w:LsdException Locked="false" Priority="33" QFormat="true" Name="Book Title"/>
<w:LsdException Locked="false" Priority="37" SemiHidden="true"
UnhideWhenUsed="true" Name="Bibliography"/>
<w:LsdException Locked="false" Priority="39" SemiHidden="true"
UnhideWhenUsed="true" QFormat="true" Name="TOC Heading"/>
<w:LsdException Locked="false" Priority="41" Name="Plain Table 1"/>
<w:LsdException Locked="false" Priority="42" Name="Plain Table 2"/>
<w:LsdException Locked="false" Priority="43" Name="Plain Table 3"/>
<w:LsdException Locked="false" Priority="44" Name="Plain Table 4"/>
<w:LsdException Locked="false" Priority="45" Name="Plain Table 5"/>
<w:LsdException Locked="false" Priority="40" Name="Grid Table Light"/>
<w:LsdException Locked="false" Priority="46" Name="Grid Table 1 Light"/>
<w:LsdException Locked="false" Priority="47" Name="Grid Table 2"/>
<w:LsdException Locked="false" Priority="48" Name="Grid Table 3"/>
<w:LsdException Locked="false" Priority="49" Name="Grid Table 4"/>
<w:LsdException Locked="false" Priority="50" Name="Grid Table 5 Dark"/>
<w:LsdException Locked="false" Priority="51" Name="Grid Table 6 Colorful"/>
<w:LsdException Locked="false" Priority="52" Name="Grid Table 7 Colorful"/>
<w:LsdException Locked="false" Priority="46"
Name="Grid Table 1 Light Accent 1"/>
<w:LsdException Locked="false" Priority="47" Name="Grid Table 2 Accent 1"/>
<w:LsdException Locked="false" Priority="48" Name="Grid Table 3 Accent 1"/>
<w:LsdException Locked="false" Priority="49" Name="Grid Table 4 Accent 1"/>
<w:LsdException Locked="false" Priority="50" Name="Grid Table 5 Dark Accent 1"/>
<w:LsdException Locked="false" Priority="51"
Name="Grid Table 6 Colorful Accent 1"/>
<w:LsdException Locked="false" Priority="52"
Name="Grid Table 7 Colorful Accent 1"/>
<w:LsdException Locked="false" Priority="46"
Name="Grid Table 1 Light Accent 2"/>
<w:LsdException Locked="false" Priority="47" Name="Grid Table 2 Accent 2"/>
<w:LsdException Locked="false" Priority="48" Name="Grid Table 3 Accent 2"/>
<w:LsdException Locked="false" Priority="49" Name="Grid Table 4 Accent 2"/>
<w:LsdException Locked="false" Priority="50" Name="Grid Table 5 Dark Accent 2"/>
<w:LsdException Locked="false" Priority="51"
Name="Grid Table 6 Colorful Accent 2"/>
<w:LsdException Locked="false" Priority="52"
Name="Grid Table 7 Colorful Accent 2"/>
<w:LsdException Locked="false" Priority="46"
Name="Grid Table 1 Light Accent 3"/>
<w:LsdException Locked="false" Priority="47" Name="Grid Table 2 Accent 3"/>
<w:LsdException Locked="false" Priority="48" Name="Grid Table 3 Accent 3"/>
<w:LsdException Locked="false" Priority="49" Name="Grid Table 4 Accent 3"/>
<w:LsdException Locked="false" Priority="50" Name="Grid Table 5 Dark Accent 3"/>
<w:LsdException Locked="false" Priority="51"
Name="Grid Table 6 Colorful Accent 3"/>
<w:LsdException Locked="false" Priority="52"
Name="Grid Table 7 Colorful Accent 3"/>
<w:LsdException Locked="false" Priority="46"
Name="Grid Table 1 Light Accent 4"/>
<w:LsdException Locked="false" Priority="47" Name="Grid Table 2 Accent 4"/>
<w:LsdException Locked="false" Priority="48" Name="Grid Table 3 Accent 4"/>
<w:LsdException Locked="false" Priority="49" Name="Grid Table 4 Accent 4"/>
<w:LsdException Locked="false" Priority="50" Name="Grid Table 5 Dark Accent 4"/>
<w:LsdException Locked="false" Priority="51"
Name="Grid Table 6 Colorful Accent 4"/>
<w:LsdException Locked="false" Priority="52"
Name="Grid Table 7 Colorful Accent 4"/>
<w:LsdException Locked="false" Priority="46"
Name="Grid Table 1 Light Accent 5"/>
<w:LsdException Locked="false" Priority="47" Name="Grid Table 2 Accent 5"/>
<w:LsdException Locked="false" Priority="48" Name="Grid Table 3 Accent 5"/>
<w:LsdException Locked="false" Priority="49" Name="Grid Table 4 Accent 5"/>
<w:LsdException Locked="false" Priority="50" Name="Grid Table 5 Dark Accent 5"/>
<w:LsdException Locked="false" Priority="51"
Name="Grid Table 6 Colorful Accent 5"/>
<w:LsdException Locked="false" Priority="52"
Name="Grid Table 7 Colorful Accent 5"/>
<w:LsdException Locked="false" Priority="46"
Name="Grid Table 1 Light Accent 6"/>
<w:LsdException Locked="false" Priority="47" Name="Grid Table 2 Accent 6"/>
<w:LsdException Locked="false" Priority="48" Name="Grid Table 3 Accent 6"/>
<w:LsdException Locked="false" Priority="49" Name="Grid Table 4 Accent 6"/>
<w:LsdException Locked="false" Priority="50" Name="Grid Table 5 Dark Accent 6"/>
<w:LsdException Locked="false" Priority="51"
Name="Grid Table 6 Colorful Accent 6"/>
<w:LsdException Locked="false" Priority="52"
Name="Grid Table 7 Colorful Accent 6"/>
<w:LsdException Locked="false" Priority="46" Name="List Table 1 Light"/>
<w:LsdException Locked="false" Priority="47" Name="List Table 2"/>
<w:LsdException Locked="false" Priority="48" Name="List Table 3"/>
<w:LsdException Locked="false" Priority="49" Name="List Table 4"/>
<w:LsdException Locked="false" Priority="50" Name="List Table 5 Dark"/>
<w:LsdException Locked="false" Priority="51" Name="List Table 6 Colorful"/>
<w:LsdException Locked="false" Priority="52" Name="List Table 7 Colorful"/>
<w:LsdException Locked="false" Priority="46"
Name="List Table 1 Light Accent 1"/>
<w:LsdException Locked="false" Priority="47" Name="List Table 2 Accent 1"/>
<w:LsdException Locked="false" Priority="48" Name="List Table 3 Accent 1"/>
<w:LsdException Locked="false" Priority="49" Name="List Table 4 Accent 1"/>
<w:LsdException Locked="false" Priority="50" Name="List Table 5 Dark Accent 1"/>
<w:LsdException Locked="false" Priority="51"
Name="List Table 6 Colorful Accent 1"/>
<w:LsdException Locked="false" Priority="52"
Name="List Table 7 Colorful Accent 1"/>
<w:LsdException Locked="false" Priority="46"
Name="List Table 1 Light Accent 2"/>
<w:LsdException Locked="false" Priority="47" Name="List Table 2 Accent 2"/>
<w:LsdException Locked="false" Priority="48" Name="List Table 3 Accent 2"/>
<w:LsdException Locked="false" Priority="49" Name="List Table 4 Accent 2"/>
<w:LsdException Locked="false" Priority="50" Name="List Table 5 Dark Accent 2"/>
<w:LsdException Locked="false" Priority="51"
Name="List Table 6 Colorful Accent 2"/>
<w:LsdException Locked="false" Priority="52"
Name="List Table 7 Colorful Accent 2"/>
<w:LsdException Locked="false" Priority="46"
Name="List Table 1 Light Accent 3"/>
<w:LsdException Locked="false" Priority="47" Name="List Table 2 Accent 3"/>
<w:LsdException Locked="false" Priority="48" Name="List Table 3 Accent 3"/>
<w:LsdException Locked="false" Priority="49" Name="List Table 4 Accent 3"/>
<w:LsdException Locked="false" Priority="50" Name="List Table 5 Dark Accent 3"/>
<w:LsdException Locked="false" Priority="51"
Name="List Table 6 Colorful Accent 3"/>
<w:LsdException Locked="false" Priority="52"
Name="List Table 7 Colorful Accent 3"/>
<w:LsdException Locked="false" Priority="46"
Name="List Table 1 Light Accent 4"/>
<w:LsdException Locked="false" Priority="47" Name="List Table 2 Accent 4"/>
<w:LsdException Locked="false" Priority="48" Name="List Table 3 Accent 4"/>
<w:LsdException Locked="false" Priority="49" Name="List Table 4 Accent 4"/>
<w:LsdException Locked="false" Priority="50" Name="List Table 5 Dark Accent 4"/>
<w:LsdException Locked="false" Priority="51"
Name="List Table 6 Colorful Accent 4"/>
<w:LsdException Locked="false" Priority="52"
Name="List Table 7 Colorful Accent 4"/>
<w:LsdException Locked="false" Priority="46"
Name="List Table 1 Light Accent 5"/>
<w:LsdException Locked="false" Priority="47" Name="List Table 2 Accent 5"/>
<w:LsdException Locked="false" Priority="48" Name="List Table 3 Accent 5"/>
<w:LsdException Locked="false" Priority="49" Name="List Table 4 Accent 5"/>
<w:LsdException Locked="false" Priority="50" Name="List Table 5 Dark Accent 5"/>
<w:LsdException Locked="false" Priority="51"
Name="List Table 6 Colorful Accent 5"/>
<w:LsdException Locked="false" Priority="52"
Name="List Table 7 Colorful Accent 5"/>
<w:LsdException Locked="false" Priority="46"
Name="List Table 1 Light Accent 6"/>
<w:LsdException Locked="false" Priority="47" Name="List Table 2 Accent 6"/>
<w:LsdException Locked="false" Priority="48" Name="List Table 3 Accent 6"/>
<w:LsdException Locked="false" Priority="49" Name="List Table 4 Accent 6"/>
<w:LsdException Locked="false" Priority="50" Name="List Table 5 Dark Accent 6"/>
<w:LsdException Locked="false" Priority="51"
Name="List Table 6 Colorful Accent 6"/>
<w:LsdException Locked="false" Priority="52"
Name="List Table 7 Colorful Accent 6"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="Mention"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="Smart Hyperlink"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="Hashtag"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="Unresolved Mention"/>
<w:LsdException Locked="false" SemiHidden="true" UnhideWhenUsed="true"
Name="Smart Link"/>
</w:LatentStyles>
</xml><![endif]-->
<style>
<!--
/* Font Definitions */
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;
mso-font-charset:0;
mso-generic-font-family:roman;
mso-font-pitch:variable;
mso-font-signature:3 0 0 0 1 0;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;
mso-font-charset:0;
mso-generic-font-family:swiss;
mso-font-pitch:variable;
mso-font-signature:-536859905 -1073732485 9 0 511 0;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{mso-style-unhide:no;
mso-style-qformat:yes;
mso-style-parent:"";
margin:0cm;
margin-bottom:.0001pt;
mso-pagination:widow-orphan;
font-size:12.0pt;
font-family:"Calibri",sans-serif;
mso-ascii-font-family:Calibri;
mso-ascii-theme-font:minor-latin;
mso-fareast-font-family:Calibri;
mso-fareast-theme-font:minor-latin;
mso-hansi-font-family:Calibri;
mso-hansi-theme-font:minor-latin;
mso-bidi-font-family:"Times New Roman";
mso-bidi-theme-font:minor-bidi;
mso-fareast-language:EN-US;}
.MsoChpDefault
{mso-style-type:export-only;
mso-default-props:yes;
font-family:"Calibri",sans-serif;
mso-ascii-font-family:Calibri;
mso-ascii-theme-font:minor-latin;
mso-fareast-font-family:Calibri;
mso-fareast-theme-font:minor-latin;
mso-hansi-font-family:Calibri;
mso-hansi-theme-font:minor-latin;
mso-bidi-font-family:"Times New Roman";
mso-bidi-theme-font:minor-bidi;
mso-fareast-language:EN-US;}
@page WordSection1
{size:612.0pt 792.0pt;
margin:72.0pt 72.0pt 72.0pt 72.0pt;
mso-header-margin:36.0pt;
mso-footer-margin:36.0pt;
mso-paper-source:0;}
div.WordSection1
{page:WordSection1;}
-->
</style>
<!--[if gte mso 10]>
<style>
/* Style Definitions */
table.MsoNormalTable
{mso-style-name:"Table Normal";
mso-tstyle-rowband-size:0;
mso-tstyle-colband-size:0;
mso-style-noshow:yes;
mso-style-priority:99;
mso-style-parent:"";
mso-padding-alt:0cm 5.4pt 0cm 5.4pt;
mso-para-margin:0cm;
mso-para-margin-bottom:.0001pt;
mso-pagination:widow-orphan;
font-size:12.0pt;
font-family:"Calibri",sans-serif;
mso-ascii-font-family:Calibri;
mso-ascii-theme-font:minor-latin;
mso-hansi-font-family:Calibri;
mso-hansi-theme-font:minor-latin;
mso-bidi-font-family:"Times New Roman";
mso-bidi-theme-font:minor-bidi;
mso-fareast-language:EN-US;}
</style>
<![endif]-->
<!--StartFragment-->
<div class="MsoNormal">
<span style="font-family: "Times New Roman",serif; mso-fareast-font-family: "Times New Roman";">Thursday commenced with a phenomenal simulation illustrating
the operation of Kanban across the supply-chain before we boarded a bus for
some welcome downtime on the 3 hour journey to Kyoto for what I personally
found to be the most inspiring visit of the tour to <a href="https://www.omron.com/about/history/ayumi/innovation/#history1978-2" target="_blank">Omron Taiyo</a></span><span style="font-family: "Times New Roman", serif; font-size: 12pt;">, a joint venture between Omron corporation and Japan
Sun Industries aimed at integrating people with disabilities into the
workforce. 120 of 134 staff had some form of disability (physical, intellectual
or emotional) – sustainably and profitably producing healthcare equipment,
power supplies, switches and other components.</span><span style="font-family: "Times New Roman", serif; font-size: 12pt;">
</span><span style="font-family: "Times New Roman", serif; font-size: 12pt;">By this stage, the metaphor of “the cliff edge” was front-of-mind on
every visit and Omron Taiyo exemplified it as the relentless ingenuity required
to support paraplegics, people with one arm, and those with other less visible
disabilities in the workplace.</span><span style="font-family: "Times New Roman", serif; font-size: 12pt;"> </span><span style="font-family: "Times New Roman", serif; font-size: 12pt;">The
endless hunt for any edge of improvement was tangible walking the floor, right
down to spreading panoramic pictures on the back of binders in filing cabinets
to encourage them being placed back in the right position and save 3-4 seconds
for people looking for a binder. </span></div>
<div class="MsoNormal">
<span style="font-family: "Times New Roman", serif; font-size: 12pt;"><br /></span></div>
<table align="center" cellpadding="0" cellspacing="0" class="tr-caption-container" style="margin-left: auto; margin-right: auto; text-align: center;"><tbody>
<tr><td style="text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhGOsTScMZTbUMvg9eh5939D1yi5CRYgwpShr5kn_b46Y6ZOMwOvS9oB0Jz0bs2ABjXYbh6xTFdMnQOiArSOO3RcpB4ostpcwxAaVz2EMboqRydnWqClLJicFYcvMGCTlWEz3FRtaUjqdFM/s1600/Omron.jpg" imageanchor="1" style="margin-left: auto; margin-right: auto;"><img border="0" data-original-height="301" data-original-width="451" height="266" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhGOsTScMZTbUMvg9eh5939D1yi5CRYgwpShr5kn_b46Y6ZOMwOvS9oB0Jz0bs2ABjXYbh6xTFdMnQOiArSOO3RcpB4ostpcwxAaVz2EMboqRydnWqClLJicFYcvMGCTlWEz3FRtaUjqdFM/s400/Omron.jpg" width="400" /></a></td></tr>
<tr><td class="tr-caption" style="text-align: center;">Briefing at Omron Taiyo</td></tr>
</tbody></table>
<div class="MsoNormal">
<span style="font-family: "Times New Roman", serif; font-size: 12pt;"><br /></span></div>
<div class="MsoNormal">
<span style="font-family: Times New Roman, serif;">After a “night off” in Kyoto, Friday began with a visit to Takatsuki General Hospital to explore Lean in healthcare. The hospital proudly informed us of the 3000+ improvement initiatives they had implemented under TQM and their use of Quality Circles to build the improvement mindset along with explaining some of the challenges of adapting from the manufacturing to healthcare context. Their cliff-edge, a rapidly growing percentage of elderly population (65+) living longer and longer stressing the healthcare system. As we toured behind-the-scenes in the most startling hospital environment I have ever seen, I found myself wishing my wife (who is a nurse) was with me and looking forward to sharing what I had seen with her and enriching my layman’s view of the differentiation.</span></div>
<div class="MsoNormal">
<span style="font-family: Times New Roman, serif;"><br /></span></div>
<table align="center" cellpadding="0" cellspacing="0" class="tr-caption-container" style="margin-left: auto; margin-right: auto; text-align: center;"><tbody>
<tr><td style="text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhL2EtgJO-Xyyf97MmZXI_TH4VJXzWxV1oKrRmUOhMufQN_k5ydAZkzTvNyuaIBHsDyDlqf5FXfo_AuSTErpHqkO_rBNSDoQ8nrslNYj7u7zHML7NL9_IvjbQ_Ya_HqB2bqRuz1lOEhDQAJ/s1600/Hospital.jpg" imageanchor="1" style="margin-left: auto; margin-right: auto;"><img border="0" data-original-height="99" data-original-width="457" height="138" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhL2EtgJO-Xyyf97MmZXI_TH4VJXzWxV1oKrRmUOhMufQN_k5ydAZkzTvNyuaIBHsDyDlqf5FXfo_AuSTErpHqkO_rBNSDoQ8nrslNYj7u7zHML7NL9_IvjbQ_Ya_HqB2bqRuz1lOEhDQAJ/s640/Hospital.jpg" width="640" /></a></td></tr>
<tr><td class="tr-caption" style="text-align: center;">Kaizen outcomes, therapy innovation, & the masked Coactivation team (plus honorary teammate from Belgium)</td></tr>
</tbody></table>
</div>
<div>
Friday afternoon brought a final debrief followed by a celebratory closing dinner and some late-night Kyoto bar-hopping. I have a number of blog posts I’d been holding off on until after Japan, and look forward to delving more deeply into some of the insights of the trip in those. If there was one thing that was reinforced every day as a contrast between the Agile world and TPS it was an obsession with data. We tend to be far too “fluffy and fuzzy”, and the usefulness of hard data whether it be for optimising workflow based on effective demand forecasting, optimising the deployment of your workforce, scheduling work, identifying waste, or steering improvement was amazing to see in action. <!--EndFragment--></div>
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEje0TT01YnElhvnzsNJL3p7OTU0MN_GjxsnqGv6jBDo4M7JJAlXxsmkE28K8r_0X8kY8Sgt_NIcAcfRhOZ6ocb8n5HXXbJr_gwROSoMq2ATjY7kjaCa0CIkgiiLTHdgAvvWs5AqtNqIbKPI/s1600/Isuzu+2.jpg" imageanchor="1" style="clear: left; float: left; margin-bottom: 1em; margin-right: 1em;"></a></div>
Mark Richardshttp://www.blogger.com/profile/12477809828045353101noreply@blogger.com14tag:blogger.com,1999:blog-7030397814607511868.post-55701798189279344312019-03-04T02:21:00.000-08:002019-03-04T02:21:09.742-08:00Effective Change Control "by Release" in SAFe<blockquote class="tr_bq">
“<i>Control by Release … Control by turning loose within well-understood parameters. Control by trusting the process. This doesn’t mean anything goes</i>” – Artful Making, Rob Austin and Lee Devin</blockquote>
<br />
Under a “traditional” delivery model, organizations employ a combination of gating and detailed scope, cost and timeline commitments to facilitate governance, change control and executive oversight of strategic product spend. <br />
<br />
With SAFe, the move to Lean Budgeting and outcome-based metrics enables the elimination of much of the overhead and inefficiency inherent in the traditional approach. SAFe 4.6 crystallized this with the introduction of the four <a href="https://www.scaledagileframework.com/guardrails/" target="_blank">Portfolio Guardrails</a>:<br />
<br />
<ol>
<li>Guiding investments by horizon</li>
<li>Optimizing value and solution integrity with capacity allocation</li>
<li>Approving Significant initiatives</li>
<li>Continuous Business Owner engagement</li>
</ol>
<br />
The opening quote is from one of the books that profoundly influenced me early in my Agile career – Artful Making. The notion of “Control by Release” has been a core component of my coaching toolkit for many years, particularly in the context of decentralization. In this post, I will explore the “Control by Release” aspect of each guardrail as we determine “what to do” then move beyond into the tools that help us during PI execution while we “are doing”.<br />
<br />
<h4>
Guiding Investments by Horizon</h4>
This guardrail controls the percentage of investment capacity that can be consumed by a particular horizon of investment idea. “Release” is achieved by not constraining the ideas under consideration, but "control" ensures innovative horizon 3 and “coming attraction” horizon 2 ideas are not drowned out by the all-consuming “demand of today” in horizon 1.<br />
<br />
Horizon allocation authority often exceeds the remit of the Portfolio itself, requiring validation at the enterprise level – particularly given the high-risk nature of horizon 3 investments. However, once established it releases the Portfolio team to more futuristic investments within the agreed constraint.<br />
<h4>
<br /></h4>
<h4>
Optimizing value and solution integrity with capacity allocation</h4>
Another percentage-based control tool, this is typically applied more at the Solution and Program levels. A classic scenario is B2B digital products – often stuck in the following dilemma:<br />
<br />
<ul>
<li>“Without the B2B providers we can’t attract B2C consumers” </li>
<li>“Without B2C consumers we can’t sign up the B2B providers”. </li>
</ul>
<br />
This is a level well above “what feature should we build” – it’s a strategic tool. “For the next 2 PI’s, we want to invest heavily in the B2B space with 70% of our capacity”. We thus achieve "control" by specifying the percentage of ART capacity to be consumed by B2B features and "release" by the fact we have not actually talked about what B2B features should be considered. <br />
<br />
This decision is often not within the remit of Product Management. It will need validation by their Business Owners, Portfolio Management or some combination of the two – but once set they are released to find the best features to use that capacity for.<br />
<h4>
<br /></h4>
<h4>
Approving Significant Initiatives</h4>
The Product Manager for an ART has significant remit when it comes to feature selection. In mature SAFe most features built are independent features identified in service of product strategy rather than derived from Epics. The Product Manager is empowered to identify Features and facilitate their prioritization (through WSJF), but accountable for the economic outcomes achieved by the ART justifying the spend. There is a level of safety and control in this as we know that the Feature should have a quantifiable, rapidly measurable benefit and has to be small – small enough to fit in a single PI for a single ART. <br />
<br />
However, what happens when the Product Manager encounters a big idea – something too big to be a Feature - an Epic. This attracts more due diligence, approval and monitoring at the Portfolio level. “Before you start down this path, we need to validate it.” <br />
<br />
The Product Manager is “released” to pursue a range of small valuable investments, but works within the “control” that if the investment passes a certain threshold higher authorities must become involved. <br />
<h4>
<br /></h4>
<h4>
Continuous Business Owner Engagement</h4>
Late last year I <a href="http://www.agilenotanarchy.com/2018/10/unleash-your-art-with-right-business.html" target="_blank">dedicated a whole post to this</a>. How do we “release” the Product Manager to do the job they’ve been appointed to do? By providing the “control” of engagement with executive business owners for involvement in moments where key constraints are established.<br />
<br />
There are 4 clearly defined “control” events for this in SAFe:<br />
<br />
<ul>
<li>Business Owners collaborate to define the Cost of Delay for candidate Features and thus “control” the priorities whilst having “released” the Product Manager to find features to present for prioritization.</li>
<li>Business Owners collaborate to “control” tradeoff decisions during Management Review at PI planning whilst having “released” the teams to identify the tradeoffs required, then accept the committed objectives to establish a “control” around commitment expectations for the PI.</li>
<li>The System Demo (attended by the Business Owners) demonstrates progress in the previous iteration, and should illustrate alignment to the agreement reached at PI planning.</li>
<li>The PI Demo where achieved outcomes are assessed against committed objectives by the Business Owners</li>
</ul>
<br />
<h3>
Beyond Portfolio Guardrails</h3>
Each of the guardrails provides controls on what we choose to do, at varying levels of seniority, regularity and granularity. However, what happens once we are “doing?” Or, in more traditional language “how do we apply change control during execution?”.<br />
<br />
The “hippy agilist” inside me gets nervous about tackling the second half of this post. Surely I’m not going to start talking about the dreaded “change request”. What about Agile principle 2 – “<i>Welcome changing requirements, even late in development</i>”? Unfortunately, I have probably seen this principle abused more than any other (albeit, the sustainable pace of principle 8 is definitely the most commonly ignored – typically in the context of abuse of principle 2). All too often, it is interpreted as “I thought this was agile and I could change my mind anytime I liked” without accepting that the change might impact cost, timeframe or other commitments.<br />
<br />
So, how do we enable the “release” to embrace changing requirements whilst maintaining the “control” to ensure this occurs in a responsible fashion?<br />
<br />
<h3>
Establishing Guardrails for ART execution</h3>
We have the hints for these controls from the Portfolio. A decision-making framework must address the following:<br />
<br />
<ul>
<li>At what point does a Team need to escalate a decision or notification to the Program level?</li>
<li>At what point does an ART need to escalate a decision or notification to their Business Owners?</li>
</ul>
<br />
The answer in both cases lies in the controls we have established:<br />
<br />
<ul>
<li>Committed PI Objectives</li>
<li>Capacity Allocation</li>
</ul>
<br />
Both have been validated and accepted by the Business Owners. The ART has been “released” to make any change it likes within these controls. For example, it has pre-agreed with the Business Owners that if the PI runs into challenges the stretch objectives can be sacrificed without consultation. However, to examine some example “control triggers”:<br />
<br />
<h4>
Capacity Allocation for BAU</h4>
The application of capacity allocation to BAU/Unplanned work was explored in detail in <a href="http://www.agilenotanarchy.com/2019/02/dealing-with-unplanned-andor-bau-work.html" target="_blank">my recent post on BAU and Unplanned work</a>, but to illustrate a change control example:<br />
<br />
<ul>
<li>A team was given a capacity allocation of 10% for BAU/Unplanned work</li>
<li>The Product Owner is now “released” to prioritize any stories they feel are important (be it minor enhancements, tech debt remediation or minor production defect fixes) so long as they fall within 10% of the team’s capacity each iteration.</li>
<li>In the event that BAU and Unplanned work threatens to exceed the capacity constraint (eg a string of urgent minor enhancement requests from a noisy stakeholder), we trigger the “control”. It’s no longer a team decision, and must be escalated to Program Level.</li>
<li>At the Program Level, there may be a “System-level” solution to it that can still be constrained to the ART. For instance, redirecting some of the work to another team or sacrificing a stretch objective due to the importance of the unplanned work.</li>
<li>If there is no ART-level solution that doesn’t compromise committed objectives and the Program Team cannot politically refuse the BAU work, it must be escalated to the Business Owners to make the decision: “Are we willing to sacrifice a strategic committed objective for this unplanned work or will we exercise our executive authority to defer the unplanned work?”</li>
</ul>
<br />
<h4>
Significant change in Committed Objective</h4>
We know that teams don’t commit to delivering either their plans or their stories at PI Planning – they commit to achieving their committed objectives. The stories and plans constitute a current belief as to the best way to achieve the objectives. There’s more to this story than meets the eye though:<br />
<br />
<ul>
<li>Whilst objectives are meant to be “SMART”, they rarely are. This leaves interpretation very much open, and its easy for a Product Owner to wind up in a world of pain with subject matter experts, stakeholders and product managers arguing that there is implicit scope in the objective that the team never planned for.</li>
<li>The objectives are “in a system context”. Business Owners accept “the overall objectives for the ART”, and make tradeoff decisions to optimize the whole rather than the parts. Implicit in the process of arriving at this is that the team’s plan reflects the rough percentage of the team or ART capacity that will be consumed achieving the objective. (ie In the plan, there were 78 points of estimated stories associated with it). We know estimates are guesses, but if we are suddenly dealing with 150 points of stories there is no doubt we are in a world of pain. This could occur due to ugly surprises, missed stories, or interpretation arguments but however it happens there’s no doubt we’re in pain. Whether it’s caused by dysfunction between the Product Owner and Team, Product Owner and Product Manager, or Product Owner and Stakeholder this objective may compromise a number of others.</li>
</ul>
A common technique is to establish a “size threshold” type control. For example, in the event that the total estimated size for the Feature varies by more than 20% from that established at PI planning, it should be escalated to Program Level for review. Often, it can be solved at the Program Level through effective tradeoff decisions (by resetting expectations, swinging other teams to the rescue or sacrificing stretch objectives). However, if it cannot be resolved we’re now in a position where following through on one committed objective compromises one or more others – and that’s a Business Owner decision. Once again, it should be escalated. They may lend their executive support to downscoping the work, or elect to sacrifice another objective to support it continuing in its inflated state.<div>
<br /><h4>
An objective cannot be met. </h4>
<br />
This seems to happen most often due to an issue with an external dependency (eg delayed infrastructure, rejection of design by ARB). As soon as the ART is aware that an objective cannot be met, this must be escalated to the Business Owners. Notwithstanding the importance of transparency, its quite possible that they can swing their executive weight behind moving the blockage.<br />
<br />
<h3>
Conclusion</h3>
If I had read this post 10 years ago, my response would have been “that’s far too structured to be agile”. My views have become a little less simplistic over the years as I’ve worked with large organizations and government agencies who need evidence of documented controls in place and are looking for “simpler, less wasteful, but still responsible”.<br />
<br />
But, to be honest, what motivates me most to address it is helping “teams in pain”. I’ve worked with a number of ARTs in recent years who have struggled massively with achieving 50% “Release Predictability” let alone 80% even with obscene levels of overtime. There are numerous contributing issues, but uncontrolled scope creep is a recurring culprit. Teams trying to collaborate with their Product Owners accept too much change with the Product Owners bright new ideas. Product Owners struggle to push back when their Product Manager keeps reinterpreting the goalposts of their Features thanks to fuzzy PI objectives and absent/incomplete Feature Acceptance Criteria. Product Owners struggle to say no when senior stakeholders come up with great ideas. It’s not fun, and teams enjoy neither the overtime pressure nor the feeling of failure when they miss their objectives time after time.<br />
<br />
The truth is, every change involves a decision and every decision is a tradeoff decision. A team will make a trade-off that leads to team-level optimization, a Program Team will make a trade-off that leads to ART-level optimization, and Business Owners will optimize still more broadly. Good backlog discipline and effective leveraging of the controls built into SAFe enable the right trade-offs to be made at the right level at the right time, and satisfy the auditors that effective controls are in place!<br />
<div>
<br /></div>
</div>
Mark Richardshttp://www.blogger.com/profile/12477809828045353101noreply@blogger.com17tag:blogger.com,1999:blog-7030397814607511868.post-91876849941038768232019-02-25T02:31:00.000-08:002019-02-25T03:03:20.100-08:00Practical Finance and Cost Allocation in SAFe<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiMyhGxl6xhJodoX9vdZEjkgMyNZnOhjUxOyxY2elvIcSxcnVYCcGx_izYxht20-Zm5EIAe0zR2ikD0cZpSzqRfebbi_hyrQp2sxhsnVpnnXKW6qqXumPRp7hWKCDdPNxSxHS5f4pj9RPnu/s1600/Finance+Balance+Scales.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" data-original-height="370" data-original-width="358" height="200" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiMyhGxl6xhJodoX9vdZEjkgMyNZnOhjUxOyxY2elvIcSxcnVYCcGx_izYxht20-Zm5EIAe0zR2ikD0cZpSzqRfebbi_hyrQp2sxhsnVpnnXKW6qqXumPRp7hWKCDdPNxSxHS5f4pj9RPnu/s200/Finance+Balance+Scales.png" width="193" /></a></div>
<br />
<br />
SAFe provides some wonderful yet daunting guidance when it comes to funding and the application of Lean Budgets. As of SAFe 4.6, we have 3 key tenets of Lean Budgeting:<br />
<br />
<ol>
<li>Fund Value Streams, not projects</li>
<li>Guide Investments by horizon</li>
<li>Participatory Budgeting</li>
</ol>
<br />
My purpose in this article is not to restate the SAFe recommendations. They’re well documented at in the <a href="https://www.scaledagileframework.com/lean-budgets/" target="_blank">Lean Budget article</a>. As always, however, I’d rather talk practice than theory – in this case in the area of “Fund Value Streams, not projects”.<br />
<br />
In summary, the theory is that we provide guaranteed funding to establish a standing capacity (in the form of an Agile Release Train), then use a combination of “<a href="https://www.scaledagileframework.com/guardrails/" target="_blank">guardrails</a>”, Epic level governance and Product Management accountability to ensure that this funded capacity is well used (building valuable features) and tune it over time based on results achieved.<br />
<br />
When I take a room of leadership through this approach its usually pretty confronting, and often provokes strong reactions. Then I share a story from an early SAFe implementation. It was with an organization that didn’t have Lean or Agile friendly funding, we just had a stable ART with stable teams that were fed by projects. And we built a record for “100% on time/on budget”. We did it in a very simple way. When something was delivered under budget, we still charged the quoted price, and as such we were able to build up a buffer fund. When something ran over budget, we drew down on the buffer fund. It was closely managed, and it all came out in the wash! By the conclusion of the story, that same room who was reacting strongly a few minutes earlier is suddenly grinning (in some cases rather nervously). I’m pretty sure every organization I’ve worked with in the past 10 years has survived historically using some variation of this technique.<br />
<br />
Some SAFe implementations are lucky enough to start with capacity funded ARTs fully following the framework guidance, but in most cases they’re still realistically project funded. It’s either a really big amorphous project being used as a masking umbrella to the standing funding model, or quite literally the single ART is being funded by numerous projects and needing to charge back.<br />
<br />
And to take it a bit further, even if we are capacity funded we usually need more granular data on how the money is spent. At minimum, we generally have some work which is Opex funded and some Capex funded. We also want some data on how much our features are costing. Hopefully we’re not falling into the trap of funding feature by feature, but when your ART is costing $3-5M per PI the organization will require us to be able to break down where those millions are going.<br />
<br />
About now, the timesheet police come out! Somebody somewhere figures out a set of WBS codes the ART should be charging against (I recently heard an example where a theoretically capacity funded ART had up to 15 WBS codes per Feature), and everyone on the ART spends some time every week trying to break up the 40 hours they worked across a bewildering array of WBS codes that will then be massaged, hounded and reconciled by a small army in a PMO.<br />
<br />
There’s a much simpler, less wasteful way. We’ve used it time and again, blessed by Finance department after Finance department – once they understand the SAFe framework. I’m going to start at the team level, then build it up to the ART.<br />
<br />
<h3>
Team Level Actuals</h3>
We usually work this on a “per Sprint” basis, and need to know two things:<br />
<br />
<ul>
<li>What did the team cost?</li>
<li>What did they work on?</li>
</ul>
<br />
<h4>
What did the team cost?</h4>
Figuring out what the team cost should be straightforward. Given that we know if you’re part of an Agile team you’re 100% dedicated, all we need is your daily rate and the days you worked. Specifics of how this daily rate is calculated for permanent employees versus contract/outsource vary too much to provide specifics, but for each of your agile teams you should know your “burn rate per sprint”. You then need a way of dealing with leave and (hopefully not) overtime. We’re not trying to totally kill timesheeting here, but we can be much more simplistic about it. Each team member should only have one WBS code to allocate their time against – the one that says “I worked a day as a member of this team”. Thus, using your knowledge of burn rates and actual days worked you have total cost for the team for the sprint.<br />
<br />
<h4>
What did they work on?</h4>
If you’re part of an Agile team, the only thing you could possibly work on is your backlog! So, we know that the entire team cost should be allocated against their backlog. From a funding perspective, aggregating this is based on effective categorization of backlog items: by parent Feature, item type or both. Consider the following example:<br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjLfMEj61z3YdPoH8O8ChH7hJuHyNPwVwzGwTZudOsdYEw7St3PXDisYMJZiReB5Ivlr3PfHMYvDO-ad61xUZXMAy-uhRQmqsU8KvDukDRpamE1TwBlzCYAX2p6imAor53-3Sxj_NJsI40A/s1600/Team+Backlog+Example+for+Actuals.JPG" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" data-original-height="376" data-original-width="785" height="153" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjLfMEj61z3YdPoH8O8ChH7hJuHyNPwVwzGwTZudOsdYEw7St3PXDisYMJZiReB5Ivlr3PfHMYvDO-ad61xUZXMAy-uhRQmqsU8KvDukDRpamE1TwBlzCYAX2p6imAor53-3Sxj_NJsI40A/s320/Team+Backlog+Example+for+Actuals.JPG" width="320" /></a></div>
<br />
<div class="separator" style="clear: both; text-align: center;">
</div>
<b>The Sprint in Aggregate</b><br />
<br />
Velocity: 28<br />
<br />
<div class="separator" style="clear: both; text-align: center;">
</div>
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiptcJfqmHP-fCpndcn5Bt3mT_WedoCKJReM2MEJ2S6hru4JUYfHz_skZTTqzHlIDD5z3KVNzhOqyrv6QJFgyCmDNnJCOKu7n53VDaZsSwYa3IIdgUNNVq40PVJ1teX8fKMoI2Ckxw0vx1f/s1600/Aggregated+Team+Backlog+for+Actuals.JPG" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" data-original-height="242" data-original-width="732" height="105" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiptcJfqmHP-fCpndcn5Bt3mT_WedoCKJReM2MEJ2S6hru4JUYfHz_skZTTqzHlIDD5z3KVNzhOqyrv6QJFgyCmDNnJCOKu7n53VDaZsSwYa3IIdgUNNVq40PVJ1teX8fKMoI2Ckxw0vx1f/s320/Aggregated+Team+Backlog+for+Actuals.JPG" width="320" /></a></div>
<br />
Based on a team burn rate of $100K/sprint, we then have:<br />
<br />
<ul>
<li>Feature A: $36,000</li>
<li>Feature B: $46,000</li>
<li>Production Defects: $11,000</li>
<li>BAU: $7,000</li>
</ul>
<br />
If your world can’t cope with ragged hierarchies, you can create “Fake Features” for the purpose of aggregation. I quite commonly see features like:<br />
<br />
<ul>
<li>Feature C: “PI 3.1 Production Defect Fixes”</li>
<li>Feature D: “PI 3.1 BAU Work”</li>
</ul>
<br />
The richness and detail of your aggregation basically depends on your “Story Type” classifications. For example, typically work done on exploration/discovery can't be capitalized, which would lead you to introduce a story type of “Exploration”.<br />
<br />
<h3>
Applying the results</h3>
At this point, we have all the costs against the temporary WBS associated with their team. All that remains is to journal the costs across from the temporary WBS to the real WBS based on your aggregates.<br />
<br />
If you’re clever, you’ll automate the entire process. Extract the timesheet data, extract the backlog data, calculate the journals and submit!<br />
<br />
<h3>
Dealing with the naysayers</h3>
At this point, some people get worried. The size of the stories was estimated, not actual. What happens if Story 1 was estimated as 3 points and was actually 5? What about stories that didn’t get accepted? Can Fibonacci sizing really be accurate enough? Our old timesheets recorded their time spent against different activities in minutes!<br />
<br />
It’s time for a reality check. I’m going to illustrate with a story. I was recently facilitating some improvement OKR setting with the folks responsible for timesheets in a large division (still mostly waterfall). One of the objectives they wanted to set involved reducing the number of timesheet resets. I asked what a timesheet reset was and why it was important to reduce them. Turned out it was when a timesheet had been submitted and was some way through the approval process when they realized there was an error and it needed to be reset to be fixed and resubmitted. Obviously, this was a pain. I asked them how often it happened and why? The response: “Usually when there’s a public holiday we get a lot of them. Everyone enters 8, 8, 8, 8, 8 (hours worked) and the approver approves on autopilot then half way through their approval run remembers the public holiday!”<br />
<br />
Everyone (and most especially finance) knows timesheet data is approximate at best. The person filling it out knows they worked 8 hours, guesses their way through how much they spent on what, and finds whatever hours are left unaccounted for and chooses something to attach them to! And the person approving it does little review, knowing they have no meaningful way to validate the accuracy.<br />
<br />
While the backlog aggregation will always have a level of inaccuracy, few will argue that it is any less accurate than the practices employed by their timesheet submitters (unless you’re a law firm steeped in the 6-minute charging increment). And at this level, your CFO should realize that any variation is not material to the overall investment and is accepted under GAAP (General Accepted Accounting Principles).<br />
<br />
<h3>
Moving from Team to Train</h3>
On the surface, life gets a little more complex moving from team to train. You have lots of people in supporting roles not necessarily working on specific features. Again, however, it’s not all doom and gloom when you look at prevailing practices.<br />
<br />
In many an IT organization, pre-Agile daily rates attract a “tax” used to cover the costs of those less directly attributable such as management, governance, QA teams and the like. Every project they’ve ever estimated has attracted a percentage surcharge (or a series thereof).<br />
<br />
In the same vein, we can calculate a “burdened run rate” for the teams. We do this by taking the burn rate for every member of the ART not associated with a delivery team, summing them, then distributing them across the team burn rates. In theory, they exist because the teams couldn’t be delivering value without them – so they must be contributing in some fashion. Consider the following example:<br />
<br />
<div class="separator" style="clear: both; text-align: center;">
</div>
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEga4yVQ4cNmvCcETV9FITOCybsFN1asK2Wgvmw2CyLwMF8cWCheUjdACQ1IGB8fZ75yLDN_B972SDyBMLMedmqOlhcC-dIcygwaQHNKbkE-f9zNYNv3eh9ySgXWgbbK45YxZh-vcoukbqTE/s1600/ART+Burn+Rate.JPG" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" data-original-height="424" data-original-width="997" height="136" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEga4yVQ4cNmvCcETV9FITOCybsFN1asK2Wgvmw2CyLwMF8cWCheUjdACQ1IGB8fZ75yLDN_B972SDyBMLMedmqOlhcC-dIcygwaQHNKbkE-f9zNYNv3eh9ySgXWgbbK45YxZh-vcoukbqTE/s320/ART+Burn+Rate.JPG" width="320" /></a></div>
<br />
Support costs can either be distributed proportionally to burn rate or on a flat per team rate (usually based on discussion with Finance). Assuming a flat per team rate, we can restate the example above as:<br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhXgn5oPKrs3wnklzMgvnTvzZGCmEPUCbon3LO3lDUGsfrtr1cVXYet3p9-APM6LQ1tkEd88UjhvZDENkAUCCriNRdmCQdbIdad1DHuI5l-H7fQkvSbyN14EyUDZVw0UijfzjwyjrkMZ0-e/s1600/Burdened+ART+Burn+Rate.JPG" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" data-original-height="326" data-original-width="537" height="194" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhXgn5oPKrs3wnklzMgvnTvzZGCmEPUCbon3LO3lDUGsfrtr1cVXYet3p9-APM6LQ1tkEd88UjhvZDENkAUCCriNRdmCQdbIdad1DHuI5l-H7fQkvSbyN14EyUDZVw0UijfzjwyjrkMZ0-e/s320/Burdened+ART+Burn+Rate.JPG" width="320" /></a></div>
<br />
<div class="separator" style="clear: both; text-align: center;">
</div>
<br />
This becomes more nuanced in the case of a support team who does directly cost attributable work. The classic example is the System Team. They should be spending a certain percentage of their capacity in general support and the rest building enabler features (hopefully DevOps enabler features). In this case, we can use the team-level backlog aggregation approach illustrated above provided we can see their support work clearly categorized so we know which percentage of their cost to distribute to burdened burn rates and which percentage to attribute directly to features.<br />
<br />
All that remains is for our supporting staff to timesheet against a temporary “I worked on this ART WBS”, and we have the means to attribute our costs at the ART level just as we did for the team.<br />
<br />
We get one other thing for free. I like the word "Burdened" when it comes to burn rates. There's usually a world of potential waste to be eradicated in burden costs. Calculating some heuristics allows your CFO to start asking some rather pointed questions about whether ARTs are really "running lean".<br />
<br />
<h3>
Conclusion</h3>
I work with one small client who has none of the “enterprise fiscal responsibilities” of most SAFe implementations. In theory, they have no need for any of the above discipline and in fact ran their early implementation without it. But then they wanted to start analyzing cost/benefit on the features they were building. In fact, it was the delivery folks who wanted to know the answers so they could change up the cost/benefit conversations when feature requests came in.<br />
<br />
I don’t think it matters how “ideally Lean or Agile” you are, if you’re in the type of enterprise using SAFe you will need to be able to allocate your costs across Opex and Capex, and need to analyze your Feature costs to tune your investment strategy and provide data to your improvement initiatives. The techniques illustrated in this article require good backlog discipline and some walking through to get blessing from your Finance departments, but they’re far from rocket science. And best of all, they work regardless of whether you’re project funded, capacity funded, or some combination of the two!<br />
<br />
Because, in the end, I have one experience with Leaning up governance. Until you have a viable alternative that enables the organization to fulfil its fiscal and governance responsibilities you’ll never dislodge the onerous, wasteful practices of the past.<br />
<div>
<br /></div>
Mark Richardshttp://www.blogger.com/profile/12477809828045353101noreply@blogger.com246tag:blogger.com,1999:blog-7030397814607511868.post-15759571529554380542019-02-15T02:41:00.000-08:002019-02-15T02:41:00.777-08:00Dealing with Unplanned and/or BAU work in SAFeIn the Agile world in general, we have long preached the move from “Project mindset” to “Product mindset”. “Wouldn’t the world be simpler if we just talked about work instead of projects and BAU?” is a mantra on many an agilist’s lips. <br />
<br />
Whilst the notion of forming teams and trains that “just do the most important work regardless of its nature” is a great aspiration, it comes with a number of caveats:<br />
<br />
<ul>
<li>Funding and capitalization are generally significantly different for the two</li>
<li>Planning and commitment are difficult when some (or much) of the team’s work is unplanned</li>
</ul>
<br />
Enterprises have typically solved for the problem through structural separation. The first step into Agile is often to move from separate “Plan”, “Build” and “Run” structures to separate “Plan and Build” and “Run” structures. Projects are fed through “Plan and Build”, then after some warranty period transitioned to “Run”. Funding is separate, and “Run” is driven more by SLA’s than plans.<br />
<br />
A truly product-oriented mindset requires the establishment of teams and ARTS that can “Plan,Build and Run”, and this post will tackle in-depth the issue of planning and commitment and introduce some tools for tackling the funding side of the equation.<br />
<br />
<h3>
Funding</h3>
I’ll tackle the topic of funding in greater detail in a future post, but the short version follows. If a backlog item is categorized, the categories can be mapped to funding constructs. We can then take the burn-rate for a team, the percentage of its capacity dedicated to each funding construct, and allocate funding accordingly.<br />
<br />
<h3>
Planning and Commitment</h3>
Both the PI cadence of SAFe and the Sprint cadence of Scrum seem to invalidate the incorporation of BAU. After all, if we fix our Feature priorities for 8-12 weeks in SAFe and our Story priorities for 2 weeks in Scrum how do we deal with the unplanned?<br />
<br />
Known BAU work can be represented by planned backlog items, but the answer to unplanned work lies in the effective utilization of Capacity Allocation. We can reserve a given percentage of the team (or train’s) capacity for unplanned work, and plan and commit based on the remaining capacity. <br />
<br />
<h4>
Team-level Illustration: Production Defects</h4>
One of the first benefits we find with persistent teams is that we can feed production defects back to the team responsible for introducing them. This provides them with valuable feedback, typically dramatically improving quality. <br />
<br />
We might reserve 10% of team capacity to cater for this. Thus, if the team’s velocity is 40 they would only plan to a velocity of 36 and reserve 4 points for production defects. <br />
<br />
Mechanically, the following occurs:<br />
<br />
<ul>
<li>If less than 4 points of production defects arrive, the team pulls forward work from the following sprint.</li>
<li>If more than 4 points of defects arrive, the Product Owner makes an informed decision: defer new feature work or defer low-priority defects.</li>
</ul>
<br />
My preferred implementation of this technique is slightly different. A number of times, we have reserved the 10% for a combination of Production Defects and Innovation. If the team has shipped clean code, they get to work on their innovation ideas rather than pulling forward work!<br />
<br />
<h4>
ART-level illustration: BAU work</h4>
When staffing ARTs, we often find that some (or many) of the key staff are only available “if they bring their BAU work with them”. In these cases, we plan the known BAU work and apply PI-level capacity allocation based on the percentage of their capacity we feel is needed to cater to expected “unplanned BAU” loads and withhold this when planning out the PI.<br />
<br />
Dealing with fluctuations in unplanned work levels at the ART/PI level is a little more consequential. Whilst the sprint-to-sprint mechanism of the production defect illustration still applies, we need to be monitoring for potential impact on PI objectives.<br />
<br />
<ul>
<li>If less than the expected amount of unplanned work arrives for the team, we have the option to either use the spare capacity to absorb work from other teams struggling with their PI objectives or pull forward Features from future PI’s.</li>
<li>If more than the expected amount arrives, we are monitoring impact on committed objectives. We can cater to a certain amount by sacrificing capacity allocated to stretch objectives, but if we are at risk of compromising committed objectives this should trigger a management decision to determine whether to defer or deflect the unplanned work or compromise a committed objective due to the significance of the unplanned work.</li>
</ul>
<br />
<h3>
Discipline is a must</h3>
Applying these techniques will quickly run into a challenge. Teams are often sloppy with BAU/unplanned work. They “just do it”, viewing the effort of creating, sizing and running backlog items for it as unnecessary overhead. This leaves us without the visibility required for the deliberate, proactive decision making illustrated above and often somewhat embarrassingly at the end of the Sprint or PI apologizing for missing a commitment “because BAU was more than expected” without any hard data to back it up and even more importantly without having given the Product Owner/Product Manager/Business Owners the opportunity to intervene and deflect the unplanned work to enable us to maintain the commitment.<br />
<br />
Further, I find most teams dramatically underestimate the capacity consumed by BAU work. We’ve routinely worked with teams who set a capacity of 30% aside for BAU, then when they’ve finally missed enough objectives to buy into actually tracking their BAU work find it to be 50-60%. <br />
<br />
However, the true benefit of discipline goes further – the data generated is a goldmine.<br />
<h3>
<br /></h3>
<h3>
Reaping the Benefit of Discipline</h3>
Whilst the first benefit of discipline is obviously that of gaining an accurate understanding of your capacity and being able to more confidently make and keep commitments, exponential gains can be realized once you start to analyze the data generated. A key first step is developing an awareness of failure demand and value demand.<br />
<br />
<h4>
Failure Demand vs Value Demand</h4>
<blockquote class="tr_bq">
“<i>Failure demand is demand caused by a failure to do something or do something right for the customer</i>” – John Seddon</blockquote>
The first illustration that was given to me for failure demand many years ago was in the context of call centers. It’s the 2nd and 3rd phone call you have to make because your issue wasn’t fully resolved on the first call. If we take a typical agile team or ART, we can find many examples:<br />
<br />
<ul>
<li>A late-phase defect is caused by failure to “build quality in”.</li>
<li>A production defect is caused by failure to deploy a quality product</li>
<li>A request for information is caused by failure to have provided that information previously or failure to have made the requester aware of where the information is published</li>
<li>An issue is often caused by failure to effectively mitigate a risk</li>
<li>Time spent issuing reminders or nagging is failure demand, as more effectively establishing the awareness of the “why” and clearly setting the expectation would have avoided it.</li>
<li>Managing the politics of a missed commitment results from both failure to meet the commitment and failure to effectively manage the possibility that the commitment would be compromised.</li>
</ul>
<br />
<blockquote class="tr_bq">
“<i>Value demands are demands from customers that we ‘want’, the reason we are in business</i>” – John Seddon</blockquote>
Value demand for teams and ARTs should be obvious – the features and stories the teams are working on! However, this can become a little more nuanced very quickly:<br />
<br />
<ul>
<li>Is work done on an improvement initiative value demand? Our customer probably didn’t directly ask for it. In fact, many improvement initiatives are effectively failure demand as they are driven by addressing previous failures.</li>
<li>A great deal of BAU/Unplanned work is falsely perceived as value demand. “I run this script or extract every morning”, “We produce and consolidate this report every month” are all great examples. In theory someone values the result of the script or extract, and values the report – but the need to dedicate capacity to it results from a failure to automate it, or failure to fix a broken process.</li>
</ul>
<br />
<h3>
Applying the Insights from Demand Patterns</h3>
Assuming we’ve had the discipline to channel all demand on a team through their backlog, and the further discipline to categorize it appropriately as failure or value demand, we can now start to drive significant improvement on the following basis:<br />
<br />
<ul>
<li>If I reduce failure demand, I have more capacity to devote to value demand</li>
<li>If I find a more effective way to respond to value demand, I have more capacity to devote to value demand</li>
</ul>
<br />
In “<a href="https://www.amazon.com/Four-Types-Problems-Art-Smalley/dp/193410955X/ref=sr_1_1?keywords=four+types+of+problem&qid=1550226278&s=gateway&sr=8-1" target="_blank">Four Types of Problems: from reactive troubleshooting to creative innovation</a>”, Lean expert Art Smalley defines a hierarchy of problem types and accompanying resolution strategies. Three of these are pertinent to this situation:<br />
<br />
<ul>
<li><b>Type 1: Troubleshooting</b> – “<i>Reactive problem solving based upon quick responses to immediate symptoms</i>”.</li>
<li><b>Type 2: Gap from Standard</b> – “<i>Structured problem solving focused on problem definition, goal setting, root causes analysis, counter-measures, checks, standards and follow-up activities</i>”</li>
<li><b>Type 3: Target Condition</b> – “<i>Continuous improvement that goes beyond existing performance of a stable process or value stream. It seeks to eliminate waste, overburden, unevenness, and other concerns systemically, rather than responding to one specific problem</i>”.</li>
</ul>
<br />
When you form a good Agile team, their ability to jump to each other’s aid, rally around problems and move from individual work to teamwork tends to exhibit a lot of troubleshooting – particularly in the case of unplanned work. Good troubleshooting skills are fundamental to any team. As Smalley comments, “<i>to address each [issue] with a deeper root cause problem-solving approach would require tracking and managing a problem list that runs, literally, hundreds of miles long. No organization can hold that many problem-solving meetings … in an efficient manner</i>”.<br />
<br />
Our response to most failure demand is to apply troubleshooting techniques. However, while these will help us survive the prevailing conditions they won’t help us change them. Change requires the use of Type 2 problem solving techniques. We need to leverage our data to identify recurring trends, and act to remove the root cause of the failure demand. Smalley devotes great attention to problem definition, and opens with two pieces of critical advice when framing the problem for attention:<br />
<br />
<ul>
<li><i>“The first step is to clarify the initial problem background using facts and data to depict the gap between how things should be (current standard) versus how they actually are (current state).</i></li>
<li><i>“Why does this problem deserve time and resources? How does it relate to organizational priorities? Strive to show why the problem matters or else people might not pay attention or might question the problem-solving effort.”</i></li>
</ul>
<br />
As we are successful with the reduction of failure demand with our Type 2 activities, we can move on to Type 3 problem solving, driving activity to establish new target conditions. If we accurately understand the capacity being devoted to various types of value demand we can more accurately assess whether the value being generated justifies the capacity being consumed – triggering informed continuous improvement. An enterprise PMO we have been working with provided a wonderful example recently:<br />
<br />
They had historically applied a QA process to every project the organization ran. This, of course, was characterized as “BAU” work. It had to be done every time a project passed through a particular phase in lifecycle. As they gathered data on how much of their capacity it actually consumed, they started to question the value proposition. How regularly did the QA check actually expose an issue? What were the typical consequences of the issues exposed? What other high-value discretionary activities were unable to proceed due to capacity constraints? Eventually, they were able to make an informed decision to move to a sampling approach, freeing up more capacity to devote to high-value initiatives they had been frustrated by an inability to proceed with.<br />
<br />
<h3>
Conclusion</h3>
Capacity allocation allows us to deal with BAU/Unplanned work, but my experience has been that it never works well without the accompanying discipline of actually channeling that work formally through your backlog. It might require some creativity to make it meaningful (eg a single backlog item for the sprint representing the capacity devoted to a daily BAU activity). Beginning with the reduction of failure demand in BAU/Unplanned work will both improve performance and free capacity which can then be devoted to true continuous improvement initiatives.<br />
<br />
However, the usefulness of the Sprint or PI cadence-driven cycle seems to fall apart at the point where more than 30-40% of capacity is being reserved for unplanned work. Some form of cadence-driven alignment cycle will always be valuable, but adaptation from the standard events and agendas will be necessary to make them meaningful and Kanban is far more likely to provide a useful lifecycle model. The ARTs I have worked with in this situation have tended to wind up with shortened planning events far more focused on “priority alignment” than detailed planning.<br />
<br />
Above all, the benefit comes from the mindfulness generated in the presence of data reflecting “where you really spend your time” as opposed to “what your value priorities are”, and the accompanying discipline of acting on that data to achieve better alignment.<br />
<div>
<br /></div>
Mark Richardshttp://www.blogger.com/profile/12477809828045353101noreply@blogger.com56tag:blogger.com,1999:blog-7030397814607511868.post-35165523080231964662018-10-27T23:24:00.000-07:002018-10-27T23:27:11.553-07:00Unleash your ART with the right Business OwnersFor years, I wondered why Dean Leffingwell had to use another name for stakeholders with the "Business Owner" construct in SAFe. My description in training used to run "an ART will have many stakeholders, but somewhere will be the 4-6 whose support is critical to your success - they're your Business Owners".<br />
<br />
At some point it dawned on me. If you consider the size of investment involved in running an Agile Release Train, under any legacy delivery model there would have been some form of executive steering committee. Through this lens, you are offering the ART Business Owner construct as a Lean|Agile alternative to the traditional steering committee.<br />
<br />
I have been rewarded by deliberate focus on formalizing the Business Owner construct. It has unlocked one of the key decentralization puzzles I have encountered in my years with SAFe. At some point in the journey of envisioning an ART, you are looking for a Product Manager. A single person with a huge amount of delegated responsibility as the strategic voice of the customer. Finding that one person the enterprise agrees can effectively represent all the competing interests for the ART's strategy and capacity can be almost impossible. The problem also rears its head for the Release Train Engineer (RTE). Most ARTs will be working on multiple strategic assets with a diverse ownership throughout the IT organisation - owners who often have significant concerns about others working on their platforms.<br />
<br />
I have come to think of the RTE and Product Manager as empowered delegates of the Business Owners for the ART. The Business Owners are then collectively accountable for rapid response to any decision escalated to them. When these 2 layers of leadership operate effectively together, magic happens.<br />
<br />
<h3>
When and How to select Business Owners</h3>
The journey of an ART begins with leadership training and a vision workshop. We are looking for a group of leaders and stakeholders collectively aligned in their understanding of the framework and with a shared vision for what the ART will be.<br />
<br />
It is ideal for Business Owners to be a part of this early journey, so the time to map candidate business owners is when you're determining the attendees for the Leading SAFe and the vision workshop.<br />
<br />
When selecting business owner candidates, an overall stakeholder map can be a useful input. You need 2 types of representative:<br />
<br />
<ul>
<li>Business Stakeholders</li>
<ul>
<li>The owners of the operational value stream(s) the ART will service</li>
<li>Stakeholders with policy, regulatory or other assurance concerns in relation to the ART's mission</li>
<li>Owners of funding (if not covered above)</li>
</ul>
<li>Technology Stakeholders</li>
<ul>
<li>Designated owners of Strategic Technology Assets the ART will impact</li>
<li>Line Managers of staff the ART is likely to recruit</li>
</ul>
</ul>
<br />
<h3>
What level executive?</h3>
If you look too junior for your Business Owners, they won't have the teeth to fulfil their mission. Conversely, looking too senior will give you authority but is unlikely to yield the time commitments you will be pursuing.<br />
<br />
Whilst most organisations have their own leadership hierarchy, I find the sweet spot in large organisations is "the most junior level still considered to be an executive" - just above the line where senior middle management begins. Considering this to be a "level one exec", I take one extra step - find the level 2 exec in that area and seek a nominated delegate.<br />
<br />
<h3>
How many do I want?</h3>
There is no set answer to how many Business Owners an ART should have, but I have some rules of thumb based on experience. A number of times two were nominated - the Business Sponsor and the Technology Owner. These struggled, partially due to a lack of diversity of voice and nearly always because the Business Sponsor had numerous peers who had interests they did not feel the sponsor adequately represented.<br />
<br />
So, I worry if I see less than 4 Business Owners. On the other hand, too many is also a huge problem. It's incredibly difficult to reach and maintain alignment and move on critical decisions with a large and unfocused group. I once had the misfortune of trying to facilitate an ART vision workshop with 30 candidate Business Owners and convergence was near impossible.<br />
<br />
You want enough to be appropriately representative (usually at least 4) and not so many you'll struggle to make decisions (usually painful to move beyond 8-10).<br />
<br />
<h3>
The importance of setting expectations</h3>
Your prospective executive business owners need to understand what comes with the job. As a collective the organisation is making them accountable for fiscal oversight and executive championing of the ART's mission.<br />
<br />
They will attend and actively participate in a number of SAFe events, with a not inconsiderable accompanying time investment. They will be needed for at least the following:<br />
<br />
<ul>
<li>Participation in the ART vision workshop</li>
<li>Participation in the Program Backlog prioritisation workshop(s) each PI</li>
<li>Attendance at PI planning, validation and acceptance of objectives and participation in the management review</li>
<li>Attendance at System Demos (as part of their oversight obligations)</li>
<li>Attendance at and participation in Inspect and Adapt</li>
<li>Periodic participation in governance and escalation workshops with respect to ART performance.</li>
<li>Being the 'voice of the ART' in their area of the business.</li>
</ul>
<br />
<br />
They will need to understand the purpose of each of these, their role, and the ensuing time commitments.<br />
<br />
I believe the position of Business Owner on an ART should be formally nominated and accepted, and would go so far as to suggest formalising a Terms of Reference for the Business Owner committee.<br />
<br />
<h3>
Leveraging your Business Owners</h3>
The primary times your train and Business Owners will intersect will be through the afore-mentioned SAFe events. Following are some of the patterns I have found beneficial.<br />
<br />
<h4>
The ART Vision Workshop</h4>
Every ART should start with a clear vision, and this is the workshop that first crystalizes it (documented <a href="http://www.agilenotanarchy.com/2017/04/facilitating-release-train-design-with.html" target="_blank">here</a>). Agreement is reached on Customers, Success Measures, Vision Statements and the nature of the solution to be built and the business owner roles are confirmed. As the executive owners of the ART, it is critical not only that the business owners have a voice in shaping the vision but that clarity and alignment is reached on how the ART's success will be measured.<br />
<br />
<h4>
Program Backlog Prioritisation Workshops </h4>
In preparation for this workshop, the Product Manager has been decomposing Epics, talking to customers, and reflecting on learning from shipped features to identify and shape a set of candidate features to add to the Program Backlog. Each feature has a value proposition, and in SAFe we use a contextualised Cost of Delay (COD) estimation and the Weighted Shortest Job First algorhythm to arrive at economic priorities.<br />
<br />
In this workshop, new features are evaluated to determine their COD and existing backlog features where conditions might have changed are re-assessed. Based on known information about feature value proposition, Business Owners use agile estimation to come into alignment on the cost of delay. This enables the Product Manager to fulfil their responsibility to maintain an economically prioritised backlog whilst leveraging the diversity and organisational authority of the business owners to make the assessments.<br />
<br />
<h4>
PI Planning</h4>
Little needs to be added to existing material in this space. Business Owners have a critical role to play both interacting with teams on an adhoc basis and in a planned fashion through plan reviews and the management review. The PI Planning event provides amazing "Gemba time" for executives, with much to be learned by observing and interacting as the teams build their plans.<br />
<br />
The event commences with a set of priorities that have been validated and endorsed by the business owners. By the end of day 1, there will be various challenges to that vision. Regularly, hard decisions will need to be made, and made on the night. Management Review provides the forum to revisit their earlier "value proposition discussion" in the light of emerging information and provide rapid response with the same set of authority as drove the initial priorities.<br />
<br />
On the second day, the all-important "Business Owner walk-around" occurs. The Business Owners visit each team and conduct a review and assessment of the PI objectives. It both establishes direct executive/team engagement and feedback, and permits clarification of objective intent - maximising the chance both the team and their stakeholders leave the room aligned in their commitment expectations.<br />
<br />
<h4>
System Demo</h4>
The primary "Execution reporting" vehicle for the ART culturally is the System Demo. Every 2 weeks, it provides a transparent checkpoint based on demonstrated functionality and linkage back to PI objectives. It also acts as a platform for feedback. As implementations are demonstrated, where they differ from the vision of the business owner or expose new challenges or insights this is the forum to both trigger and receive that feedback.<br />
<br />
<h4>
Inspect and Adapt</h4>
Business Owners have a role to play in all 3 phases of the Inspect and Adapt workshop. During the PI Demo, they are gaining an understanding of "what has been achieved" in the PI with reference back to the objectives committed at PI Planning. During the quantitative measurement phase, they are both reviewing ART PI Metrics and evaluating performance of teams against their committed objectives based on the Demo.<br />
<br />
Finally, during the problem solving workshop they provide the all-important executive lens to root cause analysis and brainstorming. It provides them with invaluable time "at the Gemba", and insights into enabling initiatives that should be prioritised.<br />
<br />
<h4>
Governance</h4>
Each of the SAFe events described above qualifies as a governance event. Collectively, they enable the Business Owners to steer ART strategy, provide rapid decision-making response at key moments in the lifecycle and maintain visibility through System Demos and Inspect and Adapt.<br />
<br />
However, it is also typical to establish some form of cadence-based "ART Steering" forum. In previous versions of SAFe this was known as "Release Management", but I suspect it has receded from visibility in the framework due to confusion over the title. A monitoring and escalation forum needs to exist for the ART during PI execution. It is informed by the standard SAFe events, but facilitates monitoring and follow-through of the various risks and issues that emerge.<br />
<br />
<h4>
Enabling</h4>
To succeed in mission, the ART will need to collaborate across the organisation - particularly for exploration activities. Business Owners provide a built-in channel of access to the areas that will typically be critical. Through their understanding of the focus areas for the ART, they can proactively plan who from their areas should be involved and how.<br />
<br />
<h3>
Conclusion</h3>
I have become so convinced of the power of a well-identified, engaged group of Business Owners that it is one of my top priorities when shaping a potential ART these days. I have found it to be a hugely critical key in unlocking empowerment and ability to move for Product Managers and Release Train Engineers, whilst providing the Business Owners a great sense of comfort in the level of insight and input they have.<br />
<div>
<br /></div>
Mark Richardshttp://www.blogger.com/profile/12477809828045353101noreply@blogger.com327tag:blogger.com,1999:blog-7030397814607511868.post-53113731496921669592018-01-08T04:42:00.000-08:002018-01-08T04:42:21.150-08:00Effective Feature Templates for SAFe<h3>
Introduction</h3>
Features are the key vehicle for value flow in SAFe, yet they are also the source of much confusion amongst those implementing it. The framework specifies that “Each feature includes a Benefit Hypothesis and acceptance criteria, and is sized or split as necessary to be delivered by a single Agile Release Train (ART) in a Program Increment (PI)”.<br />
<br />
It is obvious that you need a little more information about the feature, and on what feels like countless occasions I have facilitated the definition of a Feature Template with a Product Management group. People in classes ask me for a sample, and of course the only samples I have belong to my clients and aren’t mine to share.<br />
<br />
The new emphasis on Lean UX in SAFe 4.5 finally inspired me to put some time into crafting a Feature Template of my own that I could share. The result is a synthesis of recurring patterns I have observed in my coaching, and focuses an “essential components” with guidance on additional information that might be required.<br />
<div>
<br /></div>
<div>
<h3>
How much detail is needed, and by when?</h3>
<div>
I divide the refinement lifecycle of the Feature into two phases. </div>
<div>
<ul>
<li>Prior to WSJF assessment</li>
<li>Prior to PI Planning</li>
</ul>
</div>
<div>
There is a level of detail required for a feature to enable Cost of Delay and sizing assessment. Information is inventory, and we want a lightweight holding pattern until the Feature’s priorities indicate it as needing to be prepared for PI planning.</div>
<div>
<br /></div>
<div>
To this end, my template focuses on taking a canvas approach to supporting WSJF assessment, and I provide some guidance on likely extensions of detail in readiness for PI Planning.</div>
</div>
<div>
<br /></div>
<h3>
Feature Canvas</h3>
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjJ9d97yFO6_nJsEq1o5fXOfc0xuu6f6QKuMadOzCIGIg3Xxxfkbx8tEkkjTdZeB2j-x8r2zXkd8hufg27-Cwn_zoUHV17AWSMug1ZFaMr_MxunmLviH4ceDssgkOqX5YAAAJwyLL1fFeOs/s1600/Blank+Feature+Canvas.jpg" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" data-original-height="913" data-original-width="1600" height="364" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjJ9d97yFO6_nJsEq1o5fXOfc0xuu6f6QKuMadOzCIGIg3Xxxfkbx8tEkkjTdZeB2j-x8r2zXkd8hufg27-Cwn_zoUHV17AWSMug1ZFaMr_MxunmLviH4ceDssgkOqX5YAAAJwyLL1fFeOs/s640/Blank+Feature+Canvas.jpg" width="640" /></a></div>
<div>
<br /></div>
<div>
<b>Problem Statement</b></div>
<div>
Leveraging the work of Jeff Gothelf in Lean UX, we base the feature on a definition of the problem it is designed to address. Gothelf provides two excellent template statements here:</div>
<div>
<br /></div>
<blockquote class="tr_bq">
<b>New Product:</b><br /><i>“The current state of the [domain] has focussed primarily on [customer segments, pain points, etc].<br />What existing products/services fail to address is [this gap]<br />Our product/service will address this gap by [vision/strategy]<br />Our initial focus will be [this segment]”</i></blockquote>
<blockquote class="tr_bq">
<b>Existing Product:</b><br /><i>“Our [service/product] is intended to achieve [these goals].<br />We have observed that the [product/service] isn’t meeting [these goals] which is causing [this adverse effect] to our business.<br />How might we improve [service/product] so that our customers are more successful based on [these measurable criteria]?”</i></blockquote>
<div>
<div>
<b>Feature Hypothesis</b></div>
<div>
Again, leveraging Gothelf’s work we form a hypothesis as to the impact our Feature might achieve. The template takes the form:</div>
<blockquote class="tr_bq">
<i>“We believe this [business outcome] will be achieved if [these users] successfully achieve [this user outcome] with [this feature]”.</i></blockquote>
<div>
<b>Objectives and Key Results (OKRs)</b></div>
<div>
Features are intended to provide verifiable impact, this detail is critical to enabling effective Cost of Delay estimation and the post-deployment verification of impact. We want to ensure that quantifiable movement of identified Leading Indicators supports the ongoing evolution of our Product Management strategy.</div>
<div>
<br /></div>
<div>
As previously documented in <a href="http://www.agilenotanarchy.com/2017/03/improving-safe-product-management.html" target="_blank">this post</a>, I have become quite a fan of the OKR model initiated at Intel and popularized by Google and find this a useful discipline in defining feature impacts. </div>
<div>
<br /></div>
<div>
If OKRs seem a little daunting, you would instead list Leading Indicators and expected movements in this section.</div>
<div>
<br /></div>
<div>
<b>Cost of Delay Components</b></div>
<div>
The effectiveness/objectivity of Cost of Delay estimation workshops is heavily driven by the data on the table. The 3 sections for User/Business Value, Timing Criticality and Risk Reduction/Opportunity Enablement provide opportunity to highlight supporting data for the assessment of the three cost of delay components.</div>
<div>
<br /></div>
<div>
<b>Key Subject Matter experts</b></div>
<div>
I rarely if ever work with an ART where Product Management is self-sufficient with their domain expertise. Deliberate identification of and engagement with subject matter experts early in the lifecycle of a feature is critical.</div>
<div>
<br /></div>
<div>
<b>External Dependencies</b></div>
<div>
Nothing brings a feature unstuck faster than unidentified external dependencies. These should be flushed early, and inform prioritization and roadmapping discussions.</div>
<div>
<br /></div>
<div>
<b>Non Functional Requirements</b></div>
<div>
We know that an ART will have a standing set of non functional requirements that applies to all features, but occasionally features come with specific NFR’s. </div>
</div>
<div>
<br /></div>
<div>
<h4>
Sample Completed Canvas</h4>
<div>
It was incredibly difficult to invent a sample feature because my head kept running to real features, but eventually I settled on a fictitious feature for restaurant reservations.</div>
</div>
<div>
<br /></div>
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjJaH4iLonQbfJGBc4tsMkt7JGvIPe0MCtwjJD_5qytTEp30fWqyPFDdlnBhHCFHoLK9Ewqlr4ZW4n-weyHasFra9G7hNjRGfOrw9_EhhRQTOfkROXQ_fvDGSxw93OhUt6MJchKIJdNuK0u/s1600/Sample+Feature+Canvas.jpg" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" data-original-height="913" data-original-width="1600" height="364" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjJaH4iLonQbfJGBc4tsMkt7JGvIPe0MCtwjJD_5qytTEp30fWqyPFDdlnBhHCFHoLK9Ewqlr4ZW4n-weyHasFra9G7hNjRGfOrw9_EhhRQTOfkROXQ_fvDGSxw93OhUt6MJchKIJdNuK0u/s640/Sample+Feature+Canvas.jpg" width="640" /></a></div>
<div>
<br /></div>
<h4>
A glimpse at how you might visualise your next WSJF estimation workshop</h4>
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgViZeuooE-zLcjwDXWlzIygtt6czHzJgAneQV-35wiKavCHQut_IH30FhH62fZfM0-aJFhxffqP0GmM5srvoAKJ2R7r-R9eUs_kTwrw8K0DSe5HUmYH3fFf5YqV2ZdIhMdcNA7M8UJXTpF/s1600/WSJF+Session+Visualisation.jpg" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" data-original-height="299" data-original-width="606" height="314" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgViZeuooE-zLcjwDXWlzIygtt6czHzJgAneQV-35wiKavCHQut_IH30FhH62fZfM0-aJFhxffqP0GmM5srvoAKJ2R7r-R9eUs_kTwrw8K0DSe5HUmYH3fFf5YqV2ZdIhMdcNA7M8UJXTpF/s640/WSJF+Session+Visualisation.jpg" width="640" /></a></div>
<div>
<br /></div>
<div>
<h3>
Detail beyond the Canvas</h3>
<div>
As a feature is selected as a candidate for an upcoming PI, it triggers the collection of additional framing detail. How much or how little detail is appropriate tends to vary ART by ART and at different stages in their evolution. </div>
<div>
<br /></div>
<div>
At a minimum, it will require acceptance criteria. However, some other things to consider would include:</div>
<div>
<ul>
<li>User Journeys: Some framing UX exploration is often very useful in preparing a Feature, and makes a great support to teams during PI planning. </li>
<li>Architectural Impact Assessment: Some form of deliberate architectural consideration of the potential impact of the feature is critical in most complex environments. It should rarely be more than a page – I find a common approach is one to two paragraphs of text accompanied by a high level sequence diagram identifying expected interactions between architectural layers.</li>
<li>Change Management Impacts: How do we get from deployed software to realised value? Who will need training? Are Work Instructions required? </li>
</ul>
</div>
<div>
<br /></div>
<h3>
Tuning your Template</h3>
<div>
Virtually every ART I have worked with has oscillated between “too much up-front information” and “not enough up-front information”. You want to know enough to enable teams and product owners to effectively plan and execute iteratively, yet not so much that you constrain the opportunity for teams and product owners to innovate and take ownership of their interpretation.</div>
<div>
<br /></div>
<div>
Every PI is a learning opportunity. Take stock a week after PI planning and look at both the information you wished you’d had, and your observations as to the value proposition of the information you had provided. </div>
<div>
<br /></div>
<div>
Then, take stock again late in the PI. Look at how the features played out over the PI, and the moments you wish you could have avoided 😊 </div>
<div>
<br /></div>
<h3>
Who completes the Canvas/Template?</h3>
<div>
The Product Manager is the content authority at the Program Backlog level, hence they are the ultimate owners. However, one of the nice influences Lean UX has brought to SAFe 4.5 is a real emphasis of “collaborative design”. In avoiding the waste of knowledge handoff, the best people to work through the majority of the detail (including preparing the canvas itself) are the product owners and teams likely to be implementing the feature.</div>
</div>
<div>
<br /></div>
<div>
<blockquote class="tr_bq">
</blockquote>
<blockquote class="tr_bq">
</blockquote>
</div>
Mark Richardshttp://www.blogger.com/profile/12477809828045353101noreply@blogger.com29tag:blogger.com,1999:blog-7030397814607511868.post-83682753913514506432017-07-07T01:13:00.000-07:002017-07-09T18:38:10.297-07:00Facilitating Release Train Design with the ART Canvas Part 3 - Launch PlanningFollowing a hectic couple of months launching four new ARTS, its time to conclude my three-part series on facilitating Release Train design with the ART Canvas. Covering the facilitation of a 1-day workshop, the previous posts dealt with <a href="http://www.agilenotanarchy.com/2017/04/facilitating-release-train-design-with.html" target="_blank">creation of a shared ART Vision</a> <a href="http://www.agilenotanarchy.com/2017/04/facilitating-release-train-design-with_23.html" target="_blank">accompanied by a supporting design</a>. In this conclusion, I tackle the closing session of the day: the preparation of a launch plan. <br />
<br />
Before commencing the launch planning, we generally shrink the audience. We release the stakeholders who were critical to establishing a shared vision and design, and bring our focus in to the leadership team who will be executing the launch preparation activities.<br />
<br />
Agile is a team sport, and the ART is intended to be a self-organizing team of agile teams. So, your leadership team needs to work as an agile team too! The vision workshop is essentially a team formation activity for the leaders, who then have the chance to operate as an agile team as they prepare for the launch.<br />
<br />
Since our final objective for the workshop is to generate a launch plan, the metaphor that makes most sense is that of a short “enablement PI” which is executed by the leadership team with the support of the product owners. Thus, the final segment of the workshop is a mini PI Planning. I open with the following challenge objective for their enablement PI:<br />
<br />
<blockquote class="tr_bq">
<i>“Your product is an Agile Release Train that can fulfil the vision we’ve defined here today. 8 weeks from now (or whatever launch date we’ve set), 150 people are going to walk into a room to spend 2 days in their first PI Planning. What will make this a success?”</i></blockquote>
To assist them in their planning, I then distribute the following Features before sending them into breakouts to create a set of stories and objectives that will realize the objective:<br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgCQqHG9xyYWbgUo51YVmHYu90lEuxCedjmO6iTymfEtabw7tjgQtjqMXqNLUYV9cNhnKl-YMCyHF1YTeCCAbdtyS-DgN0EWvvPalkJ77Lh8FIpnmPgcxEzs9jnZs4t63cy_tRgdOMXx-nu/s1600/Launch+Feature+-+Program+Backlog.JPG" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" data-original-height="817" data-original-width="1502" height="347" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgCQqHG9xyYWbgUo51YVmHYu90lEuxCedjmO6iTymfEtabw7tjgQtjqMXqNLUYV9cNhnKl-YMCyHF1YTeCCAbdtyS-DgN0EWvvPalkJ77Lh8FIpnmPgcxEzs9jnZs4t63cy_tRgdOMXx-nu/s640/Launch+Feature+-+Program+Backlog.JPG" width="640" /></a></div>
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhPhs3prcvfN-s5d48nHiu5JG9VWqgtfeRcNNf0r40O8ssrv-hR_T5scwYpIaY0Cq7xdBMh5No6J9Gxdw2mEXSPdnk8uTsWMfrpuJ2nx1dw0lRgZ2ftJMCZkJLHWKjth5vA18_0wJ1_tiPA/s1600/Launch+Feature+-+Training+Enablement.JPG" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" data-original-height="832" data-original-width="1529" height="348" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhPhs3prcvfN-s5d48nHiu5JG9VWqgtfeRcNNf0r40O8ssrv-hR_T5scwYpIaY0Cq7xdBMh5No6J9Gxdw2mEXSPdnk8uTsWMfrpuJ2nx1dw0lRgZ2ftJMCZkJLHWKjth5vA18_0wJ1_tiPA/s640/Launch+Feature+-+Training+Enablement.JPG" width="640" /></a></div>
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgihPZCyDR3Zz_8xRAL8lv88RL88LnPJQZRsHGvVVDyUOowg9ZfuEOiGKkNyiaCB0BPWB5Rz2K2X10BI7lA50dUgr18IfkWsKoC0btQQ7ae10WC1ZYEAKLt-PcdwmiveciBxYI-WP-FBvcP/s1600/Launch+Feature+-+ART+Staffing.JPG" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" data-original-height="822" data-original-width="1517" height="346" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgihPZCyDR3Zz_8xRAL8lv88RL88LnPJQZRsHGvVVDyUOowg9ZfuEOiGKkNyiaCB0BPWB5Rz2K2X10BI7lA50dUgr18IfkWsKoC0btQQ7ae10WC1ZYEAKLt-PcdwmiveciBxYI-WP-FBvcP/s640/Launch+Feature+-+ART+Staffing.JPG" width="640" /></a></div>
<div class="separator" style="clear: both; text-align: center;">
<br /></div>
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhHUnbKZcEgrv3rb1RL2jeC7Au8ii7eoQS3Phu05EOCJdpqykF7qZeTQq1JiCJWd8FMtO2Gdc_qGjXDQUiTIOvzJtEC8ISSOjPnUMoVKcrljIW5DQv9OszWb0W0f-xnA0LF-uG__b2CiU-m/s1600/Launch+Feature+-+System+Team.JPG" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" data-original-height="825" data-original-width="1520" height="346" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhHUnbKZcEgrv3rb1RL2jeC7Au8ii7eoQS3Phu05EOCJdpqykF7qZeTQq1JiCJWd8FMtO2Gdc_qGjXDQUiTIOvzJtEC8ISSOjPnUMoVKcrljIW5DQv9OszWb0W0f-xnA0LF-uG__b2CiU-m/s640/Launch+Feature+-+System+Team.JPG" width="640" /></a></div>
<br />
<div class="separator" style="clear: both; text-align: center;">
</div>
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEi7Lb8HvzIlaRoQgCnkMBa8Y_IidApDed-hzSi75QLHjiQr9Zhl6VAlU1xhX35Jnxc2JXrzcI7G86qlrF4FVuQhWwJLffVulM84YDfzp31EXnEDHGPDruqnw40lAvovqP3D9skhOWzYJ7mK/s1600/Launch+Feature+-+Logistics.JPG" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" data-original-height="826" data-original-width="1518" height="348" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEi7Lb8HvzIlaRoQgCnkMBa8Y_IidApDed-hzSi75QLHjiQr9Zhl6VAlU1xhX35Jnxc2JXrzcI7G86qlrF4FVuQhWwJLffVulM84YDfzp31EXnEDHGPDruqnw40lAvovqP3D9skhOWzYJ7mK/s640/Launch+Feature+-+Logistics.JPG" width="640" /></a></div>
<br />
<br />
The depth to which the plan is developed depends on our time-boxing. I’ve generally run this workshop over the course of a single day, which means their set of stories and backlog will be very rudimentary given the constrained time-box they will have for breakouts. I have increasingly become tempted to extend it to a second day, allowing time to create a more effective plan, establish PI objectives, identify dependencies and create a Program Board. This would also allow some time on the 2nd day to work through some team formation activities with the Leadership Team such as:<br />
<br />
<ul>
<li>Development of a social contract</li>
<li>Design of the team Kanban</li>
<li>Planning of team demo approach (the team should be demonstrating back to stakeholders on launch preparation progress)</li>
<li>Agreement on standup timing</li>
<li>Iteration planning for the first iteration</li>
</ul>
<br />
<h3>
Closing the session</h3>
In closing, we should have the following outcomes:<br />
<br />
<ul>
<li>A name and launch date for the ART</li>
<li>A completed ART canvas, ready to be hung on a wall (and eventually digitised)</li>
<li>An agreement for the newly formed ART leadership team to function as an agile team during the launch preparation</li>
<li>An appropriately scary launch preparation backlog that motivates movement by the leadership team and is accompanied by an agreed “Agile monitoring” process using Team Demos to enable progress transparency and feedback. </li>
</ul>
<br />
I like to close out with a final check-in. I love the definition of consensus Jean Tabaka taught me: “I can live with that, and support it”. It’s a great way to bring a day of very hard work to a close, perhaps using a roman vote. “We’ve formed a vision, an ART design and a plan today. There’s a lot of hard work ahead of us but I’d like to check that we have achieved consensus before we leave this room.”<br />
<div>
<br /></div>
<br />
<div>
<br /></div>
Mark Richardshttp://www.blogger.com/profile/12477809828045353101noreply@blogger.com9tag:blogger.com,1999:blog-7030397814607511868.post-68386424706750577102017-06-11T10:36:00.002-07:002017-06-11T10:36:41.340-07:00Reflecting on the 2017 SAFe Leadership RetreatEarlier this week, I spent a few days at the very picturesque Dalmahoy Hotel in Edinburgh attending the 2017 SAFe Leadership Retreat. This was our 3rd gathering, having travelled to Banff (Canada) in 2016 and Crieff (Scotland) in 2015.<br />
<br />
If I had to describe the retreat in one word, it would be “community”. Given the general application of SAFe in large enterprise and the prevailing “partner consultancy” based model, creation of an environment where both consultants and practitioners come together to transcend boundaries and share is no mean feat. Full credit must go to <a class="g-profile" href="https://plus.google.com/110982072426312732934" target="_blank">+Martin Burns</a> and his better half Lucy for their tireless efforts in this regard.<br />
<br />
As always, the retreat was attended by <a class="g-profile" href="https://plus.google.com/111678440224086860538" target="_blank">+Dean Leffingwell</a> along with a number of other representatives from SAI. Also in attendance were a mix of SAFe Fellows, SPCTs, consultants and practitioners along with a “chaos monkey” in the form of <a class="g-profile" href="https://plus.google.com/104205134740204626607" target="_blank">+Simon Wardley</a>.<br />
<br />
Having now had a few days to reflect on the experience, I’d like to share some of the key themes that emerged.<br />
<br />
<h3>
SAFe “next”</h3>
In the opening session, Dean spent a couple of hours running us through the soon-to-be-released next version of SAFe. Whilst we’re under NDA when it comes to specifics, I can say that the changes were enthusiastically received – with much improved guidance in some critical areas and best of all for the first time ever a simpler big picture!<br />
<br />
<h3>
SAFe beyond technology</h3>
Whilst the framework is squarely focused on the HW/FW/SW side of “Lean Product Development”, those with a truly lean mindset know that there’s a lot more than technology involved in the creation of a Lean Enterprise and optimization of the flow from Idea to Value. I’ve long held the belief that great ARTs extend beyond technology into Sales, Marketing, Business Enablement and Business Change Management and it was great to see many others not just talking about this but doing it.<br />
<br />
<h3>
HR as an enabler rather than an impediment in a Lean-Agile transformation</h3>
We were lucky to have a number of attendees who were either practicing HR professionals or came from an HR background, and numerous open-space sessions devoted considerable attention to Lean|Agile and the world of HR. Whilst <a href="http://www.scaledagileframework.com/agile-hr-with-safe/" target="_blank">Fabiola Eyholzer’s guidance article</a> last year made a great start on this front, many are grappling with the practical realities of such questions as how to address career progression in the ScrumMaster/RTE and Product Manager/Owner spaces. Hopefully in the coming months we’ll see some of the outcomes of those discussions synthesized and in the public domain.<br />
<br />
<h3>
SAFe for Systems of Record</h3>
When it comes to true Business Agility, there are always Systems of Record involved. A number of sessions and discussions focused on this, with a particularly robust session on SAP. The general conclusion was that whilst it’s a lot more convoluted than digital, many are doing it successfully and common patterns are emerging.<br />
<br />
<h3>
Active Learning in SAFe courses</h3>
Many of the attendees were passionate believers in experiential and/or active learning who have struggled with the orientation of the SAFe courseware towards “lecture-style” training. The great news for all of us is that this is becoming a significant focus area for SAI. The newly introduced RTE course is a radical departure from the past, and the preview we were given of the new Leading SAFe course shows marked improvement in this direction.<br />
<br />
<h3>
SAFe is taking off in Europe</h3>
I’ve been coming to Europe every few months in a SAFe context for a couple of years now (starting with Crieff in 2015), and it has clearly been lagging the US and Australian markets in enterprise adoption. But it appears the time has come. Of the roughly 50 attendees at this year’s summit, perhaps 40 were European based and the vast majority were actively involved in significant SAFe implementations – a radical departure from 2015. <br />
<br />
<h3>
Closing Thoughts</h3>
Great agile is all about collaboration, relationship and learning. The manifesto expressed it beautifully with the words “We are uncovering better ways of developing software by doing it and helping others do it”. This year’s retreat lived the philosophy, and I enjoyed deepening existing relationships, forming new ones, sharing my experiences and learning from others’. Bring on 2018!<br />
<br />Mark Richardshttp://www.blogger.com/profile/12477809828045353101noreply@blogger.com4tag:blogger.com,1999:blog-7030397814607511868.post-26698033975158825122017-04-23T06:28:00.000-07:002017-04-23T06:31:29.266-07:00Facilitating Release Train Design with the ART Canvas Part 2 - Design<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEg_lMnWXA66ZN3Y-srryrDTJfDE2iVwi4F7TQP7gox5fMMdNEJTEq7VFmgvPyVyA_s8XG0eZEEXKhgYBqiNW8ugawtUiXtZ82ocuojB68nQzbt135SeTq0BaLDBPlWrbW_tZCw3Evv16GZS/s1600/scaling+excellence+quote.JPG" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="140" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEg_lMnWXA66ZN3Y-srryrDTJfDE2iVwi4F7TQP7gox5fMMdNEJTEq7VFmgvPyVyA_s8XG0eZEEXKhgYBqiNW8ugawtUiXtZ82ocuojB68nQzbt135SeTq0BaLDBPlWrbW_tZCw3Evv16GZS/s640/scaling+excellence+quote.JPG" width="640" /></a></div>
<h3>
</h3>
<h3>
Introduction </h3>
In <a href="http://www.agilenotanarchy.com/2017/04/facilitating-release-train-design-with.html" target="_blank">my last article</a>, I introduced the concept of facilitating a 1-day launch planning workshop for an Agile Release Train using the ART Canvas. The workshop covers the generation of a vision for the ART, preparing an initial design and generating a launch plan.<br />
<br />
The more ARTs I launch, the greater the time I devote in the workshop to developing a clear, aligned vision using the approach described in the preceding article. With this in hand, we are well equipped to move forward with designing the ART itself – the focus of this article. <br />
<br />
<h4>
Workshop Agenda</h4>
<br />
<ul>
<li>Vision (<a href="http://www.agilenotanarchy.com/2017/04/facilitating-release-train-design-with.html" target="_blank">Details in last article</a>) </li>
<li>Design</li>
<ul>
<li>What is the Development Value Stream and to what extent will the ART cover it?</li>
<li>Who will fill the key Leadership roles for the ART?</li>
<li>What supporting leadership roles will the ART need?</li>
<li>Which technical assets will the ART impact?</li>
<li>What is our Team Design strategy for the ART?</li>
<li>What is the Name and Launch Date for the ART?</li>
</ul>
<li>Planning (Details in next article)</li>
</ul>
<br />
<h3>
What is the Development Value Stream and to what extent will the ART cover it?</h3>
I was torn between calling this section of the canvas “Development Value Stream” or “Solution Context”. Introduced in SAFe 4.0, <a href="http://www.scaledagileframework.com/solution-context/" target="_blank">the Solution Context</a> “<i>identifies critical aspects of the target solution environment</i>” and “<i>is often driven by factors that are outside the control of the organisation that develops the solution</i>”. I settled on the Development Value Stream because this tends to be how I facilitate the conversation.<br />
<br />
Our focus here is really to delineate the difference between “the ART we want” and “the ART we can have”. The “ART we want” can take an “Idea” directly from the Operational Value Stream and perform all activities necessary to carry that Idea through the life cycle until it ends in realized “Value”. However, reality tends to intervene. Perhaps the ART is not capacity funded and “Ideas” need to be routed through some type of PMO function before reaching the Product Manager. A particular supporting system may not able to be worked on by the ART due to the nature of the contract with a vendor or its ownership by an entrenched organisational silo. Further, many ARTs cannot deploy independently and must participate in an enterprise release process. <br />
<br />
Lack of awareness of the pragmatic compromises in your ART design can and will derail you. In Good to Great, Jim Collins summarized it beautifully: “<i>You must maintain unwavering faith that you can and will prevail in the end, regardless of difficulties, AND, at the same time, have the discipline to confront the most brutal facts about your current reality, whatever they may be</i>”.<br />
<br />
My favorite way to represent this is to depict a Development Value Stream running from “Idea to Value”, and represent using shading or call-outs those components of the Value Stream which fall outside the boundaries of the ART. There will be some obvious exclusions we can use to frame the following discussions, and as design progresses we will find ourselves adding some fine details. By the end of the workshop, we should have highlighted all of the ART’s key external dependencies in fulfilling its mission.<br />
<br />
<h3>
Who will fill the key Leadership Roles for the ART?</h3>
If you have been comparing my canvas to the one Dean documented, you will notice a couple of differences. One of these is that I define 4 key leadership roles, whilst Dean sticks to the “classic troika”:<br />
<br />
<ul>
<li>Release Train Engineer</li>
<li>Product Manager</li>
<li>System Architect</li>
<li>UX Lead (My addition)</li>
</ul>
<br />
The reason for my extension is simple: experience and scars. The vast majority of ARTs have at least some digital component to them, and if you have a digital component you will have a UX competency. I have learnt a great deal about the field of UX in the last 5 years, and much of it I’ve learned the hard way. Two critical lessons have emerged:<br />
<br />
<ul>
<li>There is regularly significant confusion between the roles of UX and Product Management</li>
<li>When it comes to embracing iterative and incremental approaches, UX specialists are often the new architects in terms of mindset battleground.</li>
</ul>
<br />
My response is to embrace their critical leadership role in enabling effective digital outcomes by recognizing them formally as part of the ART Leadership team. <br />
<br />
Facilitating the selection of candidates is generally a formality. If we’ve prepared for the workshop at all well, the nominees are sitting in the room and putting their names in the boxes is simply putting the stamp of approval on the nomination. If we walk out of the room with one of those boxes empty, we have a critical priority as all of them are going to be incredibly busy in the coming weeks executing on the launch plan and every day will count for each of them.<br />
<br />
<h3>
What supporting leadership roles will the ART need?</h3>
Large ARTs will often need some additional folks to support the key leaders. Following are some sample questions I use to seed this discussion:<br />
<br />
<ul>
<li><b>Will one Product Manager be enough</b>? (in the case of multiple Product Managers, I’m always looking to see one designated as “chief” but if we remember the SAFe guidance of 1 Product Manager per 2-4 Product Owners it will be far from uncommon to see 2-3 people in this role)</li>
<li><b>Will one Architect be enough?</b> (Given that system architects are often tied to a limited set of technology assets, I often see 2-3 architects dedicated to large ARTs to provide adequate coverage to all assets)</li>
<li><b>Do we need a Release Manager? </b>(If the ART is facing into an Enterprise Release process and has low or no Devops Maturity, liaising with the ITIL folks can be a full-time role)</li>
<li><b>Do we need a Test Manager?</b> (The concept of a Test Manager might be anathema in a mature agile implementation, but as we launch our ART we’re not yet mature. Who is going to mentor the testers embedded in the teams and assist them with evolving their testing strategy whilst also meeting the organisation’s governance and quality articulation needs?)</li>
<li><b>Do we need a Change Manager?</b> (Many of my ARTs have a full change management team, in which case of course we would tackle this in our team design, but in cases where we don’t have a full team I often see this role staffed for the ART to enable effective liaison with the Operational Value Stream with respect to operational readiness and go-to-market strategies).</li>
</ul>
<br />
<br />
Whilst on the one hand we want to “minimize management overhead by creating a self-organizing team of teams”, on the other this will not happen overnight. Experience has taught me that for any significant ART people in these roles will exist – our choice is whether to make them a “part of the team” sharing ownership of our transformative change, or a part of “external governance functions”. <br />
<h3>
<br /></h3>
<h3>
What technical assets will the ART impact?</h3>
Begin with the list of supporting systems from your Operational Value Stream outputs. Then, because representation in the value stream is often in terms of “meta platforms”, add in more granularity as needed. (For example, middleware is part of most ARTs but often considered to be implied during the value stream discussion).<br />
<br />
Now examine the list through the lens of “Frequency/Extent of Impact”. Framing the discussion in the context of the “typical Features” defined in the Solution section of the canvas, a simple mechanism such as “*” for frequently impacted and “**” for always impacted can be useful. Below is a simplified and de-sensitized example from a recent workshop:<br />
<br />
<ul>
<li>Web**</li>
<li>SAP Bus Suite*</li>
<li>Mainframe*</li>
<li>Mobile*</li>
<li>Security</li>
<li>ESB*</li>
<li>ESS</li>
<li>WFM</li>
<li>Data Integration</li>
<li>MI/EDW*</li>
</ul>
<br />
<h3>
What is our Team Design strategy for the ART?</h3>
<div class="separator" style="clear: both; text-align: center;">
</div>
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEijgHwHQvJaj9kofdbmIGaUVKTvmwkgFwy5bFgPDz8fWJtftZvIQK6MFVPey30GpIYeqgrWhgChiyl_o0Sl2_p9NBIuIZh6q_d7VsVSxSsdraT_Dwh_3hjhWAn8IGurQAWxU4hco4grO5G2/s1600/Multi+Skilled+Quote.JPG" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="144" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEijgHwHQvJaj9kofdbmIGaUVKTvmwkgFwy5bFgPDz8fWJtftZvIQK6MFVPey30GpIYeqgrWhgChiyl_o0Sl2_p9NBIuIZh6q_d7VsVSxSsdraT_Dwh_3hjhWAn8IGurQAWxU4hco4grO5G2/s640/Multi+Skilled+Quote.JPG" width="640" /></a></div>
<div>
<br /></div>
<div>
<div>
It surprises me that there aren’t entire books devoted to the topic of agile team design and the trade-offs between feature and component teams. My advice: "Be pragmatic yet ambitious". </div>
<div>
<br /></div>
<div>
In brutal honesty, I’m a reformed “feature team purist”. I love the theory, but I’ve lived the reality. Your culture has to be ready for them. Not just your management and silo owners, but most importantly your team members. They just don’t work without open-ness to cross-skilling. Have a conversation with an iOS dev about writing android code. Try another conversation with a 20 year COBOL veteran about learning to write javascript. Recognize that there are specializations within specializations – there is no better place to learn this than your middleware folks. The naïve will think “surely I can put a middleware person in each team”, only to discover there are 6-7 discrete specializations within middleware.</div>
<div>
<br /></div>
<div>
Recognize that your ART has to start somewhere, and inspect and adapt itself to a better place. I establish a “feature teams are the goal” mindset, then climb my way back to a decent starting place – generally a combination of “nearly feature teams” with 2-3 specialized component teams. For example, for the asset stack above we wound up with “nearly Feature Teams” containing Web, SAP and Mainframe skills, a “Data and Analytics” team, a “specialized assets” team and a “Business Enablement” team focused on change management and operation readiness. By the end of the first PI planning we’d also added a lawyer to the Business Enablement Team. And .. don’t forget to define the flavor of your System Team while you’re here. Nowhere will you tackle more organisational silos than in staffing a good system team, you want to seize the momentum you have established on vision to lock this in.</div>
<div>
<br /></div>
<div>
Do not attempt to match names to teams in this workshop. Focus on defining “team templates” covering both technical and non-technical skills (eg BA, UX, Functional Analysts if you have an ERP, etc). Working out the quantity of each team flavor and the match of names to teams can come later. If you’ve put the right people in the room (line managers) you are reaching alignment on commitment to dedication and cross-functionality.</div>
<div>
<br /></div>
<h3>
What is the Name and Launch Date for the ART?</h3>
<div>
Let me be brutally clear, if you leave the room without a launch date you’ve missed a huge opportunity. A committed date is a forcing function. You are laying the seeds of the “fix the date, float the scope” mindset the ART needs to have. Look for something between 2 and 8 weeks, with a preference for 6-8 weeks. Anything less than 4 weeks requires a lot of special circumstances, so if you’re new to the game don’t try it. Anything more than 8 will hurt your sense of urgency and momentum.</div>
<div>
<br /></div>
<div>
On the Name function, I (and my colleagues) are huge believers in the power of a name in establishing a shared sense of identity. All the data is on the table to find one, and the sooner this new creation has a name the sooner it will begin to take life. Some recent examples for me:</div>
<div>
<ul>
<li>SHERPA (Secure High value Engaged Reliable Payment Assurance)</li>
<li>DART (Digital Assurance Release Train)</li>
<li>START (Student Transformation Agile Release Train)</li>
</ul>
</div>
</div>
<h3>
</h3>
<h3>
Conclusion</h3>
<div>
With an agreed vision and design for the ART, the final step is to generate the launch plan and supporting approach - the topic of my final article in this series.</div>
<div>
<br /></div>
Mark Richardshttp://www.blogger.com/profile/12477809828045353101noreply@blogger.com6tag:blogger.com,1999:blog-7030397814607511868.post-18697795181669569282017-04-08T18:25:00.000-07:002017-04-23T06:32:41.076-07:00Facilitating Release Train design with the ART Canvas Part 1 - Vision<blockquote class="tr_bq">
“<i>It became clear to me after I began to read the four hundred or so vision statements I received: they all read the same. Every organisation cares about customers, values teamwork, exists for shareholders or the community, believes in excellence in all they do. If we all threw our vision statements in a hat and then drew one out, we would think it was ours regardless of where it came from. I finally realised that it was the act of creating a vision that matters, not so much the content of what it was.</i>” – <a href="https://www.google.com/url?sa=t&rct=j&q=&esrc=s&source=web&cd=1&cad=rja&uact=8&ved=0ahUKEwiOoPPU0YbTAhWIjJAKHUqHBMMQFggaMAA&url=https%3A%2F%2Fwww.amazon.com%2FFlawless-Consulting-Guide-Getting-Expertise%2Fdp%2F0470620749&usg=AFQjCNH0i8LLkCkNg54Ebm0yKW5PKhdmvQ&bvm=bv.151325232,d.eWE" target="_blank">Peter Block, Flawless Consulting</a></blockquote>
<br />
<h3>
Introduction</h3>
In January 2014, I wrote <a href="http://www.agilenotanarchy.com/2014/01/psi-planning-tip-1-execute-your-launch.html" target="_blank">my first article on launching an ART</a>. It focused on the concept of a launch planning workshop that formed a cross-functional Agile Leadership team and generated a vision and a backlog they could execute on over 6-8 weeks to launch their ART.<br />
<br />
I’ve launched over 30 ARTs since then, and whilst my core approach has remained consistent it has benefited from a great deal of iteration. The biggest change has been adjusting the proportion of time I spend on the ART vision and design as opposed to the launch preparation backlog. Alignment is a key component of ART success, and if the leaders aren’t aligned on the vision there is little hope for the teams.<br />
<br />
Walking out of a brilliant launch workshop last year, I sat down to reflect on the key conversations and capture some notes to feed forward into my next launch. As I reviewed the photos, I had an aha moment. Why not use a Lean Canvas to anchor the key conversations? I could print it out as a big wall poster, structure an agenda around completing it and walk out of the workshop with a “Train on a Page” diagram. <br />
<br />
I’ve used it a number of times since then to good effect, and when I shared it with <a class="g-profile" href="https://plus.google.com/111678440224086860538" target="_blank">+Dean Leffingwell</a> on a visit to Boulder in January he was quick to ask about including it in his new <a href="http://www.scaledagileframework.com/implementation-roadmap/" target="_blank">Implementation Roadmap</a>. While he beat me to the publish button a few weeks ago with his <a href="http://www.scaledagileframework.com/prepare-for-art-launch/" target="_blank">Prepare for Art Launch</a> article, I felt there would be value in sharing the approach I take to facilitating it.<br />
<div>
<br /></div>
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiuhyt-30p22EZEoq4bhuwG8yfHElclcpplJPBMCzHtag6wG7kWPDEjgA_JRdZRIG8vyL351WSwZPU2M5AjoJAxzz-pD70o-kXfDMO9MbBMd38m9hy0O04WuXcEPb_bQhkSpQm69xhpW3LZ/s1600/Blank+ART+Canvas.JPG" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="344" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiuhyt-30p22EZEoq4bhuwG8yfHElclcpplJPBMCzHtag6wG7kWPDEjgA_JRdZRIG8vyL351WSwZPU2M5AjoJAxzz-pD70o-kXfDMO9MbBMd38m9hy0O04WuXcEPb_bQhkSpQm69xhpW3LZ/s640/Blank+ART+Canvas.JPG" width="640" /></a></div>
<div>
<br /></div>
<div>
<div>
All of my ART launches begin with what I call the “Launch Planning Workshop”. Generally held within a week of the Leading SAFe, this is a one-day facilitated workshop attended by the Business Owners and ART Leadership team with the objective of clarifying the vision, boundary and key success measures for the ART and generating the launch preparation backlog.</div>
<div>
<br /></div>
<div>
The workshop progresses through 3 phases:</div>
<div>
<ul>
<li>Define the vision</li>
<li>Design the ART</li>
<li>Generate the Launch Plan</li>
</ul>
</div>
<div>
This article will tackle opening the workshop and the most important phase: the Vision. My next two articles will address ART design and generation of the launch plan.</div>
<div>
<br /></div>
<h3>
Opening the Workshop</h3>
<div>
The workshop opens with a blank A0 copy of the Canvas pinned to the wall and a 2-part objective:</div>
<div>
<ul>
<li>Complete the ART Canvas to define the Vision, Leadership and Design strategy for our ART</li>
<li>Generate a backlog detailing the activities necessary to bring it to life</li>
</ul>
</div>
<div>
The bulk of the attendees should have recently attended Leading SAFe, and key participants include:</div>
<div>
<ul>
<li>ART Leadership Candidates (at minimum RTE, Product Manager, System Architect)</li>
<li>Key sponsors from both Business and IT</li>
<li>Relevant technology Line Management (those who are likely to be contributing staff to the ART)</li>
</ul>
</div>
<div>
As a general note, I do not directly populate the Canvas. I operate on either 2 whiteboards or a combination of flip-charts. At the completion of each section, a scribe will transcribe the outputs onto the canvas.</div>
<div>
<br /></div>
<h4>
Workshop Agenda</h4>
<div>
<ul>
<li>Vision</li>
<ul>
<li>Which Customers will be impacted by the ART?</li>
<li>Which Operational Value Stream(s) will the ART support?</li>
<li>Who are the Business Owners for the ART?</li>
<li>What kind of Features will the ART deliver?</li>
<li>How will we measure success for the ART?</li>
<li>What is the Vision statement for the ART?</li>
</ul>
<li>Design (Details in <a href="http://bit.ly/2p9Jf9L" target="_blank">next article</a>)</li>
<li>Planning (Details in future article)</li>
</ul>
</div>
<h3>
</h3>
<h3>
Vision</h3>
<div>
The first 6 topics on the agenda address the vision for the ART, culminating in the creation of a Vision Statement. </div>
<div>
<br /></div>
<h4>
Which Customers will be impacted by the ART?</h4>
<div>
Customer centricity is at the heart of Lean and Agile, so it is where we begin. This should take no more than 5 minutes. Personally, I use the “internal Customer” and “external Customer” metaphor to frame the conversation and ensure we are covering both internal users of the solution and true customers of the organisation.</div>
<div>
<br /></div>
<h4>
Which Operational Value Stream(s) will the ART support? </h4>
<div>
The mission for any ART involves improving business outcomes, and succeeding in that mission begins with understanding the flow of value in the areas of the business the ART is to support. </div>
<div>
If a Value Stream workshop has already been conducted, this is the moment to review the outputs from that workshop. However, for most ARTs this is not the case and now is the moment to identify and map the relevant operational value stream(s). Provided the right people are in the room, this can be generated at an appropriate level in 20-30 minutes. Generally, we are concerned with a single value stream and we look to our business folks to generate the core flow and architects to map the underlying systems. Note that we do not need a great deal of detail. </div>
</div>
<div>
<br /></div>
<table align="center" cellpadding="0" cellspacing="0" class="tr-caption-container" style="margin-left: auto; margin-right: auto; text-align: center;"><tbody>
<tr><td style="text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEj0dXnMU5qeN_F3ifG5Hg_8U5mZm0Kq_E56MmFaOr30ZTWakAKkX3Lf7bhmi-1V_JcepfrifN547DTLF3RxyOdRQKHeH5byACaUNrvIjIg5tEeGIHlQxqvpdKWdvR1Tc-F0pPV5JFVd9UE3/s1600/Sample+Operational+Value+Stream.JPG" imageanchor="1" style="margin-left: auto; margin-right: auto;"><img border="0" height="144" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEj0dXnMU5qeN_F3ifG5Hg_8U5mZm0Kq_E56MmFaOr30ZTWakAKkX3Lf7bhmi-1V_JcepfrifN547DTLF3RxyOdRQKHeH5byACaUNrvIjIg5tEeGIHlQxqvpdKWdvR1Tc-F0pPV5JFVd9UE3/s640/Sample+Operational+Value+Stream.JPG" width="640" /></a></td></tr>
<tr><td class="tr-caption" style="text-align: center;">Service Assurance Operational Value Stream for a Telco</td></tr>
</tbody></table>
<div>
<div>
For more information (and examples) on approaching this, see the excellent new guidance provided in the <a href="http://www.scaledagileframework.com/identify-value-streams-and-arts/" target="_blank">Identify Value Streams and ARTs article</a> from the Implementation Roadmap.</div>
<div>
<br /></div>
<h4>
Who are the Business Owners for the ART?</h4>
<div>
I have to confess that for a number of years, I wondered why Dean insisted on providing a new term instead of just talking about Stakeholders. An embarrassingly short time ago, it finally hit me. Every ART will have many stakeholders, but in general 3-5 of them will be critical. These are your <a href="http://www.scaledagileframework.com/business-owners/" target="_blank">Business Owners</a>. SAFe calls out specific responsibilities for them, defining them as “<i>a critical group of three to five stakeholders who have shared fiduciary, governance, efficacy and ROI responsibility for the value delivered by a specific Agile Release Train</i>”. </div>
<div>
<br /></div>
<div>
Having now lived through a number of ARTs where either the membership of this group was unclear or the identified members took little accountability, I am now very focused on identifying them early and ensuring they have been engaged and signed up for their responsibilities prior to the launch.</div>
<div>
<br /></div>
<h4>
What kind of Features will the ART deliver (Solution)?</h4>
<div>
Over time, the ART will deliver many Features. In general, by the time you are at launch there is a known seed. Perhaps it is being triggered by a waterfall program with preexisting expectations “converting” to agile. Perhaps a critical project, or an urgent set of priorities. But we’re also looking to consider the future – if for no other reason than to assist in both communicating to the broader organisation and assist decision rules on work that should be routed to the ART. Following is a sample from a recent workshop:</div>
<div>
<ul>
<li>New, digitally enabled user experience on available technology</li>
<li>Process automation, improved data exchange with third parties</li>
<li>Remediation of current platform</li>
</ul>
<div>
In short, by this point we know which operational value stream we're supporting, who the customers and key stakeholders are - we just want to clarify "what kind of stuff" they can expect from the ART.</div>
</div>
<div>
<br /></div>
<h4>
How will we measure success for the ART?</h4>
<div>
Given that 9 out of 10 of my last articles have focused on metrics, it should come as no surprise that I want to talk about them as part of our vision workshop. There are many good reasons to do this, but the most important one lies in establishing the mindset that success for the ART involves business outcomes, not “delivering features on time and budget” or “improving velocity”. It enables validation of the vision with the Business Owners, assists Product Managers in establishing their WSJF prioritization approach for the Program Backlog and frames the kind of benefit propositions that should be appearing in Features. Further, it enables us to capture baselines during our pre-launch phase so we are positioned to understand the impact the ART is having.</div>
<div>
<br /></div>
<div>
For those who have followed <a href="http://www.agilenotanarchy.com/2017/01/revamping-safes-program-level-pi.html" target="_blank">my Metrics series</a> , this area seeds the Fitness Function from the <a href="http://www.agilenotanarchy.com/2017/01/revamping-safes-program-level-pi_19.html" target="_blank">Business Impact quadrant</a>. Whilst you many not exit the room with a full set of quantifiable measures, you can at least define qualitative ones and a follow-up activity to establish quantitative approaches to them. Below, you’ll find a (slightly desensitized) sample set from a recent workshop:</div>
<div>
<ul>
<li>Staff</li>
<ul>
<li>Automation of simple work</li>
<li>Able to add more value by focusing on complex work</li>
<li>Stable and trustworthy technical platform</li>
</ul>
<li>Customers</li>
<ul>
<li>Simple, intuitive, digitally enhanced experience</li>
<li>Increased accuracy and timeliness </li>
<li>Tailored service offer based on individual circumstances</li>
<li>Seamless movement between channels (tell us once)</li>
</ul>
<li>Organisation</li>
<ul>
<li>Straight-through processing increased</li>
<li>Authenticated digital transactions increased</li>
<li>Accuracy increased in the areas of debt, outlays and fraud</li>
<li>Operational Costs reduced</li>
</ul>
</ul>
</div>
<h4>
</h4>
<h4>
What is the Vision Statement for the ART?</h4>
<div>
The discussion we have facilitated to this point has been focused on identifying “non-generic” components of the vision statement by exploring the following questions:</div>
<div>
<ul>
<li>Who are our customers?</li>
<li>How do we interact with them? (the operational value stream)</li>
<li>Who are our critical stakeholders? (who have to bless the vision)</li>
<li>What kind of Features are we going to deliver?</li>
<li>What difference are we to make? (Success Measures)</li>
</ul>
</div>
<div>
Now we want to bring it all together. I’m a big fan of the elevator pitch template popularized by Geoffrey Moore in <a href="https://www.google.com/url?sa=t&rct=j&q=&esrc=s&source=web&cd=1&cad=rja&uact=8&ved=0ahUKEwjFh5WH04bTAhUoQpoKHUtfCtwQFggcMAA&url=https%3A%2F%2Fwww.amazon.com%2FCrossing-Chasm-Marketing-High-Tech-Mainstream%2Fdp%2F0060517123&usg=AFQjCNFkrtgc11ebqqfsMcQWuXuvw3NS3w" target="_blank">Crossing the Chasm</a> and leveraged by SAFe in the Epic Value Statement. I will generally split the room into two sub-groups (ensuring a mix of backgrounds in each), and give each 20 minutes to create their pitch. I then help them pick a favorite, and optionally spend another 10 minutes polishing it by incorporating key ideas from the discarded pitch.</div>
<div>
<br /></div>
<div>
For the brave, an alternative which can really get the creative juices flowing is the Pixar Pitch. My colleague <a class="g-profile" href="https://plus.google.com/116452192195762487608" target="_blank">+Em Campbell-Pretty</a> <a href="http://www.prettyagile.com/2014/06/pitching-pixar-pitch.html" target="_blank">wrote an article on it</a> a few years ago which includes a sample used as the vision for an ART in a higher education setting. Whilst confidentiality precludes me from sharing a specific example here, I have included one written by a leadership team describing what success with their SAFe implementation would look like:</div>
</div>
<div>
<br /></div>
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEin1uIq8H8OHFCq2i6rutiFVwMYLkm-gzBUPkc_PuQIOYq_tBuzC6LMiMVWKNyPQoVa-7x-VCcAqAJIp8HsjvMNItV1MuITnKRuxhVhpUCR0opAGkOqEQZRHIeD5I_6ZWCEnIuxNLCOm2AL/s1600/Sample+Pixar+Pitch.JPG" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="392" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEin1uIq8H8OHFCq2i6rutiFVwMYLkm-gzBUPkc_PuQIOYq_tBuzC6LMiMVWKNyPQoVa-7x-VCcAqAJIp8HsjvMNItV1MuITnKRuxhVhpUCR0opAGkOqEQZRHIeD5I_6ZWCEnIuxNLCOm2AL/s640/Sample+Pixar+Pitch.JPG" width="640" /></a></div>
<div>
<br /></div>
<div>
<h3>
Conclusion</h3>
<div>
Getting this far will take at least until lunch, and probably a little further. In all likelihood, the longer it takes the more value you are getting from the discussion as assumptions are flushed and clarity emerges both on “what the mission of the ART is” and just as importantly “what it is not”! </div>
<div>
</div>
<div>
The alignment and sense of mission achieved here will stand you in good stead as you progress into the ART Design agenda items addressed <a href="http://bit.ly/2p9Jf9L" target="_blank">in my next article</a> and begin to tackle some ivory towers and entrenched silos.</div>
</div>
<div>
<br /></div>
Mark Richardshttp://www.blogger.com/profile/12477809828045353101noreply@blogger.com12tag:blogger.com,1999:blog-7030397814607511868.post-14496148085186777662017-03-26T05:41:00.002-07:002017-03-26T05:41:56.597-07:00Using OKRs to accelerate Relentless Improvement<h3>
Introduction</h3>
In my last 2 articles, I first <a href="http://www.agilenotanarchy.com/2017/03/an-introduction-to-objectives-and-key.html" target="_blank">introduced the concept of Objectives and Key Results (OKRs) with an illustration based on personal goal-setting</a> then explored <a href="http://www.agilenotanarchy.com/2017/03/improving-safe-product-management.html" target="_blank">applying them to improvement of Product Strategy</a>.<br />
<br />
After experimenting on myself with personal OKRs, my first applications of the concept in a coaching setting have been in the area of improvement objectives. I was particularly excited about this idea as I encounter so many teams and ARTs who lose heart with their retrospectives and Inspect and Adapt sessions due to failure to follow through on their great ideas.<br />
<br />
I’ve lost count of how many discussions I’ve had in either the training room or a coaching setting with people who drag themselves to retrospectives feeling they are a waste of time. The common refrain is that “we just keep talking about the same issues and nothing ever changes”. A little probing generally exposes the following:<br />
<br />
<ul>
<li>Teams use the same format every time (my pet hate is the “What went well, what didn’t go well, what puzzles me” retro).</li>
<li>Teams spend 80-90% of our session examining the past</li>
<li>The (rushed) improvement idea generation yields concepts beyond their power to change or very fuzzy</li>
<li>Few teams retrospect on the effectiveness or application of the ideas they do generate </li>
</ul>
<br />
I’ve gifted many a copy of Esther Derby and Diana Larsen’s classic “<a href="https://www.google.com.au/url?sa=t&rct=j&q=&esrc=s&source=web&cd=1&cad=rja&uact=8&ved=0ahUKEwjqvce46vHSAhVFkpQKHfFlBHMQFggZMAA&url=https%3A%2F%2Fwww.amazon.com%2FAgile-Retrospectives-Making-Teams-Great%2Fdp%2F0977616649&usg=AFQjCNHgUiL4q_D-j4lMcupUDIbyr-NJbA&bvm=bv.150729734,d.dGo" target="_blank">Agile Retrospectives</a>” to ScrumMasters and RTE’s. Likewise, I’ve facilitated countless sessions on time-boxing your retrospective or I&A to leave at least 50% of it for the “improvement” part of the discussion. <br />
<br />
Good facilitation will at least get you to the point of emerging from the session with some good ideas. However, in the words of Michael Josephson “<i>Ideas without action are like beautifully gift-wrapped boxes with nothing inside</i>”.<br />
<br />
<h3>
Crystallizing your great ideas with OKRs</h3>
A couple of years ago, I started experimenting with the Improvement Kata to assist teams with actioning their ideas. As I researched it, I came across <a href="http://blog.crisp.se/2013/05/14/jimmyjanlen/improvement-theme-simple-and-practical-toyota-kata" target="_blank">a great article describing an “Improvement Theme Canvas” by Crisp’s Jimmy Janlen</a>. The canvas was beautifully simple, taking teams on a great journey with 4 questions:<br />
<br />
<ul>
<li>Where are we now?</li>
<li>Where do we dream of being (What does awesome look like?)</li>
<li>Where can we get to next? (And how would we measure it?)</li>
<li>What steps would start us moving?</li>
</ul>
<br />
I used it again and again, in settings ranging from team retrospectives to executive workshops. And it helped. But it was still missing something. There was a recurring trend – a lack of measures.<br />
As I started experimenting with OKRs, there was an obvious synergy. I had found the Key Result setting to be the moment where I did my deepest thinking myself, so I tweaked the canvas a little:<br />
<div>
<br /></div>
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEi7-1bNzNdUVV1qTzlWW3YoXSKHrva6xwcczBmP352HB_LgWJ_pfHLhlk0YxYVtmpbPNpKKCbMyQ0gbKOTqHjWCy0s5mYYDor8tJ-qXfpsQhw5sZNE76NQEDHVXaYWde4z27mZb5CfVOQ14/s1600/Blank+Improvement+OKR+Canvas.JPG" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="363" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEi7-1bNzNdUVV1qTzlWW3YoXSKHrva6xwcczBmP352HB_LgWJ_pfHLhlk0YxYVtmpbPNpKKCbMyQ0gbKOTqHjWCy0s5mYYDor8tJ-qXfpsQhw5sZNE76NQEDHVXaYWde4z27mZb5CfVOQ14/s640/Blank+Improvement+OKR+Canvas.JPG" width="640" /></a></div>
<div>
<br /></div>
<div>
<div class="MsoNormal">
My first opportunity to apply it was the second day of a
management workshop. The first day had
been spent exploring challenge areas and selecting focus areas for
improvement. We had a fairly clear view
of current state and definition of awesome (which represented 18 months+ of hard
work), and the job on Day 2 was to address the right side of the canvas with a
3 month view. <o:p></o:p></div>
<div class="MsoNormal">
<br /></div>
<div class="MsoNormal">
We began with some objectives, then the hard work began –
how would we measure them? The result
was incredibly powerful. We moved from
some very fuzzy, amorphous objectives into real clarity on how to generate
momentum. When you start to talk about
how to measure movement, something changes in the conversation. On the one hand, it grounds you in reality
but on the other the fact that you are looking for a measure ambitious enough
to only have a 50% chance of success stretches you out again. <o:p></o:p></div>
<div class="MsoNormal">
<br /></div>
<div class="MsoNormal">
As an illustration, I’ve developed a sample based on a
commonly occurring theme in Inspect and Adapt sessions – struggles to develop
momentum with Test Automation.<o:p></o:p></div>
<div class="MsoNormal">
<br /></div>
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiHFspwp9daWX_cYGcwDWCb9yE1-Q1JCwclnsfasRa2rVO-Do9JBV9vTLZL_ZOoTmfwYqsSpiCR8dLEWkBca42MsP2cqQEVgc_eOL0FDNNlcz9JTjFql8UZAG1Ju1WRy3bDnRnISy2HeyZ4/s1600/Sample+Improvement+OKR+Canvas.JPG" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="348" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiHFspwp9daWX_cYGcwDWCb9yE1-Q1JCwclnsfasRa2rVO-Do9JBV9vTLZL_ZOoTmfwYqsSpiCR8dLEWkBca42MsP2cqQEVgc_eOL0FDNNlcz9JTjFql8UZAG1Ju1WRy3bDnRnISy2HeyZ4/s640/Sample+Improvement+OKR+Canvas.JPG" width="640" /></a></div>
<div class="MsoNormal">
<br /></div>
<div class="MsoNormal">
As a final hint on the canvas generation, the order in which you complete it is crucial. There’s a great temptation to rush to “Enabling Activities” because people love to begin with solutions. </div>
<div class="MsoNormal">
</div>
<ul>
<li>Start with “Current state”: fishbone diagrams, 5 whys, and causal loop diagrams are all great tools for generating the data and shared understanding</li>
<li>Move to “Definition of Awesome”. The word “Awesome” is incredibly powerful in helping move minds into the art of the possible, and also encourages alignment around desired direction.</li>
<li>Step 3 is to agree on your timebox (often 3 months or one Program Increment) and figure out how far you can move from your current state to the definition of awesome as you set your “Target State OKRs”. You will start flushing assumptions, and more importantly discovering alignment challenges. The movement to quantified measures with your Key Results will expose many an unvoiced insight.</li>
<li>Only now do you set the “Enabling activities”. They will come very quickly. If you’ve set your OKRs well, your key activities will be very obvious.</li>
</ul>
<br />
<div class="MsoNormal">
<br /></div>
<h3>
So far we only have an Idea, what about Action? </h3>
<div class="MsoNormal">
I can recommend nothing so strongly as the weekly priority-setting cycle from Radical Focus I described in <a href="http://www.agilenotanarchy.com/2017/03/an-introduction-to-objectives-and-key.html" target="_blank">my first OKR article</a>. The reality is, despite many schemes people use for creating space for follow-up on improvement ideas it is amazing how often they stumble. Life gets busy, delivery pressure is high, and the first thing that gets sacrificed is time to work on improvement ideas. </div>
<div class="MsoNormal">
<br /></div>
<div class="MsoNormal">
The beauty of setting yourself a few priorities each week on moving towards your OKRs and spending a little time reflecting on them at the end of the week is that it helps you “find time”. A few months into applying personal OKRs I can attest to this. I live a very hectic life. Most weeks involve 5 long days facilitating and coaching with clients, 2-3 flights, and lots of “after hours admin” whilst coming up for air to be a dad, husband and human 😊 Its very easy to find excuses. But every week starts with “how can I move forward this week?” And in the back of my head every day are my weekly goals. To be brutally honest, my learning cycle at the end of the week often focuses on “how to find time”. I’m not waiting 3 months to look back and find out I made no progress and lose heart. </div>
<div class="MsoNormal">
<br /></div>
<div class="MsoNormal">
My final hint is this: Make them public. If you’re applying the technique to Inspect and Adapt, your improvement OKRs should appear in your PI Objectives and progress discussed in your System Demos and PI Demo. Include the Key Result evaluation in the metric portion of your Inspect and Adapt. There is both power and motivation in transparency about improvement objectives.</div>
</div>
<div>
<br /></div>
Mark Richardshttp://www.blogger.com/profile/12477809828045353101noreply@blogger.com22tag:blogger.com,1999:blog-7030397814607511868.post-81482338715144578052017-03-12T16:02:00.000-07:002017-03-12T16:02:16.009-07:00Improving SAFe Product Management Strategy with OKRs<h3>
Introduction</h3>
In <a href="http://www.agilenotanarchy.com/2017/03/an-introduction-to-objectives-and-key.html" target="_blank">my last article</a>, I introduced the concept of Objectives and Key Results (OKRs) and provided an illustration based on personal application. However, I only tried out personal OKRs because I wanted a way to “learn by doing” before I started trying out some of my thinking on incorporating them in SAFe. This article will explore the first application in SAFe: Improving Product Strategy.<br />
<br />
Late last year, Product Management guru John Cutler wrote a brilliant article called <a href="https://hackernoon.com/12-signs-youre-working-in-a-feature-factory-44a5b938d6a2#.458u7lcsn" target="_blank">“12 signs you’re working in a Feature Factory”</a>. Some highlights include:<br />
<br />
<ul>
<li><i>No connection to core metrics. Infrequent discussions about desired customer and business outcomes.</i></li>
<li><i>“Success Theater” around shipping with little discussion about impact.</i></li>
<li><i>Culture of hand-offs. Front-loaded process in place to “get ahead of the work” so that items are ready for engineering”. Team is not directly involved in research, problem exploration, or experimentation and validation.</i></li>
<li><i>Primary measure of success is delivered features, not delivered outcomes.</i></li>
<li><i>No measurement. Teams do not measure the impact of their work.</i></li>
<li><i>Mismatch between prioritization rigour (deciding what gets worked on) and validation rigour (deciding if it was, in fact, the right thing to work on).</i></li>
</ul>
<br />
His blog is a gold-mine for Product Managers, and I found much of his thinking resonated with me when it came to the difference between a healthy ART and a sick one. OKRs are a very handy tool in combating the syndrome.<br />
<br />
<h3>
Introducing OKRs to Feature Definitions</h3>
The <a href="http://www.scaledagileframework.com/features-and-capabilities/" target="_blank">official guidance</a> says “every feature must have defined benefits”. We teach it in every class, and our Cost of Delay estimates should be based on the defined benefits but it is frightening how few ARTs actually define benefits or expected outcomes for features. At best, most scratch out a few rarely referenced qualitative statements. <br />
<br />
Imagine if every feature that went into a Cost of Delay (COD) estimation session or PI planning had a clearly defined set of objectives and key results! <br />
<br />
Following is an illustration based on an imaginary feature for a restaurant wanting to introduce an automated SMS-based reservation reminder capability.<br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjErvyyCfCuLZSnYdaCHOYvV2j84JcrbnHb0_RuHQ2PkdeXyMzjJd_at8Owh6BPzXlrFjNJkAYKhpTRggAo_C1fomxMgECxBZq2BKaIM8XpeYuioYx1JtVj-J2-o2OZ8OrvLti35jU-EqkF/s1600/Feature+OKR+example.JPG" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="186" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjErvyyCfCuLZSnYdaCHOYvV2j84JcrbnHb0_RuHQ2PkdeXyMzjJd_at8Owh6BPzXlrFjNJkAYKhpTRggAo_C1fomxMgECxBZq2BKaIM8XpeYuioYx1JtVj-J2-o2OZ8OrvLti35jU-EqkF/s400/Feature+OKR+example.JPG" width="400" /></a></div>
<div>
<br /></div>
<div>
<h3>
Applying OKRs to PI Objectives</h3>
<div>
I’ve lost count of the number of long discussions I’ve had about the difference between PI Objectives and Features. They almost always start the same way. “Surely our PI Objective is to deliver Feature X”. Or, in an ART with a lot of component teams it might be “Support Team A in delivering Feature X”.</div>
<div>
<br /></div>
<div>
<b>WRONG! </b></div>
<div>
</div>
<div>
Good PI objectives are based on outcomes. Over the course of the planning event, the team unpacks their features and generates stories to capture the ongoing conversation and identify key inter-dependencies. Eventually, we consolidate what we’ve learned about the desired outcomes by expressing them as PI objectives. The teams don’t commit to delivering the stories, they commit to achieving the objectives. They should be working with their product owners all the way through the PI to refine and reshape their backlogs to maximize their outcomes. </div>
<div>
<br /></div>
<div>
If every feature that enters PI planning has a well-defined set of OKRs, we have a great big hint as to what our objectives are. An ART with good Devops maturity may well transpose the Feature OKRs straight into their PI objectives (subject to trade-off decisions made during planning). They will ship multiple times during the PI, leveraging the feedback from each deployment to guide their ongoing backlog refinement. </div>
<div>
<br /></div>
<div>
<a href="http://www.scaledagileframework.com/decentralize-decision-making/" target="_blank">SAFe Principle 9</a> suggests enabling decentralization by defining the economic logic behind the decision rather than the decision itself. Using well-defined OKRs for our PI objectives provides this economic logic, enabling Product Owners and teams to make far more effective trade-off decisions as they execute.</div>
<div>
<br /></div>
<div>
However, without good DevOps maturity the features may not have been deployed in market for sufficient time by the end of the PI to be measuring the predefined Key Results. In this case, the team needs to work to define a set of Key Results they will be able to measure by the time the PI is over. These should at minimum be demonstrating some level of incremental validation of the target KRs. Perhaps they could be based on results from User Testing (the UX kind, not UAT). Or maybe, measured results in integration test environments. For example:</div>
<div>
<ul>
<li>50% of test users indicated they were highly likely to recommend the feature to a friend or colleague</li>
<li>End-to-end processing time reduced by 50% in test environments. </li>
</ul>
</div>
<div>
Last but not least, we’ve started to solve some of the challenges ARTs experience with the “Business Value” measure on PI objectives. It should be less subjective during the assignment stage at PI Planning and completely quantitative once we reach Inspect and Adapt!</div>
<div>
<br /></div>
<h3>
Outcome Validation</h3>
<div>
By this point, we’ve started to address a number of the warning signs. But, unless we’re some distance down the path to good DevOps we haven’t really done much about validation. If you read <a href="http://www.agilenotanarchy.com/2017/02/getting-from-idea-to-value-with-art.html" target="_blank">my recent Feature Kanban article</a>, you’ll have noticed that the final stage before we call a feature “done” was “Impact Validation”. </div>
<div>
<br /></div>
<div>
This is the moment for final leverage of our Feature OKRs. What happened once the feature is deployed and used in anger? Do the observed outcomes match expectations? Do they trigger the generation of an enhancement feature to feed back through our Program Backlog for the next Build/Measure/Learn cycle? Do they affect the priorities and value propositions of other features currently in the Program Backlog?</div>
<div>
<br /></div>
<h3>
Linking it back to the ART PI Metrics dashboard</h3>
<div>
In the <a href="http://www.agilenotanarchy.com/2017/01/revamping-safes-program-level-pi_19.html" target="_blank">business impact quadrant of my PI metrics model</a>, I proposed that every ART should have a “fitness function” defining the fashion in which the ART could measure its impact on the business. This function is designed to be enduring rather than varying feature by feature – the intended use is to support trend-based analysis. The job of effective product managers is, of course, to identify features which will move the strategic needles in the desired direction. Business Features should be contributing to Business Impacts, Enablers might be either generating learning or contributing to the other three quadrants.</div>
<div>
<br /></div>
<div>
Thus, what we should see is Key Result measures in every feature that exert force on the strategic success measures for the ART. Our team level metric models should be varying with feature content to enable them to steer. This helps with the first warning sign Cutler identifies:</div>
<div>
<ol>
<li><i>No measurement. Teams do not measure the impact of their work. Or, if measurement happens, it is done in isolation by the product management team and selectively shared. You have no idea if your work worked.</i></li>
</ol>
</div>
<h3>
Conclusion</h3>
<div>
Whilst OKRs obviously have a lot to offer in the sphere of Product Strategy, this is not the only area in which they might help us with SAFe. In my next article, I’ll explore applying them to Relentless Improvement.</div>
</div>
<div>
<br /></div>
Mark Richardshttp://www.blogger.com/profile/12477809828045353101noreply@blogger.com97tag:blogger.com,1999:blog-7030397814607511868.post-57239554031314245992017-03-05T07:04:00.003-08:002017-03-05T07:04:38.825-08:00An Introduction to Objectives and Key Results (OKRs)<h3>
Introduction</h3>
In late January I was working on a final draft of one of my metrics articles when someone suggested I take a look at OKRs. I’d heard of them, but hadn’t really paid much attention other than to file it on my always long backlog of “things I need to learn something about”. Then a couple of days later I was writing my abstract for a metrics session at the Agile Alliance 2017 conference and in scanning the other submissions in the stream discovered a plethora of OKR talks. This piqued my interest, so I started reading the OKR submissions. At this point I panicked a little. The concept sounded fascinating (and kind of compelling when you realize its how Google and Intel work). I was facing into the idea that my lovingly crafted “SAFe PI Metrics revamp” might be invalidated before I even finished the series.<br />
<br />
So, I went digging. The references that seemed to dominate were <a href="https://www.amazon.com.au/Radical-Focus-Achieving-Important-Objectives-ebook/dp/B01BFKJA0Y" target="_blank">Radical Focus by Christina Wodtke</a>, a <a href="https://youtu.be/mJB83EZtAjc" target="_blank">presentation by Rick Clau of Google</a>, and an <a href="https://rework.withgoogle.com/guides/set-goals-with-okrs/steps/introduction/" target="_blank">OKR guide by Google</a>. A few days of reading later, I relaxed a little. I hadn’t read anything that had invalidated my metric model, but I could see a world of synergies. A number of obvious and compelling opportunities to apply OKR thinking both personally and to SAFe had emerged.<br />
<br />
In this article, I will provide a brief overview of the concept and use my early application to personal objective setting as a worked example. My next article will detail a number of potentially powerful applications in the context of SAFe. <br />
<br />
<h3>
OKRs – an Overview</h3>
As Wodtke states in Radical Focus, “<i>this is a system that originated at Intel and is used by folks such as Google, Zynga, LinkedIn and General Assembly to promote rapid and sustained growth. O stands for Objective, KR for key results. Objective is what you want to do (Launch a killer game!), Key Results are how you know if you’ve achieved them (Downloads of 25K/day, Revenue of 50K/day). OKRs are set annually and/or quarterly and unite the company behind a vision</i>”<br />
<br />
Google provides some further great clarifying guidance:<br />
<br />
<ul>
<li><i>“Objectives are ambitious and may feel somewhat uncomfortable”</i></li>
<li><i>“Key results are measurable and should be easy to grade with a number (Google uses a scale of 0-1.0”</i></li>
<li><i>“The sweet spot for an OKR grade is 60-70%; if someone consistently fully attains their objectives, their OKRs are not ambitious enough and they need to think bigger”</i></li>
<li><i>“Pick just three to five objectives – more can lead to overextended teams and a diffusion of effort”.</i></li>
<li><i>“Determine around three Key Results for each objective”</i></li>
<li><i>“Key results express measurable milestones which, if achieved, will directly advance the objective”.</i></li>
<li><i>“Key results should describe outcomes, not activities”</i></li>
</ul>
<br />
Wodtke dials it up a notch when it comes to ambition:<br />
<br />
<ul>
<li>“<i>OKRs are always stretch goals. A great way to do this is to set a confidence level of five of ten on the OKR. By confidence level of five out of ten, I mean ‘I have confidence I only have a 50/50 shot of making this goal</i>”.</li>
</ul>
<br />
<br />
<h3>
Personal OKRs – a worked example</h3>
I’m a great believer in experimenting on myself before I experiment on my customers, so after finishing Radical Focus I decided to try quarterly personal OKRs. Over the years, I’ve often been asked when I’m going to write a book. After my colleague <a class="g-profile" href="https://plus.google.com/116452192195762487608" target="_blank">+Em Campbell-Pretty</a> published <a href="https://www.google.com.au/url?sa=t&rct=j&q=&esrc=s&source=web&cd=1&cad=rja&uact=8&ved=0ahUKEwjr7YqctLrSAhWHVZQKHX2ED4QQFggZMAA&url=https%3A%2F%2Fwww.amazon.com%2FTribal-Unity-Getting-Creating-Culture-ebook%2Fdp%2FB01LZ0O4RC&usg=AFQjCNHYP4k5fW442-5kb0oRV8lLzd1Ozw&bvm=bv.148747831,d.dGo" target="_blank">Tribal Unity</a> last year, the questions started arriving far more frequently. <br />
<br />
After a particularly productive spurt of writing over my Christmas Holidays I was starting to think it might be feasible so I began to toy with the objective of publishing a book by the end of the year. Em had used a book writing retreat as a focusing tool, so it seemed like planning to hole up in a holiday house for a few weeks late in the year would be a necessary ingredient but that was far away (and a large commitment) so the whole thing still felt very daunting. <br />
<br />
As I focused in on the first quarter, the idea for an objective to commit to scheduling the writing retreat emerged. Then the tough part came – what were the quantitative measures that would work as Key Results? Having now facilitated a number of OKR setting workshops, I'm coming to learn that Objectives are easy, but Key Results is where the brain really has to engage. My first endeavors to apply it personally were no exception. Eventually, I came to the realization that I needed to measure confidence. Confidence that I could generate enough material, and confidence that people would be interested in reading the book. After a long wrestle, I reached a definition:<br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhp8VWWPlLKioe_4KPMPkkQwAQdQyQ9JN3ZbW_xxJ1zfH_G8jY8VXp_-VB4J_S3Z6I3QebdHMrwj1_WrO6u1Ar0GOrVgqDyWnjwOQIK-yBAZ8XCWz2ZYfyOyJ4lJwW4D5jimeE55W66w4Wk/s1600/Personal+OKR+Example.JPG" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="161" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhp8VWWPlLKioe_4KPMPkkQwAQdQyQ9JN3ZbW_xxJ1zfH_G8jY8VXp_-VB4J_S3Z6I3QebdHMrwj1_WrO6u1Ar0GOrVgqDyWnjwOQIK-yBAZ8XCWz2ZYfyOyJ4lJwW4D5jimeE55W66w4Wk/s400/Personal+OKR+Example.JPG" width="400" /></a></div>
<br />
<br />
<h3>
Working the Objectives</h3>
As Wodtke states when concluding Radical Focus, “<i>The Google implementation of OKRs is quite different than the one I recommend here</i>”. Given that I had started with her work, I was quite curious to spot the differences as I read through Google’s guidance. At first, it seemed very subtle. The biggest difference I could see was that for Google not all objectives were stretch. Then the gap hit me. Wodtke added a whole paradigm for working your way towards the objective with a lightweight weekly cycle. I had loved it, as I’d mentally translated it to “weekly iterations”.<br />
<br />
The model was simple. At the start of each week, set three “Priority 1” goals and two “Priority 2” goals that would move you towards your objectives. At the end of the week, celebrate your successes and reflect on your insights. Whilst she had a lot more to offer on application and using the weekly goals as a lightweight communication tool, the simplicity was very appealing personally. After all, I had a “day job” training and coaching. My personal objectives were always going to be extra-curricular so I wanted a lightweight focusing tool.<br />
<br />
Whilst writing a book was not my only objective, it was one of two so features heavily in my weekly priorities. Following is an example excerpt:<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgCrqD7GbadIVAs0t7ZKnfZrvnZTRH0oj5kf4J3NDp92oY6_nvTbgfNfYdaKFFUFqsV-PWRmovK78ehKB0F9ADX958aeyCjkcZAS2EK1a-Mpmf0T-y7lLfj0xd10kRBZoryKsKeR8qn-Fmb/s1600/Weekly+Priorities+Log.JPG" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="350" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgCrqD7GbadIVAs0t7ZKnfZrvnZTRH0oj5kf4J3NDp92oY6_nvTbgfNfYdaKFFUFqsV-PWRmovK78ehKB0F9ADX958aeyCjkcZAS2EK1a-Mpmf0T-y7lLfj0xd10kRBZoryKsKeR8qn-Fmb/s640/Weekly+Priorities+Log.JPG" width="640" /></a></div>
<div>
<div>
<br /></div>
<div>
<b>Clarifying notes:</b></div>
<div>
<ul>
<li>Oakleigh is a suburb near me with a big Greek population. They have a bunch of late night coffee shops, and its my favorite place to write. I head up at 10pm after the kids are in bed and write until they kick me out around 2am. This article is being written from my newly found “Brisbane Oakleigh”.</li>
<li>In week 2 I utilised OKRs in an executive strategy workshop I was facilitating (with a fantastic result), and shared the concept with a friend who was struggling with goal clarity. In both cases, I used my writing OKR as an example </li>
</ul>
</div>
<div>
<br /></div>
<h3>
Conclusion</h3>
<div>
Hopefully by this point you are both starting to understand the notion of the OKR and perhaps inspired enough to read some of the source material that covers it more fully. I can’t recommend Radical Focus highly enough. It’s an easy read, fable style (think The Goal, The Phoenix Project). </div>
<div>
<br /></div>
<div>
You might have noticed along the way that my priority goal this week was to “Publish OKR article”. As seems to happen regularly to me, once I start exploring an idea it becomes too big for one post. I never actually got to the “SAFe” part of OKRs. To whet your appetite, here are some things I plan to address in the second article:</div>
<div>
<br />
<ul>
<li>Specifying OKRs as part of a Feature Definition</li>
<li>Applying OKR thinking to PI Objectives</li>
<li>Applying OKR thinking to Inspect and Adapt and Retrospective Outcomes</li>
</ul>
</div>
</div>
<div>
<br /></div>
<div>
<br /></div>
Mark Richardshttp://www.blogger.com/profile/12477809828045353101noreply@blogger.com4tag:blogger.com,1999:blog-7030397814607511868.post-14392184568092906822017-02-26T04:29:00.000-08:002017-08-10T02:27:47.637-07:00Getting from Idea to Value with the ART Program Kanban<h3>
Introduction</h3>
<br />
Readers of this blog will be no strangers to the fact that I'm a strong believer in the value of kanban visualization at all levels of the SAFe implementation. Further, if you've been reading my <a href="http://www.agilenotanarchy.com/2017/01/revamping-safes-program-level-pi.html" target="_blank">Metrics Series</a> you may have been wondering how to collect all those <a href="http://www.agilenotanarchy.com/2017/02/revamping-safes-program-level-pi.html" target="_blank">Speed Metrics</a>.<br />
<br />
Given that the Feature is the primary unit of "small batch value flow" in SAFe, effective application of kanban tools to the feature life-cycle is critical in supporting study and improvement of the flow of value for an Agile Release Train (ART).<br />
<br />
The first application for most ARTs is enabling flow in the identification and preparation of Features for PI planning. Many ARTs emerge from their first PI planning promising themselves to do a better job of starting early on identifying and preparing features for their next PI only to suddenly hit panic-stations 2 weeks out from the start of PI 2. The introduction of a kanban to visualize this process is extremely valuable in starting to create visibility and momentum to solving the problem.<br />
<br />
However, I vividly remember the debate my colleague <a class="g-profile" href="https://plus.google.com/116452192195762487608" target="_blank">+Em Campbell-Pretty</a> and I had with <a class="g-profile" href="https://plus.google.com/111678440224086860538" target="_blank">+Dean Leffingwell</a> and <a class="g-profile" href="https://plus.google.com/113589473580910466172" target="_blank">+Alex Yakyma</a> regarding their proposed implementation of the <a href="http://www.scaledagileframework.com/program-and-solution-kanbans/" target="_blank">SAFe Program Kanban</a> over drinks at the 2015 SAFe Leadership Retreat in Scotland. Their initial cut positioned the job of the program kanban as "delivering features to PI planning", whilst we both felt the life-cycle needed to extend all the way to value realization. This was in part driven by our shared belief that a feature kanban made a great visualization to support Scrum-of-Scrums during PI execution but primarily by our drive to enable optimization of the full “Idea to Value” life-cycle. Dean bought in and adjusted the representation in the framework (the graphic depicting the backlog as an interim rather than an end-state was in fact doodled by Em on her iPad during the conversation).<br />
<br />
A good Kanban requires a level of granularity appropriate to exposing the bottlenecks, queues and patterns throughout the life-cycle. Whilst the model presented in SAFe acts much as the Portfolio Kanban in identifying the overarching life-cycle states, it leaves a more granular interpretation as an exercise for the implementer. <br />
<br />
Having now built (and rebuilt) many Program Kanban walls over the years while coaching, I've come to a fairly standard starting blueprint (depicted below). This article will cover the purpose and typical usage of each column in the blueprint. <br />
<br />
<div class="separator" style="clear: both; text-align: center;">
</div>
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhm01bCtYNKL_SJ1Udvi4XXrC674TlTw5fpmMz_9myT2FqzfpgqN7yP-PeYqG2-2VwlPIyOO5PlWuvI3hHhlHOStK_ygaRvzK7Zn9pWHYIrL4j-U1lJJeL67djyjN8I13m8DiGKit4hENJz/s1600/Feature+Kanban.JPG" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="326" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhm01bCtYNKL_SJ1Udvi4XXrC674TlTw5fpmMz_9myT2FqzfpgqN7yP-PeYqG2-2VwlPIyOO5PlWuvI3hHhlHOStK_ygaRvzK7Zn9pWHYIrL4j-U1lJJeL67djyjN8I13m8DiGKit4hENJz/s640/Feature+Kanban.JPG" width="640" /></a></div>
<br />
<br />
<b>Note:</b> My <a href="http://www.agilenotanarchy.com/2017/01/tips-for-designing-and-leveraging-great.html" target="_blank">previous article on Kanban tips-and-tricks</a> is worthwhile pre-reading in order to best understand and leverage the presented model. Avatars should indicate both Product Management team members and Development teams associated with the Feature as it moves through its life-cycle.<br />
<br />
<h4>
Background thinking</h4>
The fundamental premise of lean is global optimization of the flow from idea to value. Any truly valuable Feature Kanban will cover this entire life-cycle. The reality is that many ARTs do not start life in control of the full cycle, but I believe this should not preclude visualization and monitoring of the full flow. In short, “don’t let go just because you’re not in control”. If you’re not following the feature all the way into production and market realization you’re missing out on vital feedback.<br />
<br />
<h3>
The Kanban States</h3>
<br />
<h4>
Funnel</h4>
This is the entry point for all new feature ideas. They might arrive here as features decomposed out of the Epic Kanban, features decomposed from Value Stream Capabilities, or as independently identified features. In the words of SAFe, "All new features are welcome in the Feature Funnel". <br />
No action occurs in this state, it is simply a queue with (typically) no exit policies.<br />
<br />
<h4>
Feature Summary</h4>
In this state, we prepare the feature for prioritization. My standard recommendation is that ARTs adopt a "half to one page summary" Feature Template (sample coming soon in a future article).<br />
<br />
Exit Policies would typically dictate that the following be understood about the feature in order to support an effective Cost of Delay estimation and WSJF calculation:<br />
<br />
<ul>
<li>Motivation (core problem or opportunity)</li>
<li>Desired outcomes</li>
<li>Key stakeholders and impacted users</li>
<li>Proposed benefits (aligned to Cost of Delay drivers)</li>
<li>Key dependencies (architectural or otherwise)</li>
<li>Very rough size.</li>
</ul>
<h4>
</h4>
<h4>
Prioritization</h4>
<br />
Features are taken to Cost of Delay estimation workshop, WSJF calculated, and either rejected or approved to proceed to the backlog.<br />
<br />
Exit Policies would typically indicate:<br />
<br />
<ul>
<li>Initial Cost of Delay agreed</li>
<li>WSJF calculated</li>
<li>Feature has requisite support to proceed.</li>
</ul>
<br />
<h4>
Backlog</h4>
This is simply a holding queue. We have a feature summary and a calculated WSJF. Features are stored here in WSJF order, but held to avoid investing more work in analysis until the feature is close to play. If applying a WIP limit to this state, it would likely be based on ART capacity and limited to 2-3 PI's capacity.<br />
<br />
Exit Policies would typically surround confirmation that the Feature has been selected as a candidate for the next PI and any key dependencies have been validated sufficiently to support the selection. I find most Product Management teams will make a deliberate decision at this point rather than just operating on “pull from backlog when ready”.<br />
<br />
<h4>
Next PI Candidate</h4>
Again, this state is simply a holding queue. Movement from the “Backlog” to this state indicates that the Feature can be pulled for “Preparation” when ready. <br />
<br />
Generally, there are no exit policies, but I like to place a spanning WIP limit over this and the following state (Preparing). The logical WIP limit is based on capacity rather than number of features, and should roughly match the single-PI capacity of the ART.<br />
<br />
<h4>
Preparing</h4>
Here, we add sufficient detail to the Feature to enable it to be successfully planned. The Exit Policy is equivalent to a “Feature Definition of Ready”. Typically, this would specify the following:<br />
•<span class="Apple-tab-span" style="white-space: pre;"> </span>Acceptance Criteria Complete<br />
•<span class="Apple-tab-span" style="white-space: pre;"> </span>Participating Dev Teams identified and briefed<br />
•<span class="Apple-tab-span" style="white-space: pre;"> </span>Dependencies validated and necessary external alignment reached<br />
•<span class="Apple-tab-span" style="white-space: pre;"> </span>High level Architectural Analysis complete<br />
•<span class="Apple-tab-span" style="white-space: pre;"> </span>Journey-level UX complete<br />
•<span class="Apple-tab-span" style="white-space: pre;"> </span>Required Technical Spikes complete<br />
<br />
This is the one state in the Feature Kanban that is almost guaranteed to be decomposed to something more granular when applied. The reality is that feature preparation involves a number of activities, and the approach taken will vary significantly based on context. A decomposition I have often found useful is as follows:<br />
<br />
<ul>
<li>Product Owner onboarding (affected Product Owners are briefed on the Feature by Product Management and perform some initial research, particularly with respect to expected benefits)</li>
<li>Discovery Workshops (led by Product Owner(s) and including affected team(s), architecture, UX and relevant subject matter experts to explore the feature and establish draft acceptance criteria and high level solution options)</li>
<li>Finalization (execution of required technical spikes, validation of architectural decisions, finalization of acceptance criteria, updates to size and benefit estimates).</li>
</ul>
<br />
<br />
<h4>
Planned </h4>
The planning event itself is not represented on the Kanban, but following the conclusion of PI planning all features which were included in the plan are pulled from "Preparing " to "Planned".<br />
<br />
This is a queue state. Just because a feature was included in the PI plan does not mean teams are working on it from Day 1 of the PI. We include it deliberately to provide more accuracy (particularly with respect to cycle time) to the following states. There are generally no exit policies.<br />
<br />
<h4>
Executing </h4>
A feature is pulled into this state the instant the first team pulls the first story for it into a Sprint, and the actual work done here is the build/test of the feature.<br />
<br />
Exit policies are based on the completion of all story level build/test activities and readiness for feature level validation. Determination of appropriate WIP limit strategies for this state will emerge with time and study. In the beginning, the level of WIP observed here provides excellent insight into the alignment strategy of the teams and the effectiveness of their observation of Feature WIP concepts during PI planning.<br />
<br />
<h4>
Feature Validation</h4>
A mature ART will eliminate this state (given that maturity includes effective DevOps). However, until such time as the ART reaches maturity, the type of activities we expect to occur here are:<br />
<br />
<ul>
<li>Feature-level end-to-end testing</li>
<li>Feature UAT</li>
<li>Feature-level NFR validation</li>
</ul>
<br />
Exit Policies for this state are equivalent to a “Feature Definition of Done”. They are typically based around readiness of the feature for Release level hardening and packaging. The size of the queues building in this Done state will provide excellent insights into the batch-size approach being taken to deployments (and "time-in-state" metrics will reveal hard data about the cost of delay of said batching).<br />
<br />
<h4>
Release Validation</h4>
Once again, a mature ART will eliminate this state. Until this maturity is achieved we will see a range of activities occurring here around pre-deployment finalization.<br />
<br />
Exit Policies will be the equivalent of a <a href="http://www.scaledagileframework.com/release/" target="_blank">"Release Definition of Done"</a>, and might include:<br />
<br />
<ul>
<li>Regression Testing complete</li>
<li>Release-level NFR Validation (eg Penetration, Stress and Volume Testing) complete</li>
<li>Enterprise-level integration testing complete</li>
<li>Deployment documentation finalized </li>
<li>Deployment approvals sought and granted and deployment window approved</li>
</ul>
<br />
<br />
The set of features planned for release packaging will be pulled as a batch from "Feature Validation" into this state, and the set of features to be deployed (hopefully the same) will progress together to “Done” once the exit policies are fulfilled.<br />
<br />
<h4>
Deployment</h4>
Yet another "to-be-eliminated" state. When the ARTs DevOps strategy matures, this state will last seconds - but in the meantime it will often last days. The batch of features sitting in "Release Hardening" will be simultaneously pulled into this state at the commencement of Production Deployment activities, and moved together to Done at the conclusion of post-deployment verification activities. <br />
<br />
Exit Policies will be based on enterprise deployment governance policy. For many of my clients, they are based on the successful completion of a Business Verification Testing (BVT) activity where a number of key business SME’s manually verify a set of mission-critical scenarios prior to signalling successful deployment.<br />
<br />
<h4>
Operational Readiness</h4>
This state covers the finalization of operational readiness activities. An ART that has matured well along Lean lines will already have performed much of the operational readiness work prior to deployment, but we are interested in the gap between "Feature is available" and "Feature is realizing value". Typical activities we might see here depend on whether the solution context is internal or external, but might include:<br />
<br />
<ul>
<li>Preparation and introduction of Work Instructions</li>
<li>Preparation and Delivery of end-user training</li>
<li>Preparation and execution of marketing activities</li>
<li>Education of sales channel</li>
</ul>
<br />
Exit Policies should be based around “first use in anger” by a production user in a real (non-simulated) context.<br />
<br />
<h4>
Impact Validation</h4>
A (hopefully not too) long time ago, our feature had some proposed benefits. It's time to see whether the hypothesis was correct (the Measure and Learn cycles in Lean Startup). I typically recommend this state be time-boxed to 3 months. During this time, we are monitoring the operational metrics which will inform the correlation between expected and actual benefits.<br />
<br />
Whilst learning should be harvested and applied regularly throughout this phase, it should conclude with some form of postmortem, with participants at minimum including Product Management and Product Owners but preferably also relevant subject matter experts, the RTE and representative team members. Insights should be documented, and fed back into the Program Roadmap.<br />
Exit Policies would be based upon the completion of the “learning validation workshop” and the incorporation of the generated insights into the <a href="http://www.scaledagileframework.com/roadmap/" target="_blank">Program Roadmap</a>.<br />
<br />
<h4>
Done</h4>
Everybody needs a "brag board"! <br />
<h3>
<br />Conclusion</h3>
Once established, this Kanban will provide a great deal of value. Among other things, it can support:<br />
<br />
<ul>
<li>Visualization and maintenance of the Program Roadmap</li>
<li>Management of the flow of features into the PI</li>
<li>Visualization of the current state of the PI to support Scrum of Scrums, PO Sync, executive gemba walks, and other execution steering activities.</li>
<li>Visualization and management (or at least monitoring) of the deployment, operational rollout and outcome validation phases of the feature life-cycle.</li>
<li>Collection of cumulative flow and an abundance of Lead and Cycle time metrics at the Feature level.</li>
</ul>
<br />
<div>
<br /></div>
Mark Richardshttp://www.blogger.com/profile/12477809828045353101noreply@blogger.com11tag:blogger.com,1999:blog-7030397814607511868.post-9866694774739436342017-02-18T06:43:00.000-08:002017-02-18T06:43:00.653-08:00Revamping SAFE's Program Level PI Metrics - Conclusion<blockquote class="tr_bq">
“<i>Base controls on relative indicators and trends, not on variances against plan</i>” – <a href="https://www.google.com.au/url?sa=t&rct=j&q=&esrc=s&source=web&cd=3&cad=rja&uact=8&ved=0ahUKEwidy-TX7JnSAhUKPrwKHSVBCeYQFggjMAI&url=https%3A%2F%2Fwww.amazon.com%2FImplementing-Beyond-Budgeting-Unlocking-Performance%2Fdp%2F0470405163&usg=AFQjCNEoF3ylI06J5SBfsYrPZLHYY-tTNA&bvm=bv.147448319,d.dGc" target="_blank">Bjarte Bogsnes, Implementing Beyond Budgeting</a></blockquote>
<br />
<h3>
Introduction</h3>
The series began with an <a href="http://www.agilenotanarchy.com/2017/01/revamping-safes-program-level-pi.html" target="_blank">overview of a metric model</a> defined to address the following question:<br />
<blockquote class="tr_bq">
"<i>Is the ART sustainably improving in its ability to generate value through the creation of a passionate, results-oriented culture relentlessly improving both its engineering and product management capabilities?</i>"</blockquote>
The ensuing posts delved into the definitions and rationale for the <a href="http://www.agilenotanarchy.com/2017/01/revamping-safes-program-level-pi_19.html" target="_blank">Business Impact</a>, <a href="http://www.agilenotanarchy.com/2017/01/revamping-safes-program-level-pi_25.html" target="_blank">Culture</a>, <a href="http://www.agilenotanarchy.com/2017/01/revamping-safes-program-level-pi_30.html" target="_blank">Quality</a> and <a href="http://www.agilenotanarchy.com/2017/02/revamping-safes-program-level-pi.html" target="_blank">Speed</a> quadrants. In this final article, I will address dashboard representation, implementation and application.<br />
<br />
<h3>
Dashboard Representation</h3>
The model is designed such that the selected set of metrics will be relatively stable unless the core mission of the ART changes. The only expected change would result from either refinement of the fitness function or incorporation of the advanced measures as the ART becomes capable of measuring them.<br />
<div>
<br /></div>
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgmcar0jpAyTGlC_KWzZNXEilpl0lss1YVm35H_uXnea6rTtroI4sXzs8uujt9FCddiottl4D_JCJ32ZuPPtmT6qdTvRTRZ8XHYhrVrTpHJ6kueqfaRRFW-Dh8I0_hfn2j4moCsmaS7dDxb/s1600/ART+PI+Metric+Dashboard.JPG" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="338" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgmcar0jpAyTGlC_KWzZNXEilpl0lss1YVm35H_uXnea6rTtroI4sXzs8uujt9FCddiottl4D_JCJ32ZuPPtmT6qdTvRTRZ8XHYhrVrTpHJ6kueqfaRRFW-Dh8I0_hfn2j4moCsmaS7dDxb/s640/ART+PI+Metric+Dashboard.JPG" width="640" /></a></div>
<div>
<br /></div>
<div>
Given that our focus is on trend analysis rather than absolutes, my recommendation is that for each measure the dashboard reflects the vale for the PI just completed, the previous PI and the average of the last 3 PI’s. Given the assumption that most will initially implement the dashboard in Excel (<a href="https://www.dropbox.com/s/oyhg6fe0c9ohpmj/Program%20PI%20Metrics.xlsx?dl=0" target="_blank">sample available here</a>), I would further suggest the use of conditional formatting to color-code movement (dark green for strongly positive through dark red for strongly negative). </div>
<div>
<br /></div>
<div>
<h3>
Implementation</h3>
<div>
In <a href="https://www.google.com.au/url?sa=t&rct=j&q=&esrc=s&source=web&cd=1&cad=rja&uact=8&ved=0ahUKEwjvo_ir7pnSAhVLvLwKHermDgEQFggZMAA&url=https%3A%2F%2Fwww.amazon.com%2FArt-Business-Value-Mark-Schwartz%2Fdp%2F1942788045&usg=AFQjCNGGbhf2FcFjbb5MGXOlHYh3NxiJpg&bvm=bv.147448319,d.dGc" target="_blank">The Art of Business Value</a>, Mark Schwartz proposes the idea of “<i>BI-Driven Development (BIDD?)</i>”. His rationale? “<i>In the same sense that we do Test-Driven-Development, we can set up dashboards in the BI or reporting system that will measure business results even before we start writing our code</i>”.</div>
<div>
<br /></div>
<div>
I have long believed that if we are serious about steering product strategy through feedback, every ART should either have embedded analytics capability or a strong reach into the organisation’s analytics capability. While the applicability extends far beyond the strategic dashboard (ie per Feature), I would suggest the more rapidly one can move from a manually collated and completed spreadsheet to an automated analytics solution the more effective the implementation will be.</div>
<div>
<br /></div>
<div>
Virtually every metric on the dashboard can be automatically captured, whether it be from the existing enterprise data-warehouse for Business Metrics, the Feature Kanban in the agile lifecycle management tool, Sonarqube, the logs of the Continuous Integration and Version Control tools or the Defect Management System. Speed and Quality will require deliberate effort to configure tooling such that the metrics can be captured, and hints as to approach were provided in the rationales of the relevant deep-dive articles. NPS metrics will require survey execution, but are relatively trivial to capture using such tools as <a href="http://www.surveymonkey.com/" target="_blank">Survey Monkey</a>.</div>
<div>
<br /></div>
<h4>
Timing</h4>
<div>
I cannot recommend base-lining your metrics prior to ART launch strongly enough. If you do not know where you are beginning, how will you understand the effectiveness of your early days? Additionally, the insights derived from the period from launch to end of first PI can be applied in improving the effectiveness of subsequent ART launches across the enterprise.</div>
<div>
<br /></div>
<div>
With sufficient automation, the majority of the dashboard can be in a live state throughout the PI, but during the period of manual collation the results should be captured in the days leading up to the Inspect & Adapt workshop.</div>
<div>
<br /></div>
<h3>
Application</h3>
<div>
The correct mindset is essential to effective use of the dashboard. It should be useful for multiple purposes:</div>
<div>
<ul>
<li>Enabling the Portfolio to steer the ART and the accompanying investment strategy</li>
<li>Enabling enterprise-level trend analysis and correlation across multiple ARTs</li>
<li>Improving the effectiveness of the ART’s Inspect and Adapt cycle</li>
<li>Informing the strategy and focus areas for the <a href="http://www.scaledagileframework.com/LACE/" target="_blank">Lean Agile Centre of Excellence (LACE)</a></li>
</ul>
</div>
<div>
Regardless of application specifics, our focus is on trends and global optimization. Are the efforts of the ART yielding the desired harvest, and are we ensuring that our endeavors to accelerate positive movement in a particular area are not causing sub-optimizations elsewhere in the system?</div>
<div>
<br /></div>
<div>
It is vital to consider the dashboard as a source not of answers, but of questions. People are often puzzled by the Taiichi Ohno quote “<i>Data is of course important … but I place the greatest emphasis on facts</i>”. Clarity lies in appreciating his emphasis on not relying on reports, but rather going to the “<a href="https://www.google.com.au/url?sa=t&rct=j&q=&esrc=s&source=web&cd=2&cad=rja&uact=8&ved=0ahUKEwjG0K-775nSAhXHUbwKHWWmDvoQFggbMAE&url=https%3A%2F%2Fen.wikipedia.org%2Fwiki%2FGemba&usg=AFQjCNG8HwD-fV9m7n5ZdvRCt8LIVyrfzg&bvm=bv.147448319,d.dGc" target="_blank">gemba</a>”. For me, the success of the model implementation lies in the number and quality of questions it poses. The only decisions made in response to the dashboard should be what areas of opportunity to explore – and of course every good question begins with why. For example:</div>
<div>
<ul>
<li>Why is our feature execution time going down but our feature lead time unaffected?</li>
<li>Why has our deployment cycle time not reduced in response to our DevOps investment?</li>
<li>Why is Business Owner NPS going up while Team NPS is going down?</li>
<li>Why is our Program Predictability high but our Fitness Function yield low?</li>
<li>Why is our Feature Lead Time decreasing but our number of production incidents rising?</li>
</ul>
</div>
<div>
<br /></div>
<h3>
Conclusion</h3>
<div>
It’s been quite a journey working through this model, and I’m grateful for all the positive feedback I have received along the way. The process has inspired me to write a number of supplementary articles. </div>
<div>
<br /></div>
<div>
The first of these is a detailed coverage of the Feature Kanban (also known as the Program Kanban). Numerous people have queried me as to the most effective way of collecting the Speed Metrics, and this becomes trivial with the development an effective Feature Kanban (to say nothing of the other benefits).</div>
<div>
<br /></div>
<div>
I’ve also wound up doing a lot of digging into <a href="https://www.google.com.au/url?sa=t&rct=j&q=&esrc=s&source=web&cd=3&cad=rja&uact=8&sqi=2&ved=0ahUKEwiUwbb375nSAhVEzbwKHaiDAT0QFggtMAI&url=http%3A%2F%2Feleganthack.com%2Fthe-art-of-the-okr%2F&usg=AFQjCNFtWX10jfDSU1FTjuMAHwWH4261cw&bvm=bv.147448319,d.dGc" target="_blank">“Objectives and Key Results” (OKR’s)</a>. Somehow the growing traction of this concept had passed me by, and when my attention was first drawn to it I panicked at the thought it might invalidate my model before I had even finished publishing it. However, my research concluded that the concepts were complementary rather than conflicting. You can expect an article exploring this to follow closely on the heels of my Feature Kanban coverage.</div>
<div>
<br /></div>
<div>
There is no better way to close this series than with a thought from Deming reminding us of the vital importance of mindset when utilising any form of metric.</div>
<blockquote class="tr_bq">
“<i>People with targets and jobs dependent upon meeting them will probably meet the targets – even if they have to destroy the enterprise to do it</i>.” – W. Edwards Deming</blockquote>
<div>
</div>
</div>
<div>
<br /></div>
Mark Richardshttp://www.blogger.com/profile/12477809828045353101noreply@blogger.com2tag:blogger.com,1999:blog-7030397814607511868.post-72743847417791688752017-02-05T16:13:00.000-08:002017-02-18T06:46:06.398-08:00Revamping SAFe's Program Level PI Metrics Part 5/6 - Speed<blockquote class="tr_bq">
“<i>Changing the system starts with changing your vantage point so you can ‘see’ the system differently. Development speed is often attributed to quick decisions. Early definition of the requirements and freezing specification quickly are often highlighted as keys to shortening the product development cycle. Yet the key steps required to bring a new product to market remain the creation and application of knowledge, regardless of how quickly the requirements are set. The challenge in creating an effective and efficient development system lies in shortening the entire process.</i>” – <a href="https://www.google.com.au/url?sa=t&rct=j&q=&esrc=s&source=web&cd=2&cad=rja&uact=8&ved=0ahUKEwiqiO3jl_rRAhXJKZQKHfT5AIsQFgghMAE&url=https%3A%2F%2Fwww.amazon.com%2FLean-Machine-Harley-Davidson-Profitability-Revolutionary%2Fdp%2F0814432883&usg=AFQjCNESSGxz-tZINqZzOUQV8piO8aFxvA&bvm=bv.146094739,d.dGo" target="_blank">Dantar Oosterwal, The Lean Machine.</a></blockquote>
<br />
<h3>
Series Context</h3>
•<span class="Apple-tab-span" style="white-space: pre;"> </span><a href="http://www.agilenotanarchy.com/2017/01/revamping-safes-program-level-pi.html" target="_blank">Part 1 – Introduction and Overview</a><br />
•<span class="Apple-tab-span" style="white-space: pre;"> </span><a href="http://www.agilenotanarchy.com/2017/01/revamping-safes-program-level-pi_19.html" target="_blank">Part 2 – Business Impact Metrics</a><br />
•<span class="Apple-tab-span" style="white-space: pre;"> </span><a href="http://www.agilenotanarchy.com/2017/01/revamping-safes-program-level-pi_25.html" target="_blank">Part 3 – Culture Metrics</a><br />
•<span class="Apple-tab-span" style="white-space: pre;"> </span><a href="http://www.agilenotanarchy.com/2017/01/revamping-safes-program-level-pi_30.html" target="_blank">Part 4 – Quality Metrics</a><br />
•<span class="Apple-tab-span" style="white-space: pre;"> </span><span style="color: lime;">Part 5 – Speed Metrics (You are here)</span><br />
•<span class="Apple-tab-span" style="white-space: pre;"> </span><a href="http://www.agilenotanarchy.com/2017/02/revamping-safes-program-level-pi_18.html" target="_blank">Part 6 – Conclusion and Implementation</a><br />
<div>
<br /></div>
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgu2UBGtUnOSFGeZAWPvPxDRz0TysByhz5qUl0hyoKqtRyorz2vE_mtrKGwOl0L0qBY5QxKYScTacS5zUPcO4XpyW-099ux79LsuVrOBYRnK729gHZiadKycpghrKIJlNS6cCTK4pkVttN8/s1600/Speed+Quadrant.JPG" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="372" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgu2UBGtUnOSFGeZAWPvPxDRz0TysByhz5qUl0hyoKqtRyorz2vE_mtrKGwOl0L0qBY5QxKYScTacS5zUPcO4XpyW-099ux79LsuVrOBYRnK729gHZiadKycpghrKIJlNS6cCTK4pkVttN8/s640/Speed+Quadrant.JPG" width="640" /></a></div>
<div>
<br /></div>
<div>
<h3>
Introduction</h3>
<div>
As mentioned in <a href="http://www.agilenotanarchy.com/2017/01/revamping-safes-program-level-pi_30.html" target="_blank">my last post</a>, the categorization of metrics went through some significant reshaping in the review process. The “Speed” (or “Flow”) quadrant didn’t exist, with its all-important metrics divided between “Business Impact” and “Deployment Health”. </div>
<div>
<br /></div>
<div>
Lead Time is arguably the most important metric in Lean, as evidenced by Taiicho Ohno’s famous statement that “<i>All we are doing is looking at the customer time line, from the moment the customer gives us the order to the point when we collect the cash</i>”. Not only does it measure our (hopefully) increasing ability to respond rapidly to opportunity, but is a critical ingredient in enabling a focus on global rather than local optimization.</div>
<div>
<br /></div>
<div>
In this quadrant, the core focus is to employ two perspective views on Lead Time. The first (Feature Lead Time) relates to the delivery of feature outcomes, and the second (MTTR from Incident) our ability to rapidly recover from production incidents.</div>
<div>
<br /></div>
<div>
The other proposed metrics highlight the cycle time of key phases in the idea-to-value life-cycle as an aid to understanding “where we are slow, and where we are making progress”. In particular, they will highlight failure to gain traction in XP and DevOps practices.</div>
<div>
<br /></div>
<div>
There is, however, a caveat. Many (if not most) Agile Release Trains do not begin life in control of the entire idea-to-value life-cycle. On the one hand, its very common for features to be handed off to an enterprise release management organisation for production release. On the other, whilst Lean Principles are at the heart of SAFe the framework centers on hardware/software development. The (traditionally business) skill-sets in areas such as operational readiness, marketing and sales required to move from “Deployed product” to “Value generating product” are nowhere on the big picture. </div>
<div>
<br />
ARTs focused on bringing to life the SAFe principles will address these gaps as they inspect and adapt, but in the meantime there is a temptation to “not measure what we are not in control of”. As a coach, I argue that ARTs should “never let go until you’ve validated the outcome”. You may not be in control, but you should be involved – if for nothing else than in pursuit of global optimization. </div>
<div>
<br /></div>
<h3>
Basic Definitions</h3>
</div>
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhGP1JmTiYfkrD70VHeIZmWPq5IGgNnYgO2pJ0ZyUdkwcJBAvDq-ak3fILXnqYxXN-Az-a2LovDFRSZAWfSF8JEfnnnnhSnhs353PJjj1XzQuovNJkPTBzEEUJWGHU_AmXJr0UgiaXogb5v/s1600/Speed+Metrics+Basic+Definitions.JPG" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="310" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhGP1JmTiYfkrD70VHeIZmWPq5IGgNnYgO2pJ0ZyUdkwcJBAvDq-ak3fILXnqYxXN-Az-a2LovDFRSZAWfSF8JEfnnnnhSnhs353PJjj1XzQuovNJkPTBzEEUJWGHU_AmXJr0UgiaXogb5v/s640/Speed+Metrics+Basic+Definitions.JPG" width="640" /></a></div>
<div>
<br /></div>
<div>
<h3>
Basic Metrics Rationale</h3>
<h4>
Average Feature Lead Time (days)</h4>
<div>
This is the flagship metric. However, the trick is determining "when the timer starts ticking". For an ART maintaining the recommended 3-PI roadmap, feature lead time would rarely be shorter than a depressing 9 months. </div>
<div>
</div>
<div>
To measure it, one needs 2 things: A solid <a href="http://www.scaledagileframework.com/program-and-value-stream-kanbans/" target="_blank">Feature Kanban</a>, and agreement on which stage triggers the timer. A good feature kanban will of necessity be more granular the sample illustrated in the framework (fuel for a future post), but the trigger point I most commonly look for is "selection for next PI". In classic kanban parlance, this is the moment when a ticket moves from "backlog" to "To Do", and in most ARTs triggers the deeper preparation activities necessary to prepare a feature for PI planning. The end-point for the measure is the moment at which the feature starts realizing value and is dependent on <a href="http://www.scaledagileframework.com/solution/" target="_blank">solution context</a>, often triggered by deployment for digital solutions but after business change management activities for internal solutions.</div>
<div>
<br /></div>
<h4>
Average Deployment Cycle Time (days)</h4>
<div>
This metric was inspired by the recently released <a href="https://www.amazon.com/DevOps-Handbook-World-Class-Reliability-Organizations/dp/1942788002/ref=sr_1_1?ie=UTF8&qid=1482821875&sr=8-1&keywords=devops+handbook" target="_blank">Devops Handbook</a> by Gene Kim and friends. In essence, we want to measure “time spent in the tail”. I have known ART after ART that accelerated their development cycle whilst never making inroads on their path to production. If everything you build has to be injected in a 3-month enterprise release cycle, its almost pointless accelerating your ability to build! </div>
<div>
</div>
<div>
Whilst our goal is to measure this in minutes, I have selected days as the initial measure as for most large enterprises the starting point will be weeks if not months.</div>
<div>
</div>
<h4>
Average Mean Time to Restore (MTTR) from Incident (mins)</h4>
<div>
When a high severity incident occurs in production, how long does it take us to recover? In severe cases, these incidents can cause losses of millions of dollars per hour. Gaining trust in our ability to safely deploy regularly can only occur with demonstrated ability to recover fast from issues. Further, since these incidents are typically easy to quantify in bottom-line impact, we gain the ability to start to measure the ROI of investment in DevOps enablers.</div>
<div>
</div>
<h4>
Prod Deploys Per PI (#)</h4>
<div>
Probably the simplest measure of all listed on the dashboard - how frequently are we deploying and realizing value?</div>
<div>
<br /></div>
<h3>
Advanced Definitions</h3>
</div>
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEg37jVLiQ_V4jZpQz5rVY8LlgjdiUhOdqTQLab4HMvWZEPRyTBtT5-2Qy9Z5GPdhRhegGLDuUbnuU6KgGglCjkhGYiOnXyJuhMuhF1HQtjCRry_Zl1kpxCmmajjgGVqeA58pC3Za0pTg6lm/s1600/Speed+Metrics+Advanced+Definitions.JPG" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="266" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEg37jVLiQ_V4jZpQz5rVY8LlgjdiUhOdqTQLab4HMvWZEPRyTBtT5-2Qy9Z5GPdhRhegGLDuUbnuU6KgGglCjkhGYiOnXyJuhMuhF1HQtjCRry_Zl1kpxCmmajjgGVqeA58pC3Za0pTg6lm/s640/Speed+Metrics+Advanced+Definitions.JPG" width="640" /></a></div>
<div>
<br /></div>
<div>
<h3>
Advanced Metrics Rationale</h3>
<h4>
Average Feature Execution Cycle Time (days)</h4>
<div>
This is one of the sub-phases of the lead time which are worth measuring in isolation, and is once again dependent on the presence of an appropriately granular feature kanban. </div>
<div>
</div>
<div>
The commencement trigger is "first story played", and the finalization trigger is "feature ready for deployment packaging" (satisfies Feature Definition of Done). The resultant measure will be an excellent indicator of train behaviors when it comes to Feature WIP during the PI. Are they working on all features simultaneously throughout the PI or effectively collaborating across teams to shorten the execution cycles at the feature level?</div>
<div>
<br /></div>
<div>
One (obvious) use of the metric is determination of PI length. Long PI’s place an obvious overhead on Feature Lead Time, but if average Feature Execution time is 10 weeks its pointless considering an 8 week PI. </div>
<div>
<br /></div>
<h4>
Average Deploy to Value Cycle Time (days)</h4>
<div>
This sub-phase of feature lead time measures "how long a deployed feature sits on the shelf before realizing value". </div>
<div>
</div>
<div>
The commencement trigger is "feature deployed", and the finalization trigger is "feature used in anger". It will signal the extent to which true system level optimization is being achieved, as opposed to local optimization for software build. In a digital solution context it is often irrelevant (unless features are being shipped toggled-off in anticipation of marketing activities), but for internal solution contexts it can be invaluable in signalling missed opportunities when it comes to organizational change management and business readiness activities.</div>
<div>
<br /></div>
<h4>
Average Deployment Outage (mins)</h4>
<div>
How long an outage will our users and customers experience in relation to a production deployment? Lengthy outages will severely limit our aspirations to deliver value frequently. </div>
<div>
<br /></div>
<h3>
Conclusion</h3>
<div>
We’ve now covered all 4 quadrants and their accompanying metrics. The next post will conclude the series with a look at dashboard representation, implementation and utilisation. </div>
<div>
<br /></div>
<blockquote class="tr_bq">
“<i>High performers [in Devops practices] were twice as likely to exceed profitability, market share, and productivity goals. And, for those organizations that provided a stock ticker symbol, we found that high performers had 50% higher market capitalization growth over three years.</i>” – <a href="https://www.amazon.com/DevOps-Handbook-World-Class-Reliability-Organizations/dp/1942788002" target="_blank">Gene Kim, Jez Humble, Patrick Debois, John Willis .. The Devops Handbook</a></blockquote>
<div>
<br /></div>
<div>
<br /></div>
</div>
Mark Richardshttp://www.blogger.com/profile/12477809828045353101noreply@blogger.com72tag:blogger.com,1999:blog-7030397814607511868.post-48729465059306630572017-01-30T16:34:00.000-08:002017-02-18T06:46:30.754-08:00Revamping SAFe's Program Level PI Metrics Part 4/6 - Quality<blockquote class="tr_bq">
“<i>The Systems Science Institute at IBM has reported that the cost to fix an error after product release was four to five times as much as one uncovered during design, and up to 100 times more than one identified in the maintenance phase</i>”- <a href="https://www.isixsigma.com/industries/software-it/defect-prevention-reducing-costs-and-enhancing-quality/" target="_blank">iSixSigma magazine</a></blockquote>
<h3>
Series Context</h3>
<br />
<ul>
<li><a href="http://www.agilenotanarchy.com/2017/01/revamping-safes-program-level-pi.html" target="_blank">Part 1 - Introduction and Overview</a></li>
<li><a href="http://www.agilenotanarchy.com/2017/01/revamping-safes-program-level-pi_19.html" target="_blank">Part 2 - Business Impact Metrics</a></li>
<li><a href="http://www.agilenotanarchy.com/2017/01/revamping-safes-program-level-pi_25.html" target="_blank">Part 3 - Culture Metrics</a></li>
<li>Part 4 - Quality Metrics <span style="color: blue;">(You are here)</span></li>
<li><a href="http://www.agilenotanarchy.com/2017/02/revamping-safes-program-level-pi.html" target="_blank">Part 5 - Speed Metrics</a></li>
<li><a href="http://www.agilenotanarchy.com/2017/02/revamping-safes-program-level-pi_18.html" target="_blank">Part 6 - Conclusion and Implementation</a></li>
</ul>
<div class="separator" style="clear: both; text-align: center;">
</div>
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhIa5x9PKJF2o1avB0crqIovP2bkHaOBDLFWO-uZuhIj1tEeuRvWp4OLarPK7yo_x147rpriMh4oHQkLHbLdQocyHpkmSlZV4J0eh5G14b3sD0sGj_iBrG0fIzNS1GSjC_SIff_nRksT_5E/s1600/Quality+Quadrant+Metrics.JPG" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="474" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhIa5x9PKJF2o1avB0crqIovP2bkHaOBDLFWO-uZuhIj1tEeuRvWp4OLarPK7yo_x147rpriMh4oHQkLHbLdQocyHpkmSlZV4J0eh5G14b3sD0sGj_iBrG0fIzNS1GSjC_SIff_nRksT_5E/s640/Quality+Quadrant+Metrics.JPG" width="640" /></a></div>
<div>
<br /></div>
<h3>
Introduction</h3>
<br />
Given the central nature of the “build quality in” mindset to Lean and Agile, my early drafts of the metrics dashboard devoted 3 full categories to quality:<br />
<ul>
<li>Technical Health </li>
<li>Quality </li>
<li>Deployment Health </li>
</ul>
The “quality” aspect of the original cut took a lean lens on the traditional “defect/incident” quality metrics, whilst the other two focused on technical quality and “devops” type quality respectively. <br />
<br />
I was fortunate enough to both get some great review feedback from <a class="g-profile" href="https://plus.google.com/111678440224086860538" target="_blank">+Dean Leffingwell</a> on the drafts and spend some time at a whiteboard brainstorming with him. He dwelt on the fact that I had “too many metrics and too many quadrants” :) As we brainstormed, we came to two conclusions. Firstly, the 3 concepts listed above were just different perspectives on quality – and secondly, we could separate my individual metrics into “the basics everyone should have” and “the advanced things people should have but might take time to incorporate”. The result is the set of basic and advanced definitions below. <br />
<br />
One might question the incorporation of highly technical metrics in an executive dashboard, however there are three very good reasons to do so: <br />
<ul>
<li>If our technical practices are not improving, no amount of process improvement will deliver sustainable change. </li>
<li>If our teams are taking lots of shortcuts to deliver value fast, there is no sustainability to the results being achieved and we will wind up “doing fragile not agile”. </li>
<li>If the executives don’t care, the teams are unlikely to. </li>
</ul>
The only non-subjective way I know to approach this is through <a href="https://en.wikipedia.org/wiki/Static_program_analysis" target="_blank">static code analysis</a>. Given the dominance of <a href="https://www.sonarqube.org/" target="_blank">Sonarqube</a> in this space, I have referenced explicit Sonarqube measures in the definitions. Additionally, effective adoption of Continuous Integration (CI) amongst the developers is not only a critical foundation for DevOps but also an excellent way to validate progress in the “build quality in” mindset space. <br />
<br />
On the “traditional quality measurement” front, my core focus is “are we finding defects early or late”? Thus, I look to both evaluate the timing of our validation activities and the level of quality issues escaping the early life-cycle. For deployment health, all inspiration was sourced from DevOps materials and as we re-structured the overall model it became apparent that many of these measures really belonged in the “Speed” quadrant – all that remained in the quality quadrant was clarity on production incidents.<br />
<div>
<br /></div>
<h3>
Basic Definitions</h3>
<div>
<br /></div>
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjS7rjZlqlWs4rsSGWQYog5k5jOkL1BXekTAnK1aDu17P3SBxVICdigstq4pfr4SxIz9GKEeEXAtPAzozrXTqilzuxiaQL5kdurhLiomxD9JQPzUnA-3bKuuh3GUrswUyqhpDNXtxbRaGnn/s1600/Quality+Basic+Definitions.JPG" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="346" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjS7rjZlqlWs4rsSGWQYog5k5jOkL1BXekTAnK1aDu17P3SBxVICdigstq4pfr4SxIz9GKEeEXAtPAzozrXTqilzuxiaQL5kdurhLiomxD9JQPzUnA-3bKuuh3GUrswUyqhpDNXtxbRaGnn/s640/Quality+Basic+Definitions.JPG" width="640" /></a></div>
<h3>
<br />Basic Metrics Rationale</h3>
<div>
<br /></div>
<div>
<h4>
Unit Test Coverage %</h4>
<div>
As I regularly inform participants in the training room, "<b>if you do not aggressively pursue automated testing your agile implementation will fail!"</b> It is impossible to sustainably employ an iterative and incremental approach to software development without it.</div>
<div>
<br /></div>
<div>
Static analysis tools will not tell you the quality of the unit tests or the meaningfulness of the coverage, but simply having coverage will give the developers confidence to refactor - the key to increasing maintainability. It should also increase the ratio of first fix resolution, giving confidence that defects can be resolved fast and minor enhancements made without causing unintended side effects.</div>
<div>
</div>
<div>
Further, even if automated functional tests are still on the to-do list, testers who can read unit tests will be able to more effectively adopt risk-based manual testing and thus reduce manual test effort.</div>
<div>
</div>
<h4>
Mean Time Between Green Builds (mins)</h4>
<div>
Note that many ARTs will implement multiple CI cycles – local ones executing on branches and a central master cycle on the mainline. Whilst branch-level CI cycles might be of interest at the team level, the only one we are interested in at the ART level is the master on the mainline.</div>
<div>
<br /></div>
<div>
Red CI builds are of course an indicator of poor developer quality practices (failure to locally validate code prior to check-in), and most believe the full CI cycle should occur in under 10 minutes to provide an adequate level of timely feedback to the developers, but failure on either of these fronts will naturally extend the time between green builds, so they need not be discretely measured on the dashboard.</div>
<h4>
<br />Mean Time to Recover from Red build (mins)</h4>
<div>
Two things will cause this metric to trend in the wrong direction. One is lack of the <a href="https://en.wikipedia.org/wiki/Andon_(manufacturing)" target="_blank">Andon</a> mindset (its someone else's fault, or even worse its always red, just ignore it). The second is failure to regularly commit, resulting in complex change-sets and difficult debugging. The second is easily identified through the mean time between Green Builds, so the metric enables measurement of the establishment of the Andon mindset among developers.</div>
<div>
</div>
<h4>
Late Phase Defects #</h4>
<div>
The identification and resolution of defects during the execution of a story is evidence of good team quality practices, and should be excluded from any strategic treatment of defect trends. However, defects identified in functionality associated with a story after its acceptance or in late-phase (integration, performance, security, UAT etc) testing are indicators of a failure to "build quality in". </div>
<div>
</div>
<div>
Whilst many teams do not formally log defects identified during story development, where this is done there will be a need for classification in the defect management system to separate late phase defects for reporting purposes.</div>
<div>
</div>
<h4>
Validation Capacity %</h4>
<div>
Great agile means a story is accepted once it is in production. Good agile means it is accepted once it is ready for production. For most enterprises in the early years of their agile adoption, this seems like a fairy-tale - <a href="http://www.cio.com/article/2980298/it-strategy/what-makes-a-devops-unicorn.html" target="_blank">the DevOps definition of "Unicorns"</a> such as Amazon and Netflix resonates strongly! </div>
<div>
</div>
<div>
The reality is for some time there will be testing and packaging activities which get batched up and executed late in development. Typical examples include:</div>
<div>
<ul>
<li>User Acceptance Testing - of course, the Product Owner as the embedded customer is meant to do this in good agile but for many they are neither sufficiently knowledgeable nor sufficiently empowered.</li>
<li>Integration Testing - in theory redundant if the team is practicing good full-stack continuous integration. But for all too many, environment constraints prohibit this and lead to extensive use of stubs until late phase.</li>
<li>Performance Testing - for many organisations, the performance test environments are congested, hard to book, and take days if not weeks to configure for a performance test run. </li>
<li>Penetration Testing - a highly specialised job with many organisations possessing a handful of skilled penetration testers spread across thousands of developers.</li>
<li>Release Documentation</li>
<li>Mandated Enterprise Level Integration and Deployment preparation cycles for all changes impacting strategic technology assets.</li>
</ul>
</div>
<div>
</div>
<div>
Given that the backlog "<a href="http://www.scaledagileframework.com/team-backlog/" target="_blank">represents the collection of all the things a team needs to do</a>" , all of these activities should appear in backlogs, estimated and prioritized to occur in the appropriate iterations. It is a simple matter to introduce a categorization to the backlog management tool to flag these items as hardening activities.</div>
<h4>
<br />Average Severity 1 and 2 Incidents per Deploy</h4>
</div>
<div>
<div>
High severity incidents associated with deployments are a critical quality indicator. Measurement is generally fairly trivial with the appropriate flagging in incident management systems. However, some debate may exist as to whether an incident is associated with a deployment or simply the exposition of a preexisting condition. An organisation will need to agree on clear classification standards in order to produce meaningful measures.</div>
<div>
</div>
</div>
<h3>
Advanced Definitions</h3>
<div>
<br /></div>
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgiNNZQZgXLRgLdZiPeKOh4rhRXT3ljcd2J4FlH7dSy8zoNBOje1WFhtIAz1D0r33R6WhBYwfDrn8o2LRTK9sWppg4_1Yw7m-pfsXi-rz6LVtKoaa6_zt-Q3efOFHFHh7DUdqNew9xip9Bx/s1600/Quality+Advanced+Definitions.JPG" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="268" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgiNNZQZgXLRgLdZiPeKOh4rhRXT3ljcd2J4FlH7dSy8zoNBOje1WFhtIAz1D0r33R6WhBYwfDrn8o2LRTK9sWppg4_1Yw7m-pfsXi-rz6LVtKoaa6_zt-Q3efOFHFHh7DUdqNew9xip9Bx/s640/Quality+Advanced+Definitions.JPG" width="640" /></a></div>
<div>
<br /></div>
<div>
<h3>
Advanced Metrics Rationale</h3>
<h4>
Duplication %</h4>
<div>
Duplicate code is bad code. Its simple. One line of duplicated business logic is a time-bomb waiting to explode. If this number is trending down, its an indicator developers are starting to refactor, the use of error-prone copy/paste techniques is falling and the maintainability of the source code is going up. Its potentially debatable whether one measures duplicate blocks or duplicate lines, but given the amount of logic possible to embed in a single line of code I prefer the straight up measurement of duplicated lines. </div>
<div>
<br /></div>
<h4>
Average Cyclomatic Complexity</h4>
<div>
Cyclomatic complexity is used to measure the complexity of a program by analyzing the number of linearly independent paths through a program's code. More complexity leads to more difficulty in maintaining or extending functionality and greater reliance on documentation to understand intent. It can be measured at multiple levels, however from a dash-boarding perspective my interest is in function or method level complexity. </div>
<h4>
<br />Average Branch Age at Merge (days)</h4>
<div>
This metric may take a little more work to capture, but it is well worth the effort. The modern ideal is of course not to branch at all (branching by abstraction), however the technical sophistication required by developers to achieve this takes some time to achieve. </div>
<div>
</div>
<div>
Code living in a branch is code that has not been integrated, and thus code that carries risk. The longer the code lives in a branch, the more effort it takes to merge it back into the mainline and the greater the chance that the merge process will create high levels of late-phase defects.</div>
<table align="center" cellpadding="0" cellspacing="0" class="tr-caption-container" style="margin-left: auto; margin-right: auto; text-align: center;"><tbody>
<tr><td style="text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgf1wb0oM7JzUXBxt6qhEiUGhv2D5sNxtG2PYR6hBglr16UV-ZjyZgqbBxurM3Jdk5W56gRg40wFWOzMCOrDtTr-1FQrJQr4qPhxc0ChV0yucTAisx7aLvcndz7lBLWWjDGpszrAqJRCDKf/s1600/Spotted+at+Pivotal.jpg" imageanchor="1" style="margin-left: auto; margin-right: auto;"><img border="0" height="170" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgf1wb0oM7JzUXBxt6qhEiUGhv2D5sNxtG2PYR6hBglr16UV-ZjyZgqbBxurM3Jdk5W56gRg40wFWOzMCOrDtTr-1FQrJQr4qPhxc0ChV0yucTAisx7aLvcndz7lBLWWjDGpszrAqJRCDKf/s400/Spotted+at+Pivotal.jpg" width="400" /></a></td></tr>
<tr><td class="tr-caption" style="text-align: center;">Whiteboard spotted at Pivotal Labs by @testobsessed</td></tr>
</tbody></table>
<div>
<br /></div>
<h4>
Fault Feedback Ratio (FFR) %</h4>
<div>
When it comes to defects, we are interested in not just when we find them but how we respond to them. In his book "<a href="https://www.amazon.com/Quality-Software-Management-First-Order-Measurement/dp/B002JHO40E/ref=sr_1_4?ie=UTF8&qid=1482820840&sr=8-4&keywords=weinberg+quality+software+management" target="_blank">Quality Software Management vol 2: First-Order Measurement</a>, Gerry Weinberg introduced me to the concept (along with many other fascinating quality metrics). Our goal is to determine what happens when we address a defect. Do we resolve it completely? Do we introduce other new defects in resolving the first one? A rising FFR value can indicate poor communication between testers and developers, hacked-in fixes, and deterioration in the maintainability of the application among other things. According to <a class="g-profile" href="https://plus.google.com/105857608500309373482" target="_blank">+Johanna Rothman</a> in <a href="http://www.jrothman.com/articles/2002/11/whats-your-fault-feedback-ratio/" target="_blank">this article</a> (), a value of <= 10% is a good sign.</div>
<div>
</div>
<div>
Measuring it should be trivial with appropriate classifications of defect sources and resolution verification activities in the defect management system.</div>
<div>
<br /></div>
<h4>
Average Open Defects #</h4>
<div>
When it comes to open defects, one needs to make a number of local decisions. Firstly, what severity are we interested in? Restricting it to high severity defects can hide all kinds of quality risk, but at the same time many low severity defects tend to be more matters of interpretation and often represent minor enhancement requests masquerading as defects.</div>
<div>
</div>
<div>
Further, we need to determine whether we are interested in the open count at the end of the PI or the average throughout the PI. A Lean focus on building quality in leads me to be more interested in our every-day quality position rather than what we've cleaned up in our end-of-PI rush.</div>
<div>
<br /></div>
<h3>
Conclusion</h3>
<div>
More than for any other quadrant, I wrestled to find a set of quality metrics small enough not to be overwhelming yet comprehensive enough to provide meaningful insight. At the team level, I would expect significantly more static code analysis metrics (such as “Code Smells”, “Comment Density” and “Afferent Coupling” ) to be hugely valuable. <a href="https://www.linkedin.com/in/kelleyhorton/" target="_blank">Kelley Horton</a> of Net Objectives suggested a Defect Density measure based on “# of production defects per 100 story points released”, and “% capacity allocated to technical debt reduction”. For further inspiration, I can recommend nothing so much as the “<a href="https://www.amazon.com/Quality-Software-Management-First-Order-Measurement/dp/0932633242/ref=sr_1_3?ie=UTF8&qid=1485484049&sr=8-3&keywords=weinberg+quality" target="_blank">Quality Software Managemen</a>t” series by <a class="g-profile" href="https://plus.google.com/116209650372197520745" target="_blank">+Gerald Weinberg</a>.</div>
<div>
<br /></div>
<div>
<br /></div>
<blockquote class="tr_bq">
“<i>You should name a variable with the same care with which you name a first-born child</i>” – Robert C. Martin, Clean Code</blockquote>
<div>
<br /></div>
<div>
<br /></div>
<div>
<br /></div>
<div>
<br /></div>
<div>
<br /></div>
<div>
<br /></div>
<div>
<br /></div>
<div>
<br /></div>
<div>
</div>
<div>
<br /></div>
</div>
<div>
<br /></div>
Mark Richardshttp://www.blogger.com/profile/12477809828045353101noreply@blogger.com21tag:blogger.com,1999:blog-7030397814607511868.post-54364535216019524842017-01-25T20:26:00.000-08:002017-02-18T06:46:56.538-08:00Revamping SAFe's Program Level PI Metrics Part 3/6: Culture<blockquote class="tr_bq">
"<i>Organizational culture can be a major asset or a damaging liability that hinders all efforts to grow and become more successful. Measuring and managing it is something few companies do well.</i>" - Mark Graham Brown, Business Finance Magazine</blockquote>
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiEld5vIoQiVVl6mAIvdZDxyhyphenhyphen3AguFqk3MvTbEZvPeOeMJ4JgdWQfpPmWIJJ5C5EU_Pzs-OUQnZY2xBPQuET3sJEoaMY7EOQkquZWZ_O_v4q5fgejdJQP-FedDb7mvi4XHd7DqbD7i6TT6/s1600/Culture+Quadrant+Metrics.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="321" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiEld5vIoQiVVl6mAIvdZDxyhyphenhyphen3AguFqk3MvTbEZvPeOeMJ4JgdWQfpPmWIJJ5C5EU_Pzs-OUQnZY2xBPQuET3sJEoaMY7EOQkquZWZ_O_v4q5fgejdJQP-FedDb7mvi4XHd7DqbD7i6TT6/s640/Culture+Quadrant+Metrics.png" width="640" /></a></div>
<br />
<br />
<h3>
Introduction</h3>
After <a href="http://www.agilenotanarchy.com/2017/01/revamping-safes-program-level-pi_19.html" target="_blank">exploring the Business Impact quadrant in Part 2 of this series</a>, our focus now moves to Culture. I have been involved with over 30 release trains since I started working with SAFe in early 2012, and I have come to the passionate belief over that time that positive movement in culture is the most accurate predictor of sustained success. <br />
<br />
While most agree that it is impossible to truly measure culture, there are certainly indicators that can be measured which help us in steering our path.<br />
<br />
In selecting the mix of measures proposed, I was looking for a number of elements:<br />
<ul>
<li>Are our people happy?</li>
<li>Are our stakeholders happy?</li>
<li>Are we becoming more self-organizing?</li>
<li>Are we breaking down silos?</li>
</ul>
<br />
The basic metrics address the first 2 elements, while the advanced metrics tackle self-organization and silos.<br />
<h3>
</h3>
<h3>
Basic Definitions</h3>
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEj0Q4743lzL1vV3iZxCuMPprtK9Vhnz9Xnw8AhyphenhyphenNCt-SLcnjCYowbNjluxvHsSVQU4FW3jrz-GlxzcMvgjj2Z3hveALtFN-PgoVj8qiq8nJTFyEZZNjVVOKq0lJ2HRwZZLiR3dc5fX3ILs-/s1600/Culture+Basic+Definitions.jpg" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="234" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEj0Q4743lzL1vV3iZxCuMPprtK9Vhnz9Xnw8AhyphenhyphenNCt-SLcnjCYowbNjluxvHsSVQU4FW3jrz-GlxzcMvgjj2Z3hveALtFN-PgoVj8qiq8nJTFyEZZNjVVOKq0lJ2HRwZZLiR3dc5fX3ILs-/s640/Culture+Basic+Definitions.jpg" width="640" /></a></div>
<div>
<br /></div>
<br />
<h3>
Basic Metrics Rationale</h3>
<h4>
</h4>
<h4>
Team Net Promoter Score (NPS) - "Are our people happy?"</h4>
In his book <a href="https://www.amazon.com/Ultimate-Question-Revised-Expanded-Customer-Driven-ebook/dp/B005E8AKVM/ref=sr_1_1?s=digital-text&ie=UTF8&qid=1485010142&sr=1-1&keywords=the+ultimate+question+2.0" target="_blank">The Ultimate Question 2.0</a>, Fred Reichheld describes the fashion in which many companies also apply NPS surveys to their employees - altering the question from "how likely are you to recommend [Company Name]" to "how likely are you to recommend working for [Company Name]".<br />
<br />
My recommendation is that the question is framed as "how likely are you to recommend being a member of [Release Train name]?". <a href="http://surveymonkey.com/" target="_blank">Survey Monkey</a> provides a very easy mechanism for running the surveys.<br />
<br />
For a more detailed treatment, see <a href="http://www.prettyagile.com/2013/11/measuring-team-happiness.html" target="_blank">this post</a> by my colleague <a class="g-profile" href="https://plus.google.com/116452192195762487608" target="_blank">+Em Campbell-Pretty</a>. Pay particular attention to the value of the verbatims and the inclusion of vendor staff in the survey – they’re team members too!<br />
<br />
As a coach, I often ponder what “mission success” looks like. What is the moment when the ART I’ve been nurturing is set for greatness and my job is done? Whilst not enough of my ARTs have adopted the team NPS discipline to give me great data, I have developed a belief based on the data I do have that the signal is the moving Team NPS above +20.<br />
<h4>
</h4>
<h4>
Business Owner Net Promoter Score (NPS) - "Are our stakeholders happy?</h4>
This is a more traditional treatment of NPS based on the notion that business owners are effectively internal customers of the ART. The question is framed as "how likely are you to recommend the services of [Release Train Name] to a friend or colleague?"<br />
<br />
If you’re truly serious about the Lean mindset, you will be considering your vendors when you identify the relevant Business Owners for this metric. There is vendor involvement in virtually every ART I work with, team-members sourced from vendors are a key part of our culture, and vendor management need to be satisfied the model is working for their people and their organization.<br />
<h4>
</h4>
<h4>
Staff Turnover %</h4>
In one sense, this metric could be focused on "Are our people happy", however I believe it is more holistic in nature. Staff turnover can be triggered either by people being unhappy and leaving, or by lack of organizational commitment to maintaining long-lived train membership. Either will have negative impacts.<br />
<h3>
</h3>
<h3>
Advanced Definitions</h3>
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjM6WKEMDj9CwzldUcEu9XHkrChhm5oNi_xWIe-RPHCAarcbiCSQPK3f2DtryBYA2jHg8ga7sZMR3ft4jyK2DIDLyCfwu5gnNZ30ZTv38HCI3e-dZQAW3c1lYQ1YmheuJrzFk2_UKBDVTt3/s1600/Culture+Advanced+Definitions.jpg" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="190" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjM6WKEMDj9CwzldUcEu9XHkrChhm5oNi_xWIe-RPHCAarcbiCSQPK3f2DtryBYA2jHg8ga7sZMR3ft4jyK2DIDLyCfwu5gnNZ30ZTv38HCI3e-dZQAW3c1lYQ1YmheuJrzFk2_UKBDVTt3/s640/Culture+Advanced+Definitions.jpg" width="640" /></a></div>
<div>
<br /></div>
<h3>
Advanced Metrics Rationale</h3>
<h4>
</h4>
<h4>
Developer % (IT) - "Are we becoming more self-organizing?" </h4>
When an ART is first formed it classically finds “a role in SAFe” for all relevant existing IT staff (often a criticism of SAFe from "anti-SAFe crowd"). However, as it matures and evolves the people might stay but their activities change. People who have spent years doing nothing but design start writing code again. Great business analysts move from the IT organisation to the business organisation. Project managers either return to a practical skill they had prior to become project managers or roll off the train. In short, the only people who directly create value in software development are software developers. All other IT roles are useful only in so far as they enable alignment (and the greater our self-organisation maturity the less the need for dedicated alignment functions). In short, if we seek true productivity gains we seek a greater proportion of doers. <br />
<br />
One of my customers started using this metric to measure progress on this front and I loved it. One of the early cost-saving aspects of agile is reduction in management overhead, whether it be the instant win of preventing duplication of management functions between the implementing organization and their vendors or the conversion of supervision roles (designers, project managers) to contribution roles. <br />
<br />
Obviously, this is a very software-centric view of the ART. As the “Business %” metric will articulate, maturing ARTs will tend to deliberately incorporate more people with skills unrelated to software development. Thus, this measure focuses on IT-sourced Train members (including leadership) who are developers. <br />
<br />
As a benchmark, the (Federal Government) organization who inspired the incorporation of this metric had achieved a ratio of 70%. <br />
<h4>
</h4>
<h4>
Business % - "Are we breaking down silos?" </h4>
While most ARTs begin life heavily staffed by IT roles, as the mission shifts towards global optimization of the “Idea to Value” life-cycle they discover the need for more business related roles. This might be the move from “proxy Product Owners” to real ones, but equivalently and powerfully sees the incorporation of business readiness skill-sets such as business process engineering, learning and development, marketing and other business readiness type skills. <br />
<br />
Whilst the starting blueprint for an ART incorporates only 1 mandatory business role (the Product Manager) and a number of recommended business roles (Product Owners), evolution should see this mix change drastically. <br />
<br />
The purpose of this measure could easily have been written as "Are we achieving system-level optimization?", however my personal bent for the mission of eliminating the terms "business" and "IT" led to the silo focus in the question. <br />
<h3>
</h3>
<h3>
Conclusion </h3>
When it comes to culture, I have a particular belief in the power of a change in language employed to provide acceleration. A number of ARTs I coach are working hard to eliminate the terms “Business” and “IT” from their vocabulary, but the most powerful language change you can make is to substitute the word “person” for “resource”! <br />
<br />
<br />
<h3>
Series Context</h3>
•<span class="Apple-tab-span" style="white-space: pre;"> </span><a href="http://www.agilenotanarchy.com/2017/01/revamping-safes-program-level-pi.html" target="_blank">Part 1 – Introduction and Overview</a><br />
•<span class="Apple-tab-span" style="white-space: pre;"> </span><a href="http://www.agilenotanarchy.com/2017/01/revamping-safes-program-level-pi_19.html" target="_blank">Part 2 – Business Impact Metrics</a><br />
•<span class="Apple-tab-span" style="white-space: pre;"> </span><a href="http://www.agilenotanarchy.com/2017/01/revamping-safes-program-level-pi_25.html" target="_blank">Part 3 – Culture Metrics</a> <span style="color: lime;">(You are here)</span><br />
•<span class="Apple-tab-span" style="white-space: pre;"> </span><a href="http://www.agilenotanarchy.com/2017/01/revamping-safes-program-level-pi_30.html" target="_blank">Part 4 – Quality Metrics</a><br />
•<span class="Apple-tab-span" style="white-space: pre;"> </span><span style="color: lime;"><a href="http://www.agilenotanarchy.com/2017/02/revamping-safes-program-level-pi.html" target="_blank">Part 5 – Speed Metrics</a> </span><br />
<span style="font-family: "times new roman";">•</span><span class="Apple-tab-span" style="font-family: "times new roman"; white-space: pre;"> </span><span style="font-family: "times new roman";"><a href="http://www.agilenotanarchy.com/2017/02/revamping-safes-program-level-pi_18.html" target="_blank">Part 6 – Conclusion and Implementation</a></span><br />
<br />
<blockquote class="tr_bq">
“<i>Instead of trying to change mindsets and then change the way we acted, we would start acting differently and the new thinking would follow.</i>” David Marquet, Turn the Ship Around.</blockquote>
<div>
<div class="MsoNormal" style="line-height: normal; margin-bottom: .0001pt; margin-bottom: 0cm;">
<o:p></o:p></div>
</div>
Mark Richardshttp://www.blogger.com/profile/12477809828045353101noreply@blogger.com8tag:blogger.com,1999:blog-7030397814607511868.post-22226152131210675982017-01-19T23:42:00.000-08:002017-02-18T06:47:19.819-08:00Revamping SAFe's Program Level PI Metrics Part 2/6: Business Impact<blockquote class="tr_bq">
“<i>Managers shape networks’ behavior by emphasizing indicators
that they believe will ultimately lead to long term profitability</i>” – Philip Anderson,
Seven Levers for Guiding the Evolving Enterprise</blockquote>
<br />
<div class="separator" style="clear: both; text-align: center;">
</div>
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhQnHv7y3r90-wzzUI1Focl6kFRWutaXrZkjfWUYWondJonFYRNssfsJSBIAExB_2PBsdKvDnsx8aXtfmnonwicnGfRSUy-g9XRzRwrfSgPr4cGCBgJDPC6PDELytE1fLxB2y5idEjmPay1/s1600/Business+Impact+Quadrant+Metrics.JPG" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="217" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhQnHv7y3r90-wzzUI1Focl6kFRWutaXrZkjfWUYWondJonFYRNssfsJSBIAExB_2PBsdKvDnsx8aXtfmnonwicnGfRSUy-g9XRzRwrfSgPr4cGCBgJDPC6PDELytE1fLxB2y5idEjmPay1/s400/Business+Impact+Quadrant+Metrics.JPG" width="400" /></a></div>
<div class="separator" style="clear: both; text-align: center;">
</div>
<br />
<h3>
Introduction </h3>
In <a href="http://www.agilenotanarchy.com/2017/01/revamping-safes-program-level-pi.html" target="_blank">Part 1</a> of this series, we introduced the Agile Release Train (ART) PI metrics dashboard and gave an overview of the 4 quadrants of measurement. This post explores the first and arguably most important quadrant – Business Impact. <br />
<br />
As you may have guessed from the rather short list, there can be no useful generic set of metrics. They must be context driven for each ART based on both the mission of the ART and the organisational strategic themes tha<span style="font-family: inherit;">t ga</span>ve birth to it. As Mark Schwartz put it so elegantly in <a href="https://www.amazon.com/Art-Business-Value-Mark-Schwartz/dp/1942788045/ref=sr_1_1?ie=UTF8&qid=1484896094&sr=8-1&keywords=the+art+of+business+value" target="_blank">The Art of Business Value</a>, “<i>Business value is a hypothesis held by the organization’s leadership as to what will best accomplish the organization’s ultimate goals or desired outcomes</i>”.<br />
<div class="MsoNormal">
<o:p></o:p></div>
<h3>
Definitions</h3>
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEi_IHbhyw7o1VnD8PF4HKU_TSt1cwTr9x1OLlZPJ41b_Jg_Co0bFbjMhxYfHsXMECLHjC03McIuWMc4dczLE0vDLhQeiJ3wc6pmAHXe6xpTCHYZH6UcmNgA8Yuo7K7sO-17oD9eBj53qjD1/s1600/Business+Impact+Basic+Definitions.JPG" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="176" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEi_IHbhyw7o1VnD8PF4HKU_TSt1cwTr9x1OLlZPJ41b_Jg_Co0bFbjMhxYfHsXMECLHjC03McIuWMc4dczLE0vDLhQeiJ3wc6pmAHXe6xpTCHYZH6UcmNgA8Yuo7K7sO-17oD9eBj53qjD1/s640/Business+Impact+Basic+Definitions.JPG" width="640" /></a></div>
<div>
<br /></div>
<h3>
Rationale</h3>
<h4>
Fitness Function</h4>
When reading <a href="https://www.amazon.com/Everything-Store-Jeff-Bezos-Amazon/dp/0316219282/ref=sr_1_1?ie=UTF8&qid=1484896938&sr=8-1&keywords=the+everything+store" target="_blank">The Everything Store: Jeff Bezos and the Age of Amazon</a>, I was particularly taken by the concept of the fitness function. Each team was required to propose "<i>.. A linear equation that it could use to measure its own impact without ambiguity. … A group writing software code for the fulfillment centers might home in on decreasing the cost of shipping each type of product and reducing the time that elapsed between a customer's making a purchase and the item leaving the FC in a truck</i>". Amazon has since moved to more discrete measures rather than equations (I suspect in large part due to the bottlenecks caused by Bezos' insistence on personally signing off each team's fitness function equation), but I believe the “fitness function mindset” has great merit in identifying the set of business impact metrics which best measure the performance of an ART.<br />
<br />
To illustrate based on three ART's I work with:<br />
<ul>
<li>An ART at an organisation which ships parcels uses "First time delivery %". They implement numerous digital features enabling pre-communication with customers to avoid delivery vans arriving at empty houses. Moving this a percentage point has easily quantifiable bottom-line ROI impacts.</li>
<li>An ART focused on Payment Assurance at an organisation which leverages "Delivery Partners" to execute field installation and service work. Claims for payment submitted by these partners are complex and require payment within tight SLA's. A fitness function based on Payment lead time and cost savings based on successful claim disputes would again easily be mapped to quantifiable ROI.</li>
<li>A telco ART focused on self-service diagnostics for customers. The fitness function in this case would reference “reduced quantity of fault-related calls to call centers” (due to the customer having self-diagnosed and used the tool to make their own service booking if required), “reduced quantity of no-fault-found truck rolls” (due to the tool having aided the customer in identifying ‘user error’), “increased first call resolution rates for truck rolls” (due to the detailed diagnostic information available to service technicians).</li>
</ul>
<b>Considerations when selecting fitness function components</b><br />
Obviously, the foremost consideration is identifying a number of components from which one can model a monetary impact. However, I believe two other factors should be considered in the identification process:<br />
<ul>
<li>Impact on the Customer</li>
<li>Ensuring a mix of both Leading and Lagging Measures</li>
</ul>
<a href="https://www.netpromoter.com/know/" target="_blank">Net Promoter Score (NPS)</a> is rapidly becoming the default customer loyalty metric, and whilst Reichheld argues in <a href="https://www.amazon.com/Ultimate-Question-Revised-Expanded-Customer-Driven/dp/1422173356/ref=sr_1_1?ie=UTF8&qid=1484897203&sr=8-1&keywords=the+ultimate+question" target="_blank">The Ultimate Question 2.0</a> that mature NPS implementations gain the ability to quantify the value of a movement in a specific NPS demographic I have yet to actually work with an organization that has reached this maturity. However, most have access to reasonably granular NPS metrics. The trick is identifying the NPS segments impacted by the customer interactions associated with the ART’s mission and incorporating those measures.<br />
<div>
<br />
When it comes to identifying useful leading metrics, there can be no better inspiration than the Innovation Accounting concepts explained by Eric Ries in <a href="https://www.amazon.com/Lean-Startup-Entrepreneurs-Continuous-Innovation/dp/0307887898/ref=sr_1_1?ie=UTF8&qid=1484897282&sr=8-1&keywords=the+lean+startup" target="_blank">The Lean Startup</a>. In some cases (particularly Digital), it can also be as simple as taking the popular <a href="http://www.expectedbehavior.com/experiments/pirate_metrics/" target="_blank">Pirate Metrics</a> for inspiration. For many trains with digital products, I also believe abandonment rate is an extremely valuable metric given that an abandoned transaction tends to equate to either a lost sale or added load on a call center.<br />
<h4>
Program Predictability</h4>
This is the <a href="http://www.scaledagileframework.com/metrics/#P2" target="_blank">standard proxy result measure defined in SAFe</a>. It is a great way of ensuring focus on objectives whilst leaving space for Product Owners and Managers to make trade-off calls during PI execution. In short, I paraphrase it as "a measure of how closely the outcomes from PI execution live up to the expectations established with Business Owners at PI planning and how clear those expectations were".</div>
<h3>
But wait, there's more!</h3>
A good train will use far more granular results metrics than those listed above. Each feature should come with specific success measures that teams, product owners and managers should be using to steer their strategy and tactics (fuel for another post), but I am seeking here a PI level snapshot that can be utilized consistently at portfolio levels to understand the success or otherwise of investment strategy.<br />
<h3>
A closing note on the Fitness Function</h3>
I believe the fitness function definition should be identified and agreed at the ART Launch Workshop. Well-launched ARTs will have all the key Business Owners present at this workshop, and I strongly believe that agreement on how the business impact of the ART will be measured is a critical component of mission alignment. <br />
<br />
<h3>
Series Context</h3>
•<span class="Apple-tab-span" style="white-space: pre;"> </span><a href="http://www.agilenotanarchy.com/2017/01/revamping-safes-program-level-pi.html" target="_blank">Part 1 – Introduction and Overview</a><br />
•<span class="Apple-tab-span" style="white-space: pre;"> </span><a href="http://www.agilenotanarchy.com/2017/01/revamping-safes-program-level-pi_19.html" target="_blank">Part 2 – Business Impact Metrics</a> <span style="color: lime;">(You are here)</span><br />
•<span class="Apple-tab-span" style="white-space: pre;"> </span><a href="http://www.agilenotanarchy.com/2017/01/revamping-safes-program-level-pi_25.html" target="_blank">Part 3 – Culture Metrics</a><br />
•<span class="Apple-tab-span" style="white-space: pre;"> </span><a href="http://www.agilenotanarchy.com/2017/01/revamping-safes-program-level-pi_30.html" target="_blank">Part 4 – Quality Metrics</a><br />
•<span class="Apple-tab-span" style="white-space: pre;"> </span><span style="color: lime;"><a href="http://www.agilenotanarchy.com/2017/02/revamping-safes-program-level-pi.html" target="_blank">Part 5 – Speed Metrics</a> </span><br />
<span style="font-family: "times new roman";">•</span><span class="Apple-tab-span" style="font-family: "times new roman"; white-space: pre;"> </span><span style="font-family: "times new roman";"><a href="http://www.agilenotanarchy.com/2017/02/revamping-safes-program-level-pi_18.html" target="_blank">Part 6 – Conclusion and Implementation</a></span><br />
<br />
<br />
<blockquote class="tr_bq">
“<i>The gold standard of metrics: Actionable, Accessible and Auditable ... For a report to be considered actionable it must demonstrate clear cause and effect … Make the reports as simple as possible, so everyone understands them … We must ensure that the data is credible</i>” – Eric Ries, The Lean Startup</blockquote>
Mark Richardshttp://www.blogger.com/profile/12477809828045353101noreply@blogger.com8tag:blogger.com,1999:blog-7030397814607511868.post-87630103516632357592017-01-14T17:50:00.001-08:002017-02-18T06:47:41.229-08:00Revamping SAFe's Program Level PI Metrics Part 1/6 - Overview<blockquote class="tr_bq">
<i>"Performance of management should be measured by potential to stay in business, to protect investment, to ensure future dividends and jobs through improvement of product and service for the future, not by the quarterly dividend</i>" - Deming</blockquote>
<br />
Whilst the Scaled Agile Framework (SAFe) has evolved significantly over the years since inception, one area that has lagged is that of metrics. Since the Agile Release Train (ART) is the key value-producing vehicle in SAFe, I have a particular interest in Program Metrics - especially those produced on the PI boundaries.<br />
<br />
In tackling this topic, I have numerous motivations. Firstly, the desire to acknowledge that it is easier to critique than create. I have often harassed <a class="g-profile" href="https://plus.google.com/111678440224086860538" target="_blank">+Dean Leffingwell</a> over the need to revamp the PI metrics, but not until recently have I developed a set of thoughts which I believe meaningfully contribute to progress. Further, I wish to help organisations avoid falling into the all-too-common traps of mistaking velocity for productivity or simply adopting the default “on time, on budget, on scope” and phase gate inheritance. It is one thing to tout <a href="https://www.blogger.com/(http://www.scaledagileframework.com/base-milestones-on-objective-evaluation-of-working-systems/" target="_blank">Principle 5 – Base milestones on objective evaluation of working systems</a>, and quite another to provide a sample set of measures which provide a convincing alternative to traditional milestones and measures.<br />
<div>
<h3>
Scorecard Design</h3>
It is not enough to look at value alone. One must take a balanced view not just of the results being achieved but of the sustainability of those results. In defining the PI scorecard represented here, I was in pursuit of a set of metrics which answered the following question:<br />
<br />
<blockquote class="tr_bq">
"<i>Is the ART sustainably improving in its ability to generate value through the creation of a passionate, results-oriented culture relentlessly improving both its engineering and product management capabilities?</i>"</blockquote>
<br />
After significant debate, I settled on 4 quadrants, each focused on a specific aspect of the question above:<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEg4lX-uN1axJdHGd5E9CLYaTu7K01S391hE9hzJiSAft1VHQ3cLSOSSm55H8P54xtEFpqFga68jdllhrw9-rP9GrzKlWrB1gWa3T9KqvGRLgboNeeOFdYqgSA3cfzsu0AUBEWHs1DHOLyAZ/s1600/Metrics+Quadrants.JPG" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="283" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEg4lX-uN1axJdHGd5E9CLYaTu7K01S391hE9hzJiSAft1VHQ3cLSOSSm55H8P54xtEFpqFga68jdllhrw9-rP9GrzKlWrB1gWa3T9KqvGRLgboNeeOFdYqgSA3cfzsu0AUBEWHs1DHOLyAZ/s400/Metrics+Quadrants.JPG" width="400" /></a></div>
<span style="font-family: "calibri" , sans-serif; font-size: 11pt;"><br /></span>
<span style="font-family: "calibri" , sans-serif; font-size: 11pt;">For
each quadrant, I have defined both a basic and advanced set of metrics.</span><span style="font-family: "calibri" , sans-serif; font-size: 11pt;"> </span><span style="font-family: "calibri" , sans-serif; font-size: 11pt;">The basics represent “the essentials”, the
bare minimum that should be measured for a train.</span><span style="font-family: "calibri" , sans-serif; font-size: 11pt;"> </span><span style="font-family: "calibri" , sans-serif; font-size: 11pt;">However, if one desires to truly use metrics
to both measure and identify opportunities for improvement some additional
granularity is vital – and this is the focus of the additional advanced
metrics.</span><br />
<span style="font-family: "calibri" , sans-serif; font-size: 11pt;"><br /></span>
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjwP-CCXeUR1TuQWSdKYk7xjFKw0qaeAaYzGVnxsNQDy9exhLRiZ3_aqTYIZXexWePWU0kirgz_is_N5xcZ36W43retd4GC6sw6N15JKy1FZpW9MHVRObnvVAK6l3lu8iOFpEOyb_XcBF51/s1600/Essential+Scorecard.JPG" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="370" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjwP-CCXeUR1TuQWSdKYk7xjFKw0qaeAaYzGVnxsNQDy9exhLRiZ3_aqTYIZXexWePWU0kirgz_is_N5xcZ36W43retd4GC6sw6N15JKy1FZpW9MHVRObnvVAK6l3lu8iOFpEOyb_XcBF51/s640/Essential+Scorecard.JPG" width="640" /></a></div>
<span style="font-family: "calibri" , sans-serif; font-size: 11pt;"><br /></span>
<br />
<h4>
Business Impact</h4>
Whilst at first glance this quadrant might look sparse, the trick is in the “Fitness Function”. Wikipedia defines it as “a particular type of objective function that is used to summarise, as a single figure of merit, how close a given design solution is to achieving the set aims”. Jeff Bezos at Amazon quite famously applied it, insisting that every team in the organization developed a fitness function to measure how effectively they were impacting the customer. It will be different for every ART, but should at minimum identify the key business performance measures that will be impacted as the ART fulfils its mission.<br />
<h4>
Culture</h4>
The focus in culture is advocacy. Do our people advocate working here? Do our stakeholders advocate our services? Are we managing to maintain a stable ART?<br />
<h4>
Quality</h4>
For quality, our primary question is “are we building quality in?” Unit Test coverage demonstrate progress with unit test automation, while “Mean time between Green Builds” and “MTTR from Red Build” provide good clues as to the establishment of an effective Continuous Integration mindset. From there we look at late phase defect counts and validation capacity to understand the extent to which our quality practices are “backloaded” – in short, how much is deferred to “end-to-end” feature validation and pre-release validation activities. And finally, we are looking to see incidents associated with deployments dropping.<br />
<h4>
Speed</h4>
This quadrant is focused on responsiveness - how rapidly can our ART respond to a newly identified opportunity or threat? Thus, we start with Feature Lead Time - "how fast can we realise value after identifying a priority feature?". Additionally, we are looking for downward trends in time spent “on the path to production”, mean time to recover from incidents and frequency of deployments as our Devops work pays dividends.<br />
<br />
<h3>
Conclusion</h3>
In parts 2 through 5 of this series, I will delve into each quadrant in turn, exploring the definitions of and rationale for each measure and in part 6 wrap it all up with a look at usage of the complete dashboard.<br />
<br />
<h3>
Series Context</h3>
•<span class="Apple-tab-span" style="white-space: pre;"> </span><a href="http://www.agilenotanarchy.com/2017/01/revamping-safes-program-level-pi.html" target="_blank">Part 1 – Introduction and Overview</a> <span style="color: lime;">(You are here)</span><br />
•<span class="Apple-tab-span" style="white-space: pre;"> </span><a href="http://www.agilenotanarchy.com/2017/01/revamping-safes-program-level-pi_19.html" target="_blank">Part 2 – Business Impact Metrics</a><br />
•<span class="Apple-tab-span" style="white-space: pre;"> </span><a href="http://www.agilenotanarchy.com/2017/01/revamping-safes-program-level-pi_25.html" target="_blank">Part 3 – Culture Metrics</a><br />
•<span class="Apple-tab-span" style="white-space: pre;"> </span><a href="http://www.agilenotanarchy.com/2017/01/revamping-safes-program-level-pi_30.html" target="_blank">Part 4 – Quality Metrics</a><br />
•<span class="Apple-tab-span" style="white-space: pre;"> </span><span style="color: lime;"><a href="http://www.agilenotanarchy.com/2017/02/revamping-safes-program-level-pi.html" target="_blank">Part 5 – Speed Metrics</a> </span><br />
<span style="font-family: "times new roman";">•</span><span class="Apple-tab-span" style="font-family: "times new roman"; white-space: pre;"> </span><span style="font-family: "times new roman";"><a href="http://www.agilenotanarchy.com/2017/02/revamping-safes-program-level-pi_18.html" target="_blank">Part 6 – Conclusion and Implementation</a> </span><br />
<br />
<br />
<blockquote class="tr_bq">
"<i>Short term profits are not a reliable indicator of performance of management. Anybody can pay dividends by deferring maintenance, cutting out research, or acquiring another company</i>" – Deming</blockquote>
</div>
Mark Richardshttp://www.blogger.com/profile/12477809828045353101noreply@blogger.com5tag:blogger.com,1999:blog-7030397814607511868.post-84092196114563701722017-01-05T04:16:00.002-08:002017-01-05T04:16:37.474-08:00Tips for Designing and Leveraging Great Kanban Boards<h3>
Introduction</h3>
I’ve been working on an article about the SAFe Program Kanban, and found myself mixing in a number of basic Kanban techniques. As I read through the (overly lengthy) first draft and realised the fuzzy focus being caused by a mix of “Kanban 101” and “Program Kanban”, I found myself reflecting on the fact that a lot of people kind of “fall into Kanban”. The two most common cases I encounter are the dev team that evolves their Scrum implementation to the point that the arbitrary batching mechanism of the Sprint Boundary seems suboptimal and the Agile Release Train (ART) Product Management team taking their first crack at a Program Kanban. For whatever reason, many start to use it without ever understanding any of the basic tools available other than “use WIP limits”.<br /><br /><div>
In this article, I’m going to cover two of the basic Kanban concepts every team should take advantage of and a third which tends to be more applicable for strategic Kanban systems than those operated at the dev team level.<h3>
Doing and Done</h3>
<span style="font-weight: normal;">One of the simplest improvements you can make to a Kanban is the separation of states into “Doing” and “Done”. This separation enables far more accurate visualization of the true state of a piece of work, adds immensely to the granularity of the metrics that can be derived, and most importantly is critical to enabling the move from "push" to "pull" mindset.</span><span style="font-weight: normal;"><br /></span><span style="font-weight: normal;">Consider the simple yet very common 2-state Team Kanban below:</span><br />
<span style="font-weight: normal;"><br /></span>
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgeAKzB7dt0H5jqKIgv0D4C3wmNondsuNX5LvzskgAqdfA4l2HDrIxwNt7c6EombgL2om3UU5byBq2EYxaMjiJ3dpUaHrkzK6NOef5vyDVXzueKwpeF_fzdipoTqH8HrUDbduNNi_u7DiHG/s1600/Simple+Dev+and+Test+Kanban.JPG" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="227" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgeAKzB7dt0H5jqKIgv0D4C3wmNondsuNX5LvzskgAqdfA4l2HDrIxwNt7c6EombgL2om3UU5byBq2EYxaMjiJ3dpUaHrkzK6NOef5vyDVXzueKwpeF_fzdipoTqH8HrUDbduNNi_u7DiHG/s400/Simple+Dev+and+Test+Kanban.JPG" width="400" /></a></div>
<span style="font-weight: normal;"><br /></span><span style="font-weight: normal;"><br /></span><span style="font-weight: normal;">When the developer completes story S1, they will signal this by pushing it into Test. However, the system is now lying. The fact that the developer has placed it in test does not mean testing has commenced (the clue lay in the use of the word "pushed").<br /> </span><span style="font-weight: normal;"><br /></span><span style="font-weight: normal;">Consider an alternative:</span><br />
<span style="font-weight: normal;"><br /></span>
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEh6gnwcKrfdRRvJKNqfzpr83xQV1-s1Mw6UkDj_6rDYab_0RSyI_hhrNppoGq-Y69pPOXP8aHSYssorARXpofEKvbmd1Z0mdXvO9xGAQ1P8m5QeUdGQNluxRkJsz1YARDvILaapBfOB4WhS/s1600/Dev+and+Test+Kanban+with+DoingDone.JPG" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="228" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEh6gnwcKrfdRRvJKNqfzpr83xQV1-s1Mw6UkDj_6rDYab_0RSyI_hhrNppoGq-Y69pPOXP8aHSYssorARXpofEKvbmd1Z0mdXvO9xGAQ1P8m5QeUdGQNluxRkJsz1YARDvILaapBfOB4WhS/s400/Dev+and+Test+Kanban+with+DoingDone.JPG" width="400" /></a></div>
<span style="font-weight: normal;"><br /></span><span style="font-weight: normal;">Now, when the developer completes story S1, they place it in "Dev Done". This sends a signal to the testers that when they are ready, they can "pull" story S1 into Test. If we see a big queue building in Dev Done, we can see a bottleneck emerging in front of Test. If (over time), we discover that stories are spending significant amounts of time in "Dev Done" it should trigger some root cause analysis.<br /> </span><span style="font-weight: normal;"><br /></span><span style="font-weight: normal;">You could also achieve the same effect by making a 4 state Kanban as follows:</span><span style="font-weight: normal;"><br /></span><br />
<ul>
<li><span style="font-weight: normal;">Dev</span></li>
<li><span style="font-weight: normal;">Ready for Test</span></li>
<li><span style="font-weight: normal;">Test</span></li>
<li><span style="font-weight: normal;">Ready for Acceptance</span></li>
</ul>
<span style="font-weight: normal;">To be brutally honest, the difference is intellectual. Aesthetically, I tend to prefer the “Doing|Done” approach, partially because it leaves me with less apparent states in the Kanban and mainly because I tend to assign WIP limits spanning “Doing and Done”. In fact, when designing complex Kanbans I will often use a mix of “Single State” and “Multi-State (Doing|Done)” columns from a clarity perspective. The “Single State” columns tend to be those in which no activity is occurring – they’re just a queue (eg “Backlog”).</span><br />
<span style="font-weight: normal;"><br /></span>
<h3>
Exit Policies</h3>
The creator of the Kanban Method (David Anderson) identified 5 core properties of successful Kanban implementations, one of which was “Make Process Policies Explicit”. In designing the states of your Kanban system, you are beginning to fulfill this need by making the key stages of your workflow explicit (and supporting another of the key properties – “Manage Flow”). For the evolving Scrum Team, this is often sufficient as it will be supported by their “Definition of Done” (another explicit policy). <br /><br />However, at the strategic level (or for a Kanban system that crosses team boundaries) we benefit by taking it to another level and defining “Exit Policies”. An Exit Policy is effectively the “Definition of Done” for a single state. Whilst it is up to the team member(s) (or Teams) exactly how they do the work for that state, it is not considered “Done” until it meets the exit policies for the state. These policies should be made visible as part of the Kanban design, and should be subject to review and evolution as part of continuous improvement activities. In the words of Taichi Ohno – “Without standards there can be no Kaizen”.<br /><table align="center" cellpadding="0" cellspacing="0" class="tr-caption-container" style="margin-left: auto; margin-right: auto;"><tbody>
<tr><td style="text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEioYpV_IWN7asuPfNv1Zh8o5t9hXEb8Y9oDsvWiyEpinMGNpQdS6QHmW-W_CSlkOz-k8ml0Tld_LgqzzjRMGNuh_UlNar_VPbKYYJko1_l2MMPIjLDzbJhYxa_GDqE3Ub4m9Z7tV6xKnFDE/s1600/Epic+Kanban+Wall+-+Full+%2528Blog+Size%2529.jpg" imageanchor="1" style="margin-left: auto; margin-right: auto;"><img border="0" height="478" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEioYpV_IWN7asuPfNv1Zh8o5t9hXEb8Y9oDsvWiyEpinMGNpQdS6QHmW-W_CSlkOz-k8ml0Tld_LgqzzjRMGNuh_UlNar_VPbKYYJko1_l2MMPIjLDzbJhYxa_GDqE3Ub4m9Z7tV6xKnFDE/s640/Epic+Kanban+Wall+-+Full+%2528Blog+Size%2529.jpg" width="640" /></a></td></tr>
<tr><td class="tr-caption" style="text-align: center;">Note the explicit exit policies below each state heading in this Portfolio Kanban</td></tr>
</tbody></table>
<div>
<span style="font-weight: normal;"><br /></span></div>
<h3>
Avatars</h3>
Every piece of information you can add to a Kanban board is valuable in conveying extra information to support conversation and insight. Most teams are familiar with the practice of creating a set of laminated “avatars” for each team member. When a team member is participating in the work on a card, they add their avatar to the card as a signal. Thus, anyone observing a Kanban and wanting to know who is working on a card gets instant gratification. Incidentally, this is for me one of the biggest failure areas of digital Kanban boards. To my knowledge, the only digital Kanban tool that supports multiple avatars on a single card is LeanKit – a very strange condition in a world centred on collaboration :)<div>
<br /></div>
<div>
Now to extend the concept. There is no reason to restrict avatars to the representation of individuals. If we create avatars for Dev Teams, we can (for example) understand which dev teams are involved in the implementation of a feature on a feature Kanban. Take it up a layer, and we can create avatars for ARTs and other delivery organizations. Suddenly, we can look at a portfolio Kanban and understand which delivery organizations are involved in the implementation of an Epic.</div>
<div>
<br /></div>
<table align="center" cellpadding="0" cellspacing="0" class="tr-caption-container" style="margin-left: auto; margin-right: auto; text-align: center;"><tbody>
<tr><td style="text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgn1RSR79oc5dUXhcp-c_o-NkuVaF00ua3HiA0z5Z0NTFj3HLzQgrEgRZJRNLotbtU-Qyf6RvNfJRQS2WF-R7i17_DD1vztBc9LRMp4IKQemraEE0x9i-tVt5is_PMyy99oI8xM9K4P3m9h/s1600/Card+Highlights+%25282%2529.jpg" imageanchor="1" style="margin-left: auto; margin-right: auto;"><img border="0" height="400" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgn1RSR79oc5dUXhcp-c_o-NkuVaF00ua3HiA0z5Z0NTFj3HLzQgrEgRZJRNLotbtU-Qyf6RvNfJRQS2WF-R7i17_DD1vztBc9LRMp4IKQemraEE0x9i-tVt5is_PMyy99oI8xM9K4P3m9h/s400/Card+Highlights+%25282%2529.jpg" width="293" /></a></td></tr>
<tr><td class="tr-caption" style="text-align: center;">The cards above are Epics on a Portfolio Kanban. The "Standard Avatars" (with pictures) represent individual BA's, whilst the smaller solid color avatars represent the impacted delivery organisations (an ART in one case, Business Units in others)</td></tr>
</tbody></table>
<h3>
Conclusion</h3>
There are many more tips and tricks to creating powerful Kanban visualisations, but these are the three I find myself introducing again and again as I help Scrum teams leverage Kanban techniques and ART Leadership teams implement strategic flow Kanban systems. </div>
<div>
<br /></div>
<div>
Always remember, as <a class="g-profile" href="https://plus.google.com/107639883712318675542" target="_blank">+Inbar Oren</a> put it so well, a good Kanban board <b>TALKS:</b></div>
<div>
<ul>
<li><b><span style="font-size: large;">T</span></b>ells</li>
<li><b><span style="font-size: large;">A</span></b>lways Visible</li>
<li><b><span style="font-size: large;">L</span></b>ives</li>
<li><b><span style="font-size: large;">K</span></b>eeps it Simple</li>
<li><b><span style="font-size: large;">S</span></b>elf-explanatory</li>
</ul>
</div>
Mark Richardshttp://www.blogger.com/profile/12477809828045353101noreply@blogger.com41tag:blogger.com,1999:blog-7030397814607511868.post-90538967310434446622017-01-03T05:13:00.002-08:002017-01-03T05:13:29.577-08:00Bringing your SAFe PI Plan to life during execution<div class="separator" style="clear: both; text-align: center;">
</div>
<h3>
Introduction</h3>
The SAFe PI planning event leaves every team on the Release Train with a beautifully organized backlog identifying everything they need to do together to succeed in meeting their PI objectives.<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjd0moYw0Txwx9rSN8qMJVJkH_iYBsO6-YeN00FUDmQDQsw8bVOxViejD4mrfJRjGkGnLKs5HZmmUtzHiI0MCks4m42h-milw2pLlQU3jgLeBnob7QNVKRzLaZMw-dz93NF_ISdDL9hAkI6/s1600/Full+program+board.jpg" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="484" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjd0moYw0Txwx9rSN8qMJVJkH_iYBsO6-YeN00FUDmQDQsw8bVOxViejD4mrfJRjGkGnLKs5HZmmUtzHiI0MCks4m42h-milw2pLlQU3jgLeBnob7QNVKRzLaZMw-dz93NF_ISdDL9hAkI6/s640/Full+program+board.jpg" width="640" /></a></div>
<div>
<br /></div>
<br />However, as we’ve learnt from military strategist Helmuth von Moltke, “<i>no plan survives contact with the enemy</i>!” The scale and energy of the event makes it easy to fall into the trap of believing we’ve created a plan that will survive and inherited mindset drives the belief we “now have a plan to manage compliance to”. It’s easy to miss the fact that what teams are committing to is their objectives. The carefully identified backlogs and dependencies are simply things we have produced to help us understand the outcomes we believe are possible and a point-in-time representation of the best approach to achieving them. <br /><br />Successful execution relies on us remembering that backlogs must live. Estimates will be wrong, stories will have been missed, we will discover more innovative ways of achieving the objectives. In short, circumstances will change. PI planning provides a great start by launching the PI with 5 to 10 teams having beautifully coordinated and well-groomed backlogs but success rests on what we do with them once we leave the room.<br /><br /> All too often, I see new teams and trains treat the PI plan as a static artifact. Your plan should always reflect your current best understanding of the situation, and the primary representation of your plan in SAFe is your backlog. Having <a href="http://www.agilenotanarchy.com/2016/12/team-backlog-evolution-in-safe-from-3.html" target="_blank">previously covered the ongoing lifecycle of the individual backlog item</a>, I will focus here on the of principles and practices I have found most useful in helping SAFe implementations manage the plan as a whole.<h3>
The importance of visual management</h3>
Any scaled agile implementation will inevitably wind up using a digital tool. But PI planning itself gives us the clue – it’s an amazing collaborative planning event enabled by physical visualization of the plan. If you want your plan to live, physical visualization is essential. By all means, be responsible and keep your digital tool up-to-date – but recognize it for the information refrigerator it is. I’ve seen all the tools used both well and poorly, but I’ve never seen a tool enable effective ongoing collaborative planning to anywhere near the level and efficiency possible with physical visualization<h3>
The Team PI Plan – from Planning Room to Team Room (PI level visualisation)</h3>
<div class="MsoNormal">
<o:p></o:p></div>
<div>
I have a starter template for team level plan visualisation that I suggest to all the teams I coach. It works best when a large horizontal space is available and it can be organised in one continuous run, but most teams can find space for it with a little ingenuity. As a template, it looks a little like the following:</div>
<div>
<br /></div>
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEh2UaoocrixyQra2byqooeCjsdjdHivlwxVQ0EQCPo17DwUd4hOFdKPTbM9aIDKTsg66A0HbC4AewehauDFhyphenhyphen8yEGwCehvdPwfonYLUK0pqwxuguHxVr9pZXmCIzjZSemzPs9TkhwjTCzyg/s1600/Team+Backlog+Template.jpg" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="156" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEh2UaoocrixyQra2byqooeCjsdjdHivlwxVQ0EQCPo17DwUd4hOFdKPTbM9aIDKTsg66A0HbC4AewehauDFhyphenhyphen8yEGwCehvdPwfonYLUK0pqwxuguHxVr9pZXmCIzjZSemzPs9TkhwjTCzyg/s640/Team+Backlog+Template.jpg" width="640" /></a></div>
<div>
<br /></div>
Every area except the Inbox and Overflow (covered later in the article) will contain an indication of planned velocity and load (as represented by current contents). Additionally, PI objectives should be somewhere prominent (preferably next to current sprint).<div>
<br /></div>
<table align="center" cellpadding="0" cellspacing="0" class="tr-caption-container" style="margin-left: auto; margin-right: auto; text-align: center;"><tbody>
<tr><td style="text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgJE6XXgveL80LYF7Zx7L7tNEZUkGyrFTCV2K3UiZ_ZtGpfo2KuWD0L2ABQvagj6WPPUHKI15aIeINGCPoUOl7mmTEgQ8V1Zi4qg5npI7VbbJys3rBqO9gOFawQdP7FRgdYWOuKKnptaOIa/s1600/Master+Builders+full+wall.jpg" imageanchor="1" style="margin-left: auto; margin-right: auto;"><img border="0" height="478" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgJE6XXgveL80LYF7Zx7L7tNEZUkGyrFTCV2K3UiZ_ZtGpfo2KuWD0L2ABQvagj6WPPUHKI15aIeINGCPoUOl7mmTEgQ8V1Zi4qg5npI7VbbJys3rBqO9gOFawQdP7FRgdYWOuKKnptaOIa/s640/Master+Builders+full+wall.jpg" width="640" /></a></td></tr>
<tr><td class="tr-caption" style="text-align: center;">Team Master Builders: Mobile wall, top row is current sprint, middle is next spring, bottom future sprints</td></tr>
</tbody></table>
<br />
<table align="center" cellpadding="0" cellspacing="0" class="tr-caption-container" style="margin-left: auto; margin-right: auto; text-align: center;"><tbody>
<tr><td style="text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjTHMkCh9n5-5KWTdnfWxMEk2fo4Sz5pD8Cv0Y4_bNaHuqdwLCx9ZQItW4dxN7yHwVF3PNYNt1zKVncwH106CxYeXNBjXfenx6s7rnZldsBA9pSJx2IymG0saws8BD_xOGXcblrAqptCoBf/s1600/Olympus+full+wall.jpg" imageanchor="1" style="margin-left: auto; margin-right: auto;"><img border="0" height="298" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjTHMkCh9n5-5KWTdnfWxMEk2fo4Sz5pD8Cv0Y4_bNaHuqdwLCx9ZQItW4dxN7yHwVF3PNYNt1zKVncwH106CxYeXNBjXfenx6s7rnZldsBA9pSJx2IymG0saws8BD_xOGXcblrAqptCoBf/s640/Olympus+full+wall.jpg" width="640" /></a></td></tr>
<tr><td class="tr-caption" style="text-align: center;">Team Olympus: Current to future from right to left</td></tr>
</tbody></table>
<br />
<table align="center" cellpadding="0" cellspacing="0" class="tr-caption-container" style="margin-left: auto; margin-right: auto; text-align: center;"><tbody>
<tr><td style="text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEi3r_SBxdpK58w0JtZdD1_WsTskMfFMcsL06rj7AKSIm0sVsDaz1lnl26Y2urU9DMBoTkhPnXfyK5SSGIHPUbXrKN0MvqU8z4Dze1vg9BN8ClkV59BNkVk638zinlKrxAovyNBeYpM5G3Qf/s1600/Pixar+full+wall.jpg" imageanchor="1" style="margin-left: auto; margin-right: auto;"><img border="0" height="148" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEi3r_SBxdpK58w0JtZdD1_WsTskMfFMcsL06rj7AKSIm0sVsDaz1lnl26Y2urU9DMBoTkhPnXfyK5SSGIHPUbXrKN0MvqU8z4Dze1vg9BN8ClkV59BNkVk638zinlKrxAovyNBeYpM5G3Qf/s640/Pixar+full+wall.jpg" width="640" /></a></td></tr>
<tr><td class="tr-caption" style="text-align: center;">Team Nintendo: Current sprint on right window, next sprint on middle, future on left</td></tr>
</tbody></table>
<br /><br />Additional details for each area follow:<div>
<h4>
Current Sprint </h4>
</div>
<div>
This is the visualization every team should have for their current sprint – often known as the Scrum board. Not the focus of this article, but it’s always good to bring it to life.</div>
<table align="center" cellpadding="0" cellspacing="0" class="tr-caption-container" style="margin-left: auto; margin-right: auto; text-align: center;"><tbody>
<tr><td style="text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgPnD2kZMKsFYpy8oeyu13dwKY6tWRTQniixQBT_nB-5R5P1zCZxkVbk6oLhzuHkOCS2-J7fwQ8KCzjnh8w9tpF0wJlbnJ0t9nSXROCsFPRZLZ7UsY2zWrzoCNEyZQVne0LioSU99eJROSq/s1600/Olympus+current+sprint.jpg" imageanchor="1" style="margin-left: auto; margin-right: auto;"><img border="0" height="478" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgPnD2kZMKsFYpy8oeyu13dwKY6tWRTQniixQBT_nB-5R5P1zCZxkVbk6oLhzuHkOCS2-J7fwQ8KCzjnh8w9tpF0wJlbnJ0t9nSXROCsFPRZLZ7UsY2zWrzoCNEyZQVne0LioSU99eJROSq/s640/Olympus+current+sprint.jpg" width="640" /></a></td></tr>
<tr><td class="tr-caption" style="text-align: center;">Olympus Current Sprint: Take every opportunity to build team identity through visuals</td></tr>
</tbody></table>
<br /><h4>
Next Sprint </h4>
The upcoming sprint gets slightly more focus than other future sprints, as this is where we are getting our stories to “Definition of Ready”. Typical swimlanes might be “Prioritised”, “Specifying” and “Ready. Operation of this wall is covered in my <a href="http://www.agilenotanarchy.com/2016/12/team-backlog-evolution-in-safe-from-3.html" target="_blank">last post on story lifecycle</a><div>
<br /></div>
<table align="center" cellpadding="0" cellspacing="0" class="tr-caption-container" style="margin-left: auto; margin-right: auto; text-align: center;"><tbody>
<tr><td style="text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEh-rWzN6BMxnS0IAkEbl75rLIU_MQ4PuJlKZcOkliU7NHhYkloKw0gr4fJkmcEcEx1qGHL_FlokJt-hIVnion9spk0DZPs5SHu7JXS4pQNc1HAhWNfbeJbc5B1_va2cG5y98Z3jONGSPqZT/s1600/Pixar+next+sprint.jpg" imageanchor="1" style="margin-left: auto; margin-right: auto;"><img border="0" height="344" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEh-rWzN6BMxnS0IAkEbl75rLIU_MQ4PuJlKZcOkliU7NHhYkloKw0gr4fJkmcEcEx1qGHL_FlokJt-hIVnion9spk0DZPs5SHu7JXS4pQNc1HAhWNfbeJbc5B1_va2cG5y98Z3jONGSPqZT/s640/Pixar+next+sprint.jpg" width="640" /></a></td></tr>
<tr><td class="tr-caption" style="text-align: center;">Team Pixar: Next sprint helping manage movement of stories to definition of ready</td></tr>
</tbody></table>
<br /><h4>
Future Sprints </h4>
These areas basically mirror the content from the PI plan. The backlog items and their intended sprints are carried out of PI planning and placed straight into their spot in the team area. As each sprint concludes, the cards move to the right to indicate the shrinking number of future sprints left in the PI.<br /><br /><br /><h3>
Extended Backlog Tools </h3>
Given that the backlog represents “all the work” for the team, it is a great place to capture other activities which are not necessarily either classical “user stories” or “tech stories”. Working with ARTs, we regularly devise “specialty card types” to help them articulate and manage their plans. The two I use most frequently are “Commitment Cards” to help with team-level dependency visualisation and “Capacity Cards” to represent “work that’s not necessarily very agile but definitely necessary and often responsible for killing a team if they fail to plan for it”. <br /><h4>
Commitment Cards </h4>
I was introduced to this concept by Craig Larman and Bas Vodde’s Scaling Lean and Agile Development, and have found it invaluable in SAFe. The identification of dependencies on the Program Board during PI planning (and fun with red wool) is one of the most visually powerful tools in SAFe, but little formal coverage is given to reflecting them at the team level. <br /><br />The notion of a commitment card is that when one team makes a commitment to another they place a (0 point) story in their backlog describing the commitment made. The recipient also records the commitment in their own backlog as a 0 point story. <br /><br />This assists on a number of fronts. Firstly, a dependency is rarely on a single story – it typically operates at a higher level of abstraction. Secondly, it becomes a first class citizen in the team’s backlog refinement activities. <br /><br />Finally, it assists teams populating the program board with achieving an appropriate level of granularity when reflecting their dependencies. The commitment should already be written at the appropriate summary level of granularity, and can simply be duplicated onto the program board. If the commitment card shifts in the course of planning, its twin on the program board needs to shift. <br /><h4>
Capacity Reservation Cards </h4>
Many teams have work which cannot specifically be planned for but is nonetheless reasonably predictable in size and timing and must be catered to. Whilst team-level capacity allocation is one option for dealing with this, it’s a reasonably blunt instrument which does not cater to situations where the scale of the reservation required varies from sprint to sprint. <br /><br />The most common cause of this comes in the form of hardening activities. We all know good agile doesn’t rely on hardening, but many enterprises face the harsh reality that the elimination of extended hardening periods will require dedicated work over the course of years. For example, I routinely work with organisations which have some form of enterprise-wide release process that spans 6-12 weeks. We tend to find that the capacity of a train is divided between implementing the features for the current PI, supporting the progress of features from the previous PI through the enterprise release process, and providing warranty support for the previous release. This is particularly prevalent where mainframes, ERP systems and other major COTS implementations form a major component of the technology stack. <br /><br />The bulk of work for teams arising out of these processes will be unplanned (eg defect fixes, incident resolution), but the intensity of activity and likely volume of work is more predictable. In these situations, we will place “Capacity Reservation Cards” in the backlog setting aside a certain number of points in the team’s capacity to be available. <br /><br />An additional use we make of this is setting aside capacity for the team to participate in ideation or “discovery workshops” on upcoming features as they are prepared for the next PI. Whilst the IP sprint in theory provides capacity for this work, it has the effect of creating a late-stage batching effect on team involvement in feature preparation. Inserting “Feature Discovery” items in the backlog allows time to be set aside for the team sprint by sprint and spread these activities over the whole PI. <br /><br />On a closing note, the usage of this technique enables one of my favourite PI metrics – “% of capacity required for hardening support”. Downward trends in this metric indicate the effectiveness (or otherwise) of efforts to bring forward quality and minimise the need for downstream hardening. <br /><h3>
Managing Change </h3>
Whilst as agilists we “welcome changing requirements”, there is a reality that at scale these changes will have impacts and often those impacts will extend beyond the team directly dealing with the change. A chaotic world where the backlog is constantly changing and the impact of these changes is not discovered until late in the PI is not a great thing to have. <br /><br />As such, I have found two tools to be very useful – the “Inbox” and the “Overflow”. The Inbox provides us with a mechanism for managing the introduction of new items to the backlog, and the Overflow helps provide visibility of backlog items at risk of not being completed within the PI. <br /><h4>
Inbox </h4>
<div>
As new stories are identified by the product owner (or others), they are placed in the Inbox as a holding area. The team can then establish ceremonies with the Product Owner for incorporation of new items into the backlog. Common agreements would include the team (and PO) achieving shared understanding of the backlog item, converting it to user voice form, estimating it and deliberately considering the prioritisation as it is inserted into the backlog.</div>
<table align="center" cellpadding="0" cellspacing="0" class="tr-caption-container" style="margin-left: auto; margin-right: auto; text-align: center;"><tbody>
<tr><td style="text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEi3ajrEj1rggNid8DcF2J_CK5S6kwx56xdatiLIq_V3EBOgSjalHfroQU3zrSFHVuZjE6So523wFOlWag_UfJElF5jJxok7ANFPWYswxM0dw-utqIPUG7cRHtnxL_XtrzcuMSJdHFi4BAQ6/s1600/Pixar+inbox+and+overflow.jpg" imageanchor="1" style="margin-left: auto; margin-right: auto;"><img border="0" height="362" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEi3ajrEj1rggNid8DcF2J_CK5S6kwx56xdatiLIq_V3EBOgSjalHfroQU3zrSFHVuZjE6So523wFOlWag_UfJElF5jJxok7ANFPWYswxM0dw-utqIPUG7cRHtnxL_XtrzcuMSJdHFi4BAQ6/s640/Pixar+inbox+and+overflow.jpg" width="640" /></a></td></tr>
<tr><td class="tr-caption" style="text-align: center;">Team Pixar Inbox and Overflow</td></tr>
</tbody></table>
<table align="center" cellpadding="0" cellspacing="0" class="tr-caption-container" style="margin-left: auto; margin-right: auto; text-align: center;"><tbody>
<tr><td style="text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiLnmV_TSHzlmHql-t3uur9CGswhtfHkqGK2kUQ2tEozxYdjj145y2MVDdZuHe6FMJEtiIt6CmPMdOEtwWZFmZEYGUN8a3vtLDVSaCjqvPzFLzJiSb_o6760xZbeSTwPU9Y1KqEUmUdgjXZ/s1600/Aliens+inbox+and+overflow.jpg" imageanchor="1" style="margin-left: auto; margin-right: auto;"><img border="0" height="400" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiLnmV_TSHzlmHql-t3uur9CGswhtfHkqGK2kUQ2tEozxYdjj145y2MVDdZuHe6FMJEtiIt6CmPMdOEtwWZFmZEYGUN8a3vtLDVSaCjqvPzFLzJiSb_o6760xZbeSTwPU9Y1KqEUmUdgjXZ/s400/Aliens+inbox+and+overflow.jpg" width="158" /></a></td></tr>
<tr><td class="tr-caption" style="text-align: center;">A little humor from Team Aliens: Guess which is the overflow :)</td></tr>
</tbody></table>
<br /><h4>
Overflow </h4>
As reality occurs, new backlog items are discovered, actual velocity is realised and planned velocity is updated this area comes into play. Any backlog items for the PI which will not fit based on the planned velocity are moved to the overflow to highlight the priority decisions being made by the Product Owner. <br /><br /><h3>
Backlog Refinement </h3>
Whilst supporting the sensitivity that led to this practice acquiring its new name, the unfortunate reality is that it most commonly seems to lead to people missing the key activity. Knowing that story elaboration is taken care of through specification workshops, the primary focus for refinement becomes the management of content and priority of the PI backlog for the team. <br /><br />I generally place this on cadence either once per week or once per sprint as a one hour session. It is the responsibility of the product owner, but best performed as a shared activity with the scrum master. As this is an alignment activity, I also look for all teams on the train to schedule their backlog refinement session on the same day (leaving it open to the team what time of day). Motivations for this will become clear when we proceed to Program Backlog Refinement. <br /><br />Key activities will include: <br /><br /><ul>
<li>Updating velocity forecasts: This is obviously data provided by the scrum-master, but may shift either based on yesterday’s weather or as team leave comes into focus. </li>
<li>Process the inbox: All stories from the inbox which have passed through the established entry conventions should be inserted into the backlog in the relevant sprint based on the product owner’s priorities. </li>
<li>Adjust scheduling to match capacity: Based on the updated velocity forecasts (and any newly incorporated stories), any overloaded sprints should have stories shuffled back down to future sprints until the load level falls below forecast velocity (or other agreed load constraints). This will often result in stories from the final sprint in the PI being moved into the overflow. </li>
<li>Validate commitment cards: Cast an eye over all the commitment cards in the backlog, asking the following questions: </li>
<ul>
<li>“Will we still be able to honour this commitment?” </li>
<li>“Will this reprioritisation affect a commitment we’ve made?” </li>
<li>“Do our changed circumstances mean we no longer require another team to meet the commitment they have made to us?” </li>
</ul>
<li>Adjust priorities: Now that the backlog has incorporated the inbox and been adjusted based on capacity and commitments, review for priority updates. At a bare minimum, take a good hard look at the overflow area and see whether any of those cards need to be traded back in and others demoted. </li>
</ul>
<br />On a final note, I suggest using a flagging system during refinement. Place a flag (and accompanying note) on any card that moves. This supports the following: <br /><ul>
<li>Updating the digital tool to reflect any changes made to the physical backlog. </li>
<li>Updating the team at standup the next day on the outcomes of the refinement session. </li>
<li>Informing program backlog refinement. </li>
</ul>
<div>
<h3>
Program Backlog Refinement </h3>
Whilst not formally specified in SAFe, I have found this to be an essential extension as a synchronization event. You will recall that all teams put their team level backlog refinement session on cadence to occur on the same day. We leverage this by placing the program backlog refinement ceremony on the following day. Quite often, we settle on Thursdays for teams and Fridays for the program. This is based on the fact that teams commonly adopt “Wednesday to Tuesday” sprints. You’re then refining the backlog the day after Sprint Planning (to reflect any updates coming out of the planning session) and on day 7 of the sprint (by which time you’ve discovered some new surprises and have a good clue of any stories which might slip the sprint boundary). <br /><br />The ceremony has two phases – often with slightly different participation: <br /><br /><b>Team Updates (<30 minutes)</b> <br /><br />Attended by the RTE, Product Manager, ScrumMasters and Product Owners. <br /><br />All teams provide an update of any outcomes from their backlog refinement session which may affect other teams. The focus is on moving or at-risk commitments. Typically held at the program level visualization (whether it be program board or something else). <br /><br /><b>Overflow Review (30-45 minutes)</b> <br /><br />Attended by the Product Manager, Product Owners, RTE and potentially other stakeholders. <br /><br />This is a “management by walking around” exercise. The group moves from team area to team area, with a particular focus on the contents of the overflow areas. Using the flags applied during team backlog refinement, the product owner walks through the outcomes of the previous day’s refinement and validates their prioritization calls. <br /> <br />It provides the group with insight into areas where the overflow is mounting or critical commitments are entering high-risk status. This information can then be fed into the release management meeting to support program level decision making on moving scope to other teams or establishing effective mitigation strategies. <br /><h3>
Conclusion </h3>
An agile plan lives. In the spirit of transparency, it always reflects the current reality and beliefs of the train. It is critical on many fronts: <br /><ul>
<li>Supporting a team maintaining ownership of their larger commitments, avoiding the trap of living only for the current sprint and losing sight of their commitment to a broader mission. </li>
<li>Supporting ongoing synchronisation of plans across all the teams in a train </li>
<li>Supporting effective trade-off decision making by the Release Management Team </li>
<li>Providing early warning to support effective mitigation activities as the plan fails to survive contact with the enemy. </li>
</ul>
<br />The PI planning event provides an amazing springboard, but effective planning must be continuous and based on a transparent reflection of reality. Utilising cadence and synchronisation as enablers, the practices described above are simple to implement and will provide astonishing contributions to maintaining the alignment, transparency and focus of a Release Train. <br /><br /> </div>
Mark Richardshttp://www.blogger.com/profile/12477809828045353101noreply@blogger.com0