tag:blogger.com,1999:blog-87373626232399961052024-03-13T17:51:49.219-06:00@MLCarey321The thoughts and experiences of Mike Carey, Agile CoachAnonymoushttp://www.blogger.com/profile/07829612743920787477noreply@blogger.comBlogger86125tag:blogger.com,1999:blog-8737362623239996105.post-85046957624539674522017-11-19T19:39:00.001-07:002017-11-19T19:40:06.273-07:00Gratitude<div dir="ltr" style="text-align: left;" trbidi="on">
Expressions of gratitude in November are, in my opinion, so clichéd that they run the risk of coming across as superficial, and I avoid them accordingly. So for me to post this, my first blog post in over a year, in the month of November, on the topic of gratitude, is not something I take lightly.<br />
<br />
Whether you prefer the term blessed, privileged, lucky, whatever, I am a very fortunate man. The top of my thankful list is always my wife, but I wanted to focus this on something else. This past week I was given the opportunity to speak at a one-day conference in Minneapolis call <a href="http://agiledaytwincities.org/" target="_blank">Agile Day Twin Cities</a>. It was the first time I had ever presented at a conference by invitation rather than proposal. I met some amazing people and got to better know an awesome person I'd previously met. I was treated as a peer by people I consider to be well out of my league. It was humbling and exhilarating and it never would have happened if I hadn't been invited to speak.<br />
<br />
I'm not naming names here because these awesome people are also humble; plus, I don't want to come across as a suck-up or name dropper. But, if they're reading this, they know who they are, and I want them to know how grateful I am. I intend on expressing that gratitude by taking the opportunities they've afforded me, making them proud, and paying it forward.<br />
<br />
I was so caught up in each moment that I didn't take any selfies or anything, but you can see pictures from the conference <a href="https://twitter.com/hashtag/adtc2017?f=images&vertical=default" target="_blank">on Twitter</a>. I plan on making this blog much more meaningful in 2018.</div>
Anonymoushttp://www.blogger.com/profile/07829612743920787477noreply@blogger.com0tag:blogger.com,1999:blog-8737362623239996105.post-86932651990005944692016-08-22T20:51:00.000-06:002016-08-22T20:51:56.982-06:00Agile2016 Things<table align="center" cellpadding="0" cellspacing="0" class="tr-caption-container" style="margin-left: auto; margin-right: auto; text-align: center; width: 100%;"><tbody>
<tr><td style="text-align: center;"><a href="http://makeitstranger.com/" imageanchor="1" style="margin-left: auto; margin-right: auto;" target="_blank"><img border="0" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgNTOaQmVyViRfMnT52FaWsNL_JUDrokCjQtbHGxmvNp7xq4Ed29Uc2gPGZqKICQefSQqEmt1JTIexNS4hyphenhyphenHTJi5W1OrCo-3RgxJNAOOEnLi_NktdDWzjbL3zXKZzIKpeTx1Ve6uzJNWdo/s320/agile2016-things.png" width="100%" /></a></td></tr>
<tr><td class="tr-caption" style="text-align: center;">BTW, have you watched "Stranger Things" yet? Amaze-balls!</td></tr>
</tbody></table>
<div>
I’ve had two great opportunities to learn and reflect this summer. The first was the <a href="http://agile2016.sched.org/" target="_blank">Agile2016 Conference</a>, and the second came 3 weeks later when I took my family on a beach vacation. Those two weeks have allowed me to mentally prepare for what happened today: I went from zero direct reports to four who, along with my technical lead that reports to our Director of Engineering, comprise the team that I will be leading in developing cloud-hosted solutions for Walmart’s brick-and-mortar stores. It will be my first time leading a team in my current capacity, much less leading one where the majority of the team members are brand new to both each other and the company itself. Here are some things I’ve decided to try with my new team.</div>
<div>
<br /></div>
<div>
1)<span class="Apple-tab-span" style="white-space: pre;"> </span><a href="http://www.slideshare.net/AgileME/managing-for-happiness-by-jurgen-appelo/7" target="_blank">Personal Maps</a></div>
<div>
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhPnBiuCqOhStvo1lBW-9e5UUgSvOA5k_e2BvK9iWKXLpjF8aJ3WyRyHLt60m_ekejKJvjDdVKXawUMwmEfxFX1O8k8mLYUZ8y5AgWGWz_MO_F8MjtZ315KyFF671pd-2FRjX6T0fdNNXk/s1600/managing-for-happiness-by-jurgen-appelo-7-638.jpg" imageanchor="1" style="clear: right; float: right; margin-bottom: 1em; margin-left: 1em;"><img border="0" height="112" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhPnBiuCqOhStvo1lBW-9e5UUgSvOA5k_e2BvK9iWKXLpjF8aJ3WyRyHLt60m_ekejKJvjDdVKXawUMwmEfxFX1O8k8mLYUZ8y5AgWGWz_MO_F8MjtZ315KyFF671pd-2FRjX6T0fdNNXk/s200/managing-for-happiness-by-jurgen-appelo-7-638.jpg" width="200" /></a>I actually want to try a whole bunch of things that Jurgen introduced in his opening keynote, but this is the one I’m starting with. I’m working on mine now and, on Wednesday, my tech lead and I will present ours to the team. We’ll give them about a week, and then they’ll share theirs. I will keep mine up-to-date in a digital format that I can share with any other new team members that arrive in the future, as well as all of my friends here on the Internet.</div>
<div>
<div class="separator" style="clear: both; text-align: left;">
<br /></div>
2)<span class="Apple-tab-span" style="white-space: pre;"> </span><a href="http://modernagile.org/" target="_blank">Modern Agility</a></div>
<div>
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiYe6h6YDHu6Qo1YTRE_B_Zu5lnGidTsu9ZQe0EcmZpXmbb4dZa72uyvDWX1wrNIaR_vrfZavX6qNEXXEPOQqZD4bBiHkBGn94cknJOczQ7x04mjHnuPAyzzylYyrrHss9DXxe4zG0EnlA/s1600/Modern+Agile+Wheel.png" imageanchor="1" style="clear: right; float: right; margin-bottom: 1em; margin-left: 1em;"><img border="0" height="120" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiYe6h6YDHu6Qo1YTRE_B_Zu5lnGidTsu9ZQe0EcmZpXmbb4dZa72uyvDWX1wrNIaR_vrfZavX6qNEXXEPOQqZD4bBiHkBGn94cknJOczQ7x04mjHnuPAyzzylYyrrHss9DXxe4zG0EnlA/s200/Modern+Agile+Wheel.png" width="120" /></a>I’ve joined the <a href="http://modernagile.slack.com/" target="_blank">Slack team</a>, followed them on <a href="https://twitter.com/modernagile" target="_blank">Twitter</a>, joined the <a href="https://www.facebook.com/groups/1124289160962145/" target="_blank">Facebook group</a>, and plan on getting involved with their open source <a href="https://github.com/modernagile" target="_blank">repo on GitHub</a>. I’m not sure what exactly I’m going to do with all this, but I’ve got the <a href="http://modernagile.org/#mediaKit" target="_blank">sticker</a> on my laptop that reminds me everyday to Make People Awesome; Deliver Value Continuously; Make Safety a Prerequisite; and Experiment & Learn Rapidly. I’ll be re-watching Joshua’s mid-conference keynote when I share it with the team and perusing his slides for further hints and advice on how I can implement Modern Agility on my team.</div>
<div>
<br /></div>
<div>
3)<span class="Apple-tab-span" style="white-space: pre;"> </span><a href="https://www.agilealliance.org/resources/videos/scaling-product-development-more-product-learning-without-more-process-focus" target="_blank">Focus on Impact</a></div>
<div>
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgoV7-f6GwNxCAm43hBFYJthlHQ7RsaOy1x5KHHlQnwhppF7952wiCX4DAvl_AN1OvRY2N0TeFI8UYO2hVCyckuz6fMU1bKAk3i0ee1cfcV-m_6NeiF_ju_BFysuWPfnGfGlg5UGodLtLk/s1600/Screen+Shot+2016-08-22+at+10.42.41+PM.png" imageanchor="1" style="clear: right; float: right; margin-bottom: 1em; margin-left: 1em;"><img border="0" height="72" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgoV7-f6GwNxCAm43hBFYJthlHQ7RsaOy1x5KHHlQnwhppF7952wiCX4DAvl_AN1OvRY2N0TeFI8UYO2hVCyckuz6fMU1bKAk3i0ee1cfcV-m_6NeiF_ju_BFysuWPfnGfGlg5UGodLtLk/s320/Screen+Shot+2016-08-22+at+10.42.41+PM.png" width="320" /></a>The conversation in the Agile community has been trending more and more to value, but I most like the term that David Hussman used: impact. Before our team builds anything, we’ll define the impact it will have once it’s been delivered. We won’t work on things that don’t have impact, and we won’t call it done until we’ve validated whether or not the impact was made. </div>
<div>
<br /></div>
<div>
4)<span class="Apple-tab-span" style="white-space: pre;"> </span>Shorten Improvement Cycles</div>
<div>
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiIf_Hr35euoFlh7wh_ZbQckZECZM8Vy9JlTS8d8FxYIrfkJsyg-dG-y-VVKMJ1_TcfIXI7_kISPB2BaE3H5iODHU9y0Dd_Xv4Mg_We17CAXSUXhaOqAAexkXAiFTnsu6LRA_nEZAPCSds/s1600/04869401b40cb30460671a973aa475999be63146.png" imageanchor="1" style="clear: right; float: right; margin-bottom: 1em; margin-left: 1em;"><img border="0" height="159" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiIf_Hr35euoFlh7wh_ZbQckZECZM8Vy9JlTS8d8FxYIrfkJsyg-dG-y-VVKMJ1_TcfIXI7_kISPB2BaE3H5iODHU9y0Dd_Xv4Mg_We17CAXSUXhaOqAAexkXAiFTnsu6LRA_nEZAPCSds/s200/04869401b40cb30460671a973aa475999be63146.png" width="200" /></a>Following the conference, I had lunch with <a href="https://twitter.com/WoodyZuill" target="_blank">Woody Zuill</a> of <a href="https://twitter.com/search?q=%23NoEstimates&src=typd" target="_blank">#NoEstimates</a> and <a href="https://twitter.com/search?q=%23MobProgramming&src=typd" target="_blank">#MobProgramming</a> fame. He talked about the process by which Mob Programming came into existence. He was trying to help the team learn how to identify what’s working and what’s not by holding short, daily retrospectives. By narrowing the timeframe for inspecting and adapting, the team could more easily pinpoint daily activities that were beneficial or not. As a software engineer, I see the daily retrospective as the algorithm that produced the solution of Mob Programming, and I want to see what kind of results it produces when I provide my team as the input to that algorithm.</div>
<div>
<br /></div>
<div>
5)<span class="Apple-tab-span" style="white-space: pre;"> </span><a href="http://www.slideshare.net/AgileME/managing-for-happiness-by-jurgen-appelo/61" target="_blank">Highlight Learning, not Failure</a></div>
<div>
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhTYE9oYO7fpS-Q86imAJyrWth0BPFcZN06McQqZmTY1gFBFMmJtsFwmtIC-6lK501YWHajqtJevFnlmA5EgFDgjxLuOPzNKCkxOzjNV3DwPlD1O4WIERTdARwm6g1aQGjP0FRo8dJaj-g/s1600/managing-for-happiness-by-jurgen-appelo-61-638.jpg" imageanchor="1" style="clear: right; float: right; margin-bottom: 1em; margin-left: 1em;"><img border="0" height="112" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhTYE9oYO7fpS-Q86imAJyrWth0BPFcZN06McQqZmTY1gFBFMmJtsFwmtIC-6lK501YWHajqtJevFnlmA5EgFDgjxLuOPzNKCkxOzjNV3DwPlD1O4WIERTdARwm6g1aQGjP0FRo8dJaj-g/s200/managing-for-happiness-by-jurgen-appelo-61-638.jpg" width="200" /></a>Coming back full circle to Jurgen’s “Managing for Happiness” keynote, I want to use the Celebration Grid approach in our fortnightly retrospectives to highlight learning. I’ve grown accustomed to the “Fail Fast” language that permeates the Agile community, though I always use the <a href="https://www.youtube.com/watch?v=X3rGdmoTjDc&feature=youtu.be&t=51s" target="_blank">Spotify language</a> of “fail fast to learn fast to improve fast”. Well, if you fail fast but don’t learn from it then it’s not useful, so why not focus on the learning and not the failure?</div>
<div>
<br /></div>
<div>
Those are my five action items following a weeklong conference, a week of restful reflection, and challenge of leading a brand new team for the first time. If you attended #Agile2016, what were your takeaways? If you’ve ever been in a situation similar to mine, what advice do you have for me? I look forward to hearing from you!</div>
Anonymoushttp://www.blogger.com/profile/07829612743920787477noreply@blogger.com0tag:blogger.com,1999:blog-8737362623239996105.post-32854163686510656632015-09-01T13:38:00.000-06:002015-09-01T13:38:44.013-06:00How Walmart is Going Agile with… How Many Coaches?!?<b><i>Please note that the views expressed here are my own and do not necessarily reflect those of Walmart.</i></b><br />
<b><i><br /></i></b>
Walmart Stores, Inc. is the world’s largest retailer, a Fortune 1 company, which spans 28 countries with over 60 different banners. Many in the tech world may know about Walmart.com or @WalmartLabs, significant and important arms of Walmart’s Technology organization located in the rich technical environment of California’s Silicon Valley. What many people don’t know is that the bulk of Walmart’s tech talent lives and works in the heart of Walmart country, at their headquarters in Bentonville, Arkansas.<br />
<br />
There you can find thousands of associates working hard to support associates in the home office, stores, clubs, and distribution centers, as well as our customers. It’s been the hub of Walmart’s technical solutions for decades and has been subjected to many of the struggles and opportunities that other long-lived IT departments have faced, including the recent challenge to “Go Agile”. And they’re doing it!<br />
<br />
With four Agile Coaches.<br />
<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/AVvXsEjzIrq7qtpNRHfyeroKuFZ_Rbd0OVzBsURDwsOU3-F3HwMh3f39_BVT-QND7wh2YsZfhv1btgEUFmN69AsXbieRO6K6_6LeY7Ghcp5c_lgpI0FSHVTwy1RFhUNJOv4QPKFCXB80yU5MUK0/s1600/Guardians+of+the+Agile+Transformation.jpg" imageanchor="1" style="margin-left: auto; margin-right: auto;"><img border="0" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjzIrq7qtpNRHfyeroKuFZ_Rbd0OVzBsURDwsOU3-F3HwMh3f39_BVT-QND7wh2YsZfhv1btgEUFmN69AsXbieRO6K6_6LeY7Ghcp5c_lgpI0FSHVTwy1RFhUNJOv4QPKFCXB80yU5MUK0/s320/Guardians+of+the+Agile+Transformation.jpg" width="95%" /></a></td></tr>
<tr><td class="tr-caption" style="text-align: center;">The Agile Coaches Group in Summer 2015 (with our corresponding Guardians of the Galaxy bobbleheads)<br />
From left: Spencer Offenbacker (Product Manager); Mike Carey (author); Todd Kromann; Joshua Rowell; Amanda Tygart</td></tr>
</tbody></table>
<br />
<h3>
Only Four Agile Coaches?</h3>
That’s right. Walmart’s Information Systems Division employs only four full-time Agile Coaches – all internal – to lead the transformation effort for thousands of associates. They serve not only those working in Bentonville; the Agile Coaches have traveled to Mexico, Costa Rica, the United Kingdom, and India to help with the Agile transformation efforts in those offices. As the work of transformation continues to grow, Walmart ISD's Agile Coaches will likely travel to Walmart’s other development centers around the world in the coming years.<br />
<br />
<table align="center" cellpadding="0" cellspacing="0" class="tr-caption-container">
<tbody>
<tr>
<td style="text-align: center; vertical-align: bottom;" width="50%"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjVXwyUxshM7ms4mqHoJ_GjRJvbSxp0QwQM_J0A95W-g3qPwykAOcDoco_ce74Qm_UU5X0AYdM6ksvmCFULWg5rSW7F_Dpcimxiq9iHoNSfgcvDxWR4NUeXq0jmBNofc4G-YJFJF8IECsw/s1600/CR_Guatemalans.jpg" imageanchor="1" style="margin-left: auto; margin-right: auto;"><img border="0" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjVXwyUxshM7ms4mqHoJ_GjRJvbSxp0QwQM_J0A95W-g3qPwykAOcDoco_ce74Qm_UU5X0AYdM6ksvmCFULWg5rSW7F_Dpcimxiq9iHoNSfgcvDxWR4NUeXq0jmBNofc4G-YJFJF8IECsw/s320/CR_Guatemalans.jpg" width="95%" /></a></td>
<td style="text-align: center; vertical-align: bottom;" width="50%"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgMqsD-hGFpzQHhlirwew3aJAEUFzbY9fUbOVzLtlKJtFCCucr_kvL_fYHY-aWuuRZOr66Qgyor549LLFFJ5DU2O1UITOFpXRosip32cnU8I7LbPXC4O0cKkDvSWR1AxwGJJtJGT1pAV7U/s1600/MX+Champions+01+.jpg" imageanchor="1" style="margin-left: auto; margin-right: auto;"><img border="0" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgMqsD-hGFpzQHhlirwew3aJAEUFzbY9fUbOVzLtlKJtFCCucr_kvL_fYHY-aWuuRZOr66Qgyor549LLFFJ5DU2O1UITOFpXRosip32cnU8I7LbPXC4O0cKkDvSWR1AxwGJJtJGT1pAV7U/s320/MX+Champions+01+.jpg" width="95%" /></a></td>
</tr>
<tr>
<td class="tr-caption" style="text-align: center; vertical-align: top;" width="50%">Mike Carey (author) with two associates from Guatemala while coaching in Costa Rica</td>
<td class="tr-caption" style="text-align: center; vertical-align: top;" width="50%">Mike Carey (author) with associates in Walmart's GTS (Global Technology Services) - Mexico office</td>
</tr>
<tr>
<td style="text-align: center; vertical-align: bottom;" width="50%"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiCpQB2IQWpKYEEu8vH_KQ9IkduDlcfkzJnzc69I1GzDbiY-eA9_99RAIfPXCHHi_jox66cY-92kmn3-9yqTS8AxdfJD-upbqDLVR3xQxVWRX2VrmeQ3Z0FgkJS760rhfwIPX0T1FOVhNA/s1600/MX+Champions+02.jpg" imageanchor="1" style="margin-left: auto; margin-right: auto;"><img border="0" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiCpQB2IQWpKYEEu8vH_KQ9IkduDlcfkzJnzc69I1GzDbiY-eA9_99RAIfPXCHHi_jox66cY-92kmn3-9yqTS8AxdfJD-upbqDLVR3xQxVWRX2VrmeQ3Z0FgkJS760rhfwIPX0T1FOVhNA/s320/MX+Champions+02.jpg" width="95%" /></a></td>
<td style="text-align: center; vertical-align: bottom;" width="50%"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjQy7bApIBWnNpV7GWDbiLUV6U6SGtH6LLZidCtJ2IyggijrpzYxWSFIpftqQ2JMaIevAsEx2kHBE8MWLUtt0fMEm4yXUutGcnA_GQQL6Ni_4Vn-IT2H9IoiL1eeZFEvBM2U4CXyxnhLiM/s1600/GTS+Open+Space.jpg" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjQy7bApIBWnNpV7GWDbiLUV6U6SGtH6LLZidCtJ2IyggijrpzYxWSFIpftqQ2JMaIevAsEx2kHBE8MWLUtt0fMEm4yXUutGcnA_GQQL6Ni_4Vn-IT2H9IoiL1eeZFEvBM2U4CXyxnhLiM/s320/GTS+Open+Space.jpg" width="95%" /></a></td>
</tr>
<tr>
<td class="tr-caption" style="text-align: center; vertical-align: top;" width="50%">Mike Carey (author) with more associates from Walmart's GTS (Global Technology Services) - Mexico office</td>
<td class="tr-caption" style="text-align: center; vertical-align: top;" width="50%">Associates in our GTS (Global Technology Services) - India office participating in an Open Space event facilitated by Agile Coach Todd Kromann</td>
</tr>
<tr>
<td style="text-align: center; vertical-align: bottom;" width="50%"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEi7nvxx5tuDjay8KgCK15RL7_vWblJPdVWxJG3e6sdTEXmXvlWSipUihYcvWKFhQf9ldVAebJoP0u_Eh_fYs-DVsCq67zdvGPaZ13TT2W2Jo0VD9QvhOOjrnWRWyOe3G_raW1olOw0EQBY/s1600/IN+Coaching.jpg" imageanchor="1" style="margin-left: auto; margin-right: auto;"><img border="0" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEi7nvxx5tuDjay8KgCK15RL7_vWblJPdVWxJG3e6sdTEXmXvlWSipUihYcvWKFhQf9ldVAebJoP0u_Eh_fYs-DVsCq67zdvGPaZ13TT2W2Jo0VD9QvhOOjrnWRWyOe3G_raW1olOw0EQBY/s320/IN+Coaching.jpg" width="95%" /></a></td>
<td style="text-align: center; vertical-align: bottom;" width="50%"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhok4-7rwuDCdK77gN2ueImMK6m7HtcZLu72Re75hHS8PjQAVzZVdvxpmULC2IHdXJT0tcSlBVBEFWWcCZ8WDltferK5fTJHb8A0N3vXgOIzKItQvo2nr_u7_PzUMLanyUF_BtW1uuVjHM/s1600/Amanda+Mexico+Champions.jpg" imageanchor="1" style="margin-left: auto; margin-right: auto;"><img border="0" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhok4-7rwuDCdK77gN2ueImMK6m7HtcZLu72Re75hHS8PjQAVzZVdvxpmULC2IHdXJT0tcSlBVBEFWWcCZ8WDltferK5fTJHb8A0N3vXgOIzKItQvo2nr_u7_PzUMLanyUF_BtW1uuVjHM/s320/Amanda+Mexico+Champions.jpg" width="95%" /></a></td>
</tr>
<tr>
<td class="tr-caption" style="text-align: center; vertical-align: top;" width="50%">Todd Kromann with an associate in our GTS (Global Technology Services) - India office</td>
<td class="tr-caption" style="text-align: center; vertical-align: top;" width="50%">Amanda Tygart with associates from Walmart de Mexico y Centroamerica ISD</td>
</tr>
</tbody></table>
<br />
Walmart’s Agile Coaches are also not long-tenured positions. The Agile Coach role is viewed more as a sabbatical for those who have passion for Agile and have already garnered a reputation for assisting those around them with their transition to Agile. I know this well, because I used to be an Agile Coach. Todd Kromann and I were the first two Agile Coaches for Walmart ISD, a role I enjoyed for over a year and a half before leaving to take another position within the company. This helps ensure the working knowledge and skills of the Agile Coaches are relevant to the changing demands that come with an ever-shifting technological landscape.<br />
<br />
<table align="center" cellpadding="0" cellspacing="0" class="tr-caption-container"><tbody>
<tr><td style="text-align: center; vertical-align: bottom;" width="50%"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhzR8Ltcba4aezeL2mxAlnu-Vh584VxJAaRQKpilq3OKBuRMAMxcZJTFboQRrMfQjkS2vFJclO-BXSDee0pN3r27QCb_EsWiCM2PJO5DORkl4xw2oy4emkEEgGZX0L62HZyG1rzZzP9mxU/s1600/Agile2014+Dudes+Law.jpg" imageanchor="1" style="margin-left: auto; margin-right: auto;"><img border="0" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhzR8Ltcba4aezeL2mxAlnu-Vh584VxJAaRQKpilq3OKBuRMAMxcZJTFboQRrMfQjkS2vFJclO-BXSDee0pN3r27QCb_EsWiCM2PJO5DORkl4xw2oy4emkEEgGZX0L62HZyG1rzZzP9mxU/s320/Agile2014+Dudes+Law.jpg" width="95%" /></a></td>
<td style="text-align: center; vertical-align: bottom;" width="50%"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjsWIc5Qx79XjclDv-8bz7G7c7QA-MomWL_aDJGc-KIFYpUTZ0WpuHLKip_VFd3JVWaE61AiyfTZH5o-T-_su0W12iWcbRENG1n7zXLZnUOze_BrxhdP8jpYUi_ffTaKM8noo4ZHrnAAAk/s1600/Agile2014+Wave+Riding.jpg" imageanchor="1" style="margin-left: auto; margin-right: auto;"><img border="0" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjsWIc5Qx79XjclDv-8bz7G7c7QA-MomWL_aDJGc-KIFYpUTZ0WpuHLKip_VFd3JVWaE61AiyfTZH5o-T-_su0W12iWcbRENG1n7zXLZnUOze_BrxhdP8jpYUi_ffTaKM8noo4ZHrnAAAk/s320/Agile2014+Wave+Riding.jpg" width="95%" /></a></td></tr>
<tr><td class="tr-caption" style="text-align: center; vertical-align: top;" width="50%">The first two Agile Coaches for Walmart ISD - Mike Carey (author) and Todd Kromann - presenting at #Agile2014</td>
<td class="tr-caption" style="text-align: center; vertical-align: top;" width="50%">At #Agile2014, from left: Mike Carey (author, 2nd Agile Coach); Barry Nicholson (3rd Agile Coach); Selena Hriz (Core Champion); Amanda Tygart (4th Agile Coach); Todd Kromann (1st Agile Coach); Subhendu Mishra (Core Champion)</td>
</tr>
</tbody></table>
<br />
Wait, so not only does Walmart only have four Agile Coaches for thousands of associates worldwide, they also rotate on a 1-3 year basis? How does that work?<br />
<br />
With the help of Agile Champions.<br />
<br />
<h3>
What’s an “Agile Champion”?</h3>
In September 2014 we officially launched what we call the “Agile Champion Network”. We implemented the concept of Agile Champions for months prior to solidifying it into a useful structure, and found that the use of Agile Champions was invaluable to the Agile Coaches keeping their WIP in check. On September 26th we held an Open Space to kick things off, and a blog post was published on the 18th to help lay the foundation for what we were trying to accomplish. Below is a snippet from that blog post:<br />
<i></i><br />
<div style="margin-left: 5%; width: 90%;">
<i>“The objective of this event is to crowd-source the collective intelligence and skill of our Associates to determine:</i><br />
<i><br /></i>
<i>"What are the responsibilities of an Agile Champion?</i><br />
<i><br /></i>
<i>"How do we identify existing and emerging Agile Champions?</i><br />
<i><br /></i>
<i>"How can we better leverage our Agile Champions?</i><br />
<i><br /></i>
<i>“As we've been preparing for this event, one of the frequently raised questions is ‘What's the difference between an Agile Coach and an Agile Champion?’</i><br />
<i><br /></i>
<i>“I'll start by covering what they have in common. Both have a solid understanding of the Agile mindset, or what it means to ‘Be Agile’. Both are change agents who seek to increase value delivery and reduce waste. Both assist others seeking help with their personal or team Agile adoption.</i><br />
<i><br /></i>
<i>“Now let's look at the differences.</i><br />
<i><br /></i>
<i>“An Agile Champion is only expected to have a deep understanding of at least one facet of ‘Doing Agile’. Agile Coaches have a broad understanding of Agile practices, with depth of knowledge and experience in many facets.</i><br />
<i><br /></i>
<i>“An Agile Champion assists others part-time; he or she is an active practitioner on an Agile team or project. Agile Coaches have experience as a practitioner (and we have organized ourselves as an Agile team), but our full-time job is to assist others.</i><br />
<i><br /></i>
<i>“[…] The Agile Coaches have an immense responsibility for such a small team, which is why the Agile Champions are so important. The leadership and initiative of our Agile Champions take some of the load off our backlog, allowing more people to get the assistance they need. If you are interested in taking a more active role in the adoption of both ‘Being’ and ‘Doing Agile’, please plan to attend the Agile Champion Open Space next Friday.”</i></div>
<br />
Out of the Open Space, it was determined that an Agile Champion should possess the following traits or skills:<br />
<br />
<ul>
<li>Knowledgeable about one or more specific aspects of Being or Doing Agile and have a willingness to share that knowledge</li>
<li>Credibility in the organization</li>
<li>Excellent interpersonal and communication skills</li>
<li>Ability to demonstrate the Walmart Culture</li>
<li>Passionate, positive and enthusiastic attitude</li>
<li>Commitment to continuous learning and improvement</li>
</ul>
Agile Champions opt-in to the network, where those seeking assistance can find them and reach out. Champions register with their name, the skills with which they can help others, their location, the number of hours per week they are typically available, and a few other pieces of information. Those seeking help can search by skill and further sort or filter by any of the other attributes before selecting someone to reach out to. We currently have nearly 100 Agile Champions across half a dozen locations worldwide, all willing and able to help their peers through this journey.<br />
<br />
<table align="center" cellpadding="0" cellspacing="0" class="tr-caption-container"><tbody>
<tr>
<td style="text-align: center; vertical-align: bottom;" width="100%"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjV8OSfGt-hsUWmnQQ3lBDItXk6pXgOOZsdvWtTmgaLAfOcwqkMeYISFw7eAAQAAs_h8wizIDLYr1LhuoVfDRUb_-AvF_xmcI7On-XXho0Ts6X52AM6E_KIrU7WUgz8a7W5Ts71xzikO30/s1600/Agile2015+Super+Heroes.jpg" imageanchor="1" style="margin-left: auto; margin-right: auto;"><img border="0" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjV8OSfGt-hsUWmnQQ3lBDItXk6pXgOOZsdvWtTmgaLAfOcwqkMeYISFw7eAAQAAs_h8wizIDLYr1LhuoVfDRUb_-AvF_xmcI7On-XXho0Ts6X52AM6E_KIrU7WUgz8a7W5Ts71xzikO30/s320/Agile2015+Super+Heroes.jpg" width="95%" /></a></td>
</tr>
<tr>
<td class="tr-caption" style="text-align: center; vertical-align: top;" width="100%">Walmart Coaches and Champions at #Agile2015<br />
Standing, from left: Amanda Tygart (Agile Coach, ISD); Amber Wright (US Agile Champion); Marc Thomsen (UK Agile Champion); Jenny Swan (US Agile Champion); Robert Moores (UK Agile Champion)<br />
Kneeling, from left: Tony Goulart (eCommerce Agile Coach); Luis Figaro (Brazil eCommerce Agile Coach); Jerry Schroeder (US Agile Champion)</td>
</tr>
<tr>
<td style="text-align: center; vertical-align: bottom;" width="100%"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEji4nKkJNQ00LeRII4V2bEtrNCVfiXmzgupj25ZBQEZpsPZiAAKTsHnUWwTqxt_3nEhrRLinNw70fAxDfpNimfmAxT1cRDsu6ZVIirbBlB9luXiiGHoUzVqJZgqsKUl-i8ixQCX_yMUCBU/s1600/Agile+Dinner+with+Arturo.jpg" imageanchor="1" style="margin-left: auto; margin-right: auto;"><img border="0" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEji4nKkJNQ00LeRII4V2bEtrNCVfiXmzgupj25ZBQEZpsPZiAAKTsHnUWwTqxt_3nEhrRLinNw70fAxDfpNimfmAxT1cRDsu6ZVIirbBlB9luXiiGHoUzVqJZgqsKUl-i8ixQCX_yMUCBU/s320/Agile+Dinner+with+Arturo.jpg" width="95%" /></a></td>
</tr>
<tr>
<td class="tr-caption" style="text-align: center; vertical-align: top;" width="100%">Clockwise from front-left: Mike Carey (author, Agile Coach); Arturo Robles Maloof (MX Agile Champion); Joshua Rowell (Agile Coach); Jessica Collins (US Agile Champion); Barry Nicholson (former Agile Coach, Agile Tools Product Owner); Todd Kromann (Agile Coach); Amanda Tygart (Agile Coach)</td>
</tr>
<tr>
<td colspan="2" style="text-align: center; vertical-align: bottom;" width="100%"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEj4qfmP8Al_Xj16F3pY0hEoCgYRum8P7nIjRQ0OiQTkBVFOcd-Xq46Y4ytEobbkJ7D-eaGfMu-IQv3SL0MTji5P69570MOXUw6PJekdEfglrwqECF8i3gA-Ioiuq432ZeYVQTjX8kQc8Ew/s1600/Remotes+Dinner+Group.jpg" imageanchor="1" style="margin-left: auto; margin-right: auto;"><img border="0" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEj4qfmP8Al_Xj16F3pY0hEoCgYRum8P7nIjRQ0OiQTkBVFOcd-Xq46Y4ytEobbkJ7D-eaGfMu-IQv3SL0MTji5P69570MOXUw6PJekdEfglrwqECF8i3gA-Ioiuq432ZeYVQTjX8kQc8Ew/s320/Remotes+Dinner+Group.jpg" width="95%" /></a></td>
</tr>
<tr>
<td class="tr-caption" colspan="2" style="text-align: center; vertical-align: top;" width="100%">A sampling of Walmart Associates (mostly Agile Coaches and Champions) and significant others from around the world at an "ISD Remotes" dinner, hosted by the internal Agile Community</td>
</tr>
</tbody></table>
<br />
<h3>
The “Revolving Door” We Love</h3>
In addition to the self-service network, the Agile Coaches keep a pool of at least six Core Champions at all times to whom they frequently pass off requests for help that they know the Champions can handle. This helps the Coaches stay focused on the work that they alone have the skills or bandwidth for. Core Champions also pair with the Coaches frequently to help build up their skills and reputation. It is from this Core Champion pool that Agile Coaches are chosen (by the Agile Coaches, not management) when one leaves to take on new responsibilities.<br />
<br />
We know this is an unorthodox approach to such a massive undertaking, but we’re doing it and it seems to be working. Since officially starting our Agile Transformation in February 2014, the amount of work being done using Agile approaches has increased from around 10% to a projected 80%+ by the end of the current fiscal year. Our associates have gone from discussing whether or not Scrum is a good idea to how we can achieve Continuous Delivery. Our internal Agile Community has grown from 514 members to almost 1500, with dozens still joining every month.<br />
<br />
There is no question that our success would not have been possible without our Agile Champions. Not only do they relieve some of the pressure on the Agile Coaches, they have embraced self-organization and grown in their capacity as leaders and change agents. They are showing others what it means to be a Servant Leader and help those outside their traditional circles of influence. They are empowered and it shows.<br />
<br />
The model is simple: a small central authority (the Agile Coaches) working with a large, decentralized network of part-time "volunteers" (the Agile Champions). I highly recommend it.<br />
<br />
This post is an attempt to take the experiment and conversation that's been run inside Walmart to the outside world. I want to hear your opinions, your ideas, your critiques, your experiences. Comment on this post or reach out to me via <a href="https://twitter.com/MLCarey321" target="_blank">Twitter</a> or <a href="https://www.linkedin.com/in/mlcarey321" target="_blank">LinkedIn</a>.Anonymoushttp://www.blogger.com/profile/07829612743920787477noreply@blogger.com0tag:blogger.com,1999:blog-8737362623239996105.post-73640888287934033952015-08-17T11:52:00.000-06:002015-08-17T11:53:10.855-06:00An Agile Coach and a supervisor walked into #Agile2015...Did you hear the one about the Agile Coach and Sr. Tech Manager who walked into an Agile Conference? I didn't know where I fit in!<br />
<br />
For about a year and a half I have been an Agile Coach. Before that I was essentially the Agile Coach for a subset of the organization, and a Scrum Master before that. And before I was a Scrum Master, I was a Java developer. I've never worn a "manager" hat before.<br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEg3kc3NBc5AR0Drl9rkYS59omVrD2Hk0cH2aenSpwRXIqwta8-w2Es9XHqgvL5cLv_YbZRn1ZCRLkztcR3UyjQE0tUeu9m3QeJhNtxEgwQmof-eY2I_-x-IFJ21ELztcVtx-eWL8I9Ceck/s1600/Agile2015_banner.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEg3kc3NBc5AR0Drl9rkYS59omVrD2Hk0cH2aenSpwRXIqwta8-w2Es9XHqgvL5cLv_YbZRn1ZCRLkztcR3UyjQE0tUeu9m3QeJhNtxEgwQmof-eY2I_-x-IFJ21ELztcVtx-eWL8I9Ceck/s320/Agile2015_banner.png" width="80%" /></a></div>
<br />
Just prior to <a href="http://agile2015.agilealliance.org/" target="_blank">#Agile2015</a>, I found myself moving my family over a thousand miles away from our home of 7 years to take a position as a Sr. Tech Manager. Anyone who knows me knows that being an Agile Coach was perfect for me because that's just what I do naturally, so those behaviors - that mindset - are not going away. So how does one be both an Agile Coach and a manager?<br />
<br />
I guess we'll find out!<br />
<br />
I took advantage of the largest annual Agile conference to explore the space and get some advice from people who are far more expert than myself. I attended some fantastic sessions, including:<br />
<br />
<ul>
<li><a href="http://agile2015.sched.org/event/a0d17b280274c053d1b9af6189f055e2" target="_blank">"Mentoring vs Coaching: Show Me the Difference"</a> by <a href="https://twitter.com/lyssaadkins" target="_blank">Lyssa Adkins</a></li>
<li><a href="http://agile2015.sched.org/event/068fe06a7798e736306a07cafe9c49fd" target="_blank">"A Systems Approach to Modern Leadership"</a> by <a href="https://twitter.com/mattbarcomb" target="_blank">Matt Barcomb</a></li>
<li><a href="http://agile2015.sched.org/event/649735aaef6b4d672c3f791113488b65" target="_blank">"Build Strong Teams through Trust & Alignment"</a> by <a href="https://twitter.com/austinagile" target="_blank">David Hawks</a> and <a href="https://twitter.com/athought" target="_blank">Doc List</a></li>
<li><a href="http://agile2015.sched.org/event/5885eeb06c9b3fe5b53f6690624569d6" target="_blank">"Road to No Management"</a> by <a href="https://twitter.com/pawelbrodzinski" target="_blank">Pawel Brodzinski</a> (my colleagues found my attending this session particularly humorous)</li>
<li><a href="http://agile2015.sched.org/event/30b58b81c1bf349506a3c02081be2979" target="_blank">"Swarming: The Birds, the Bees, and Agile -or- How Managers Influence Self-Organization"</a> by <a href="https://twitter.com/dhavalpanchal" target="_blank">Dhaval Panchal</a> (and, apparently, <a href="https://twitter.com/tlperry" target="_blank">Thomas Perry</a>, though Dhaval did pretty much all the presenting)</li>
<li><a href="http://agile2015.sched.org/event/92ff95e07440a3c4f831904466179173" target="_blank">"Amplify Learning in Your Organization"</a> by, again, <a href="https://twitter.com/mattbarcomb" target="_blank">Matt Barcomb</a></li>
<li><a href="http://agile2015.sched.org/event/fde0aa42f8866ecb2d0ebf41490c869d" target="_blank">"Benefiting from Conflict - Building Antifragile Relationships and Teams"</a> by <a href="https://twitter.com/jcalabrese" target="_blank">Jake Calabrese</a></li>
</ul>
<div>
I attended several other sessions, but these in particular stood out to me. I think Lyssa's was recorded, and I certainly recommend watching it once it is posted online.</div>
<div>
<br /></div>
<div>
I'm still trying to wrap my head around everything that I learned, but here are some common themes that I've managed to identify so far:</div>
<div>
<ol>
<li>A good manager and a good Agile Coach should look an awful lot alike</li>
<li>Control is an illusion; trust and collaboration get results</li>
<li>My number one job as a manager is to work on the environment that my people work in - given the right environment, the people will thrive and value will get delivered</li>
<li>Decentralizing control (decisions) is faster and tends to drive better results...</li>
<li>... as long as you also decentralize the information necessary to make the best decisions</li>
<li>It is not enough for a person or team to be robust/resilient - we must set our sights on antifragility</li>
<li>There is no silver bullet - managers, too, must be committed to continuous improvement</li>
</ol>
<div>
<br /></div>
</div>
<div>
I will be conducting experiments based on what I've learned and sharing the results - as much as I'm able - as they come to fruition. I am under no delusion that all (or any) of my experiments will be eagerly accepted or wildly successful, but I am certain that I will learn from each of them and come out a better manager and coach.</div>
<div>
<br /></div>
<div>
So tell me, what advice do you have for me as I start this journey? Or, if you also attended <a href="http://agile2015.agilealliance.org/" target="_blank">#Agile2015</a>, what learnings would you like to share? I'm eager to learn as much as I can from as many of you as I can!</div>
Anonymoushttp://www.blogger.com/profile/07829612743920787477noreply@blogger.com0tag:blogger.com,1999:blog-8737362623239996105.post-42785768857801648262015-06-08T08:49:00.001-06:002015-06-08T08:49:25.987-06:00Life after your First Agile Project<em>This blog post is adapted from a workshop/presentation I recently led at the <a href="http://nwapmi.org/meetinginfo.php?id=88&ts=1431481290" target="_blank">May NWA PMI Professional Development Day</a>.</em>
<br />
<br />
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhaoXWdhLwtG88FCx1rg_sjRDZ6RqBoMRP8Duv8wGZBrelDASIBI9V8mXHRKvrmQN8CUu4LhyphenhyphenrzUhd8j_29bq1PnZ4ok95HVBEBhln1XGNUcYNEpx-Qc_gLlzkHhcmX_beN-ubIFabZno8/s1600/what_to_do.png" imageanchor="1" style="margin-bottom: 1em; margin-right: 1em;"><img border="0" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhaoXWdhLwtG88FCx1rg_sjRDZ6RqBoMRP8Duv8wGZBrelDASIBI9V8mXHRKvrmQN8CUu4LhyphenhyphenrzUhd8j_29bq1PnZ4ok95HVBEBhln1XGNUcYNEpx-Qc_gLlzkHhcmX_beN-ubIFabZno8/s1600/what_to_do.png" /></a>
<br />
<br />
So, you just finished your first Agile project in a Waterfall organization. Now what? Let me put my Agile Coach hat on and tell you, “It depends.” It depends on whether or not it was a positive experience and how supportive the overall organization is of this “Agile thing”. Let’s run through a few possible scenarios.
<br />
<h1>
Agile Sucks</h1>
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgbcnXr0G0xLrUr-QGn1YzbBR2mSP1lYs5A233CIUb6sXGneNaKu2Fc0YIY2TT662oVDe9rfHQZ5dkx9dWC-xFg_GRndlS8JDhhGarOB_s6LdvbuwU9cHAM6PkouIHvXI4qCx6ETeZmDa8/s1600/agile_sucks.png" imageanchor="1" style="margin-bottom: 1em; margin-right: 1em;"><img border="0" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgbcnXr0G0xLrUr-QGn1YzbBR2mSP1lYs5A233CIUb6sXGneNaKu2Fc0YIY2TT662oVDe9rfHQZ5dkx9dWC-xFg_GRndlS8JDhhGarOB_s6LdvbuwU9cHAM6PkouIHvXI4qCx6ETeZmDa8/s1600/agile_sucks.png" /></a>
<br />
<br />
You may be one of the many people whose first exposure to Agile is a negative one. Maybe your team was uncooperative. Maybe there were too many practices that were too new for the team to successfully adopt. Maybe the organization was so un-Agile that your team got exhausted from trying to swim upstream the whole time. Or maybe your team never really became an Agile team; you were a bunch of silo’d individual contributors with Waterfall mindsets trying a new front-end to the same process you’ve always used to get the job done. Whatever the reason, all you know for sure is that Agile sucks. It simply does not work; not for you, maybe not for anyone.<br />
<br />
As an Agile Coach, I am sincerely bummed if this was your experience. I wish I could have been there to help make sure you knew why you were adopting Agile, not just how to go through the motions. I wish I could have been your heat shield, to protect you from the Agile defeatists and remove organizational impediments for you. I wish I could have helped you through the forming and storming stages of a team into norming and performing, so that you could benefit from a team who, corny as it sounds, was greater than the sum of its parts. I wish I could have helped you learn how to continuously improve not all at once, but incrementally.<br />
<br />
But I wasn’t there, so what will you do? I hope that you will take pause and consider the possibility that those Agile proponents can’t all be crazy. What did they do or have that you didn’t? What might you have missed? Get involved in virtual and physical Agile communities, remain open-minded, and stuff your toolbox with as many practices and approaches as you can. Study the Agile Manifesto and its principles and recognize that what it’s defining is a mindset, not a methodology. You have to be Agile before you can successfully do Agile.<br />
<h1>
Agile Recipe</h1>
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhJszsZDCMrxVxw7KPud8w0OmQtIh77FhX748ifPFQLB9o7ujizCZPMTL-5hCHGVXpVTeuOJ_Tk7jU2nWnD3AXTmtcXIo1rauf1V2dU9FQSOANbV_9_BWKqFPP8pfW-YCW-bxGvI_AYhM8/s1600/agile_recipe.png" imageanchor="1" style="margin-bottom: 1em; margin-right: 1em;"><img border="0" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhJszsZDCMrxVxw7KPud8w0OmQtIh77FhX748ifPFQLB9o7ujizCZPMTL-5hCHGVXpVTeuOJ_Tk7jU2nWnD3AXTmtcXIo1rauf1V2dU9FQSOANbV_9_BWKqFPP8pfW-YCW-bxGvI_AYhM8/s1600/agile_recipe.png" /></a>
<br />
<br />
Maybe you had some success with Agile – or at least you think you did – and you want to keep doing it with all your future project teams. What really happened is you ran a successful Scrum project, and you’re ecstatic that you found a working recipe that will turn any team into a high-performing team. The team followed the Scrum Guide to the letter and there’s no doubt in your mind that this is what Agile is all about. Agile is Scrum, Scrum is Agile. If you follow the exact same approach, you are confident you will have similar results with your next team. After all, this is the same company, same culture, same organization support and/or impediments. Why shouldn’t you expect the same results?<br />
<br />
The short answer is because it’s not the same team. Even if some of the people are the same, if the make-up of the team isn’t exactly the same then it’s a different team. You’ll be starting back at the forming stage with a new backlog, maybe even a new Product Owner, and there’s no guarantee that this group of people will interpret and embrace the Scrum Guide the same way the old team did. Hopefully you learned enough about teaching, coaching, and/or facilitation from your last team that you can guide this new team through the same pitfalls in a faster, safer way. Hopefully you learned Servant Leadership skills that will help you get buy-in from the team to try this new thing. Hopefully.<br />
<br />
Hopefully you learn by the end of this project how much more successful the project would have been if you would have kept your previous team together. There is a cost associated with breaking up a high-performing team and knocking everyone back to the forming stage. There are also reasons that you may want to incur that cost in order to reap specific benefits, but “because the project ended” is not one of those reasons.<br />
<h1>
Keep the Scrum Team</h1>
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhW75Dr5YvYNE2TinHrHDzeEfdA3KjWsOzYTdPkxoNhZpSViQVDdpza3GG3WDWMDIBKjwwiiTUWQEOEWOy_Tmts5pmcnLDFTwoh6RB-dcxakBdrrhlpyS-n0CZcSmBibsotG4JmxL2fXzs/s1600/keep_scrum_team.png" imageanchor="1" style="margin-bottom: 1em; margin-right: 1em;"><img border="0" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhW75Dr5YvYNE2TinHrHDzeEfdA3KjWsOzYTdPkxoNhZpSViQVDdpza3GG3WDWMDIBKjwwiiTUWQEOEWOy_Tmts5pmcnLDFTwoh6RB-dcxakBdrrhlpyS-n0CZcSmBibsotG4JmxL2fXzs/s1600/keep_scrum_team.png" /></a>
<br />
<br />
Not only did you have success with the team, the team became a family. You are now a high-performing Scrum team that knows the process and each other so well that you couldn’t dream of breaking them up. You manage to keep the team together for the next project, and you hit the ground running.<br />
<br />
This is great, but you have to be careful. If you have decided that Scrum is the be-all end-all of Agile then, eventually, the team will begin to stagnate. Scrum ceremonies will become ritualistic instead of productive, thought-provoking team activities. Group-think may begin to crop up, and the electric feeling of respectful debate will flicker out of the team. Some team members may become too comfortable, others restless. If you don’t do something, you’ll lose everything you fought to keep.<br />
<br />
My hope is that you learn that Agile isn’t about following a recipe. It’s about starting with a recipe and making it your own. It’s about evolving the way you cook, trying new flavors, and learning how to transition from cook to chef. Hopefully you find all the success you were looking for and more, because our successes motivate us to keep going, keep trying.<br />
<br />
Become comfortable with mining for conflict and facilitating conflict to unearth change that will make the team better. Stay in tune with the latest ideas and do your best to keep the team in the “Learning Zone”.<br />
<h1>
Grow the Agile Team</h1>
<table cellpadding="0" cellspacing="0" class="tr-caption-container" style="margin-left: 0em; margin-right: auto; text-align: center;"><tbody>
<tr><td style="text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiPVkf139NR00l5CCPECZ1azrxANv_Lu4VG2uHEsT9YUggzrukHDeGbgmiXUJalRKIFO9DNaXXprgsj1GzEZ21_dg56nvOUkdc4-BOyEYh8myID5jsxlOgpdMc_4CmBbBsgPi_gQeQblu8/s1600/evolve_agile_team.png" imageanchor="1" style="margin-bottom: 1em; margin-left: auto; margin-right: auto;"><img border="0" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiPVkf139NR00l5CCPECZ1azrxANv_Lu4VG2uHEsT9YUggzrukHDeGbgmiXUJalRKIFO9DNaXXprgsj1GzEZ21_dg56nvOUkdc4-BOyEYh8myID5jsxlOgpdMc_4CmBbBsgPi_gQeQblu8/s1600/evolve_agile_team.png" /></a></td></tr>
<tr><td class="tr-caption" style="text-align: center;">credit: universal studios</td></tr>
</tbody></table>
<br />
Perhaps you’re one of the rare few who, by the end of your first Agile project, recognize already that the team should be together and should not be limited to just Scrum. Perhaps you’ve already begun incorporating aspects of Lean, Kanban, DevOps, Lean Startup, Lean Enterprise, eXtreme Programming, or any number of other Agile approaches to help your team stretch and grow. You have a vision for how amazing your team can be – a unicorn among horses – and you recognize that Agility is a journey, not a destination.<br />
<br />
The team can only become so awesome before running into major roadblocks within the organization. The team can become locally optimized, but the benefits will be limited until the entire system is optimized. After all, this is a Waterfall organization – you can run whatever methodology you like within your team, but there’s still an overall process that must be respected.<br />
<br />
You’ll soon find that, in order to best help the team, you have to spend less time with the team and more time fixing the environment they live in. Maybe it’s the dependent teams – adjacent teams doing similar work or component teams, such as Security, Infrastructure, or Release teams. Maybe the Operations team is pushing back, trying to drive constancy at the sake of functionality. Maybe it’s the way work is approved and projects are formed that prohibit the team from responding to customer requests and market demands as quickly as they are capable. Maybe there are leaders or others in the organization that are afraid of change and, consequently, are passively or actively sabotaging the spread of Agile.<br />
<br />
If you are successful, you will find that organizational Agility provides orders of magnitude greater than a single Agile team. You’ll find that what the team does rarely have as great an impact on their performance as the environment in which they operate.Anonymoushttp://www.blogger.com/profile/07829612743920787477noreply@blogger.com0tag:blogger.com,1999:blog-8737362623239996105.post-4955110201462753872015-05-05T12:40:00.000-06:002015-05-05T14:17:11.853-06:00The HiPPO vs. The Dude - The Eternal Prioritization BattleIf you didn't already know, I'm a huge fan of <a href="https://twitter.com/davidhussman" target="_blank">David Hussman's</a> <a href="https://pragprog.com/magazines/2012-01/the-dude-abides" target="_blank">"Dude's Law"</a>, which states that "Value = Why? / How?". I've used this concept both in coaching in general (as it was intended), as well as a fun and easy way to execute <a href="http://www.mlcarey321.com/2015/03/practical-application-of-dudes-law.html" target="_blank">Weighted Shortest Job First (WSJF) prioritization</a>.<br />
<br />
A universal obstacle to value-driven prioritization is the HiPPO - the Highest Paid Person's Opinion. I still encounter this in organizations that have been on their Agile journey for over a year. It's painful for me to hear them explain the difficulties they have with changing priorities while being held accountable for the successful delivery of original commitments. Yet, when I recommend they quantify their value somehow, they explain that it can't be done. Priorities are set by people that have much more subject matter expertise and are "above my pay-band". They have to obey the HiPPO.<br />
<br />
How does one respond to the HiPPO? With the immortal words of The Dude, of course!<br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<iframe allowfullscreen="" class="YOUTUBE-iframe-video" data-thumbnail-src="https://i.ytimg.com/vi/pWdd6_ZxX8c/0.jpg" frameborder="0" height="440" src="https://www.youtube.com/embed/pWdd6_ZxX8c?feature=player_embedded" width="550"></iframe></div>
<div style="text-align: center;">
<i>"Yeah, well, you know, that's just, like, uh, your opinion, man."</i></div>
<div style="text-align: center;">
<i><br /></i></div>
<div style="text-align: left;">
Opinions are important, but we want everyone's opinion and we want to put those opinions in context of all the available options! When a <a href="http://www.mlcarey321.com/2014/02/introspective-conversation-framework.html" target="_blank">conversation framework</a> is used to turn opinions into a quantitative estimate that can drive consistent and objective prioritization of work, it becomes easy to justify a change in plans. When teams track how much value they delivered relative to what was committed to (instead of static features or objectives) then the reluctance to take on valuable, unplanned work goes away; even more importantly, the team is armed with the data to push-back against unplanned work that really isn't as valuable as the HiPPO made it seem!<br />
<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/AVvXsEgVhgA6IXmnsD_V4dCDHwSKa5HxKxBy2_Iyu-DgEf2lG2j-Rx_h3AZjOivQ5rja66T9kVIzcV9HoZgfh4dSKAmXbCVi85Mj2UY6qcLCilHPSX8WhWmyMOiq27Q7qGLcsS_i5FKVHenLevM/s1600/HPPO+(full).png" imageanchor="1" style="margin-left: auto; margin-right: auto;"><img border="0" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgVhgA6IXmnsD_V4dCDHwSKa5HxKxBy2_Iyu-DgEf2lG2j-Rx_h3AZjOivQ5rja66T9kVIzcV9HoZgfh4dSKAmXbCVi85Mj2UY6qcLCilHPSX8WhWmyMOiq27Q7qGLcsS_i5FKVHenLevM/s1600/HPPO+(full).png" width="90%" /></a></td></tr>
<tr><td class="tr-caption" style="text-align: center;">The HiPPO vs. The Dude</td></tr>
</tbody></table>
<br /></div>
<div style="text-align: left;">
Dude's Law isn't the only way to prioritize work. There are other techniques you may decide to use, just know that if you stick with the HiPPO you run the risk of seriously damaging team morale and momentum. The HiPPO destroys, the Dude abides.</div>
Anonymoushttp://www.blogger.com/profile/07829612743920787477noreply@blogger.com0tag:blogger.com,1999:blog-8737362623239996105.post-77815819203426635932015-03-06T09:02:00.000-07:002015-03-06T09:02:07.491-07:00Practical Application of Dude's Law: The Value Estimation GameLast summer, <a href="https://twitter.com/ToddKromann" target="_blank">Todd Kromann</a> and I presented on <a href="http://schd.ws/hosted_files/agile2014/85/1691_Dude's_Law_Handout.pdf" target="_blank">Dude's Law</a> at <a href="http://agile2014.sched.org/event/13c6bb5895ac70e21231df62698b37da#.VPm54PnF-Ag" target="_blank">Agile2014</a>, and I figured it was high time that I wrote a blog post to walk through what we covered.<br />
<br />
<h3>
Dude's Law</h3>
If you're not already familiar with the Agile Dude, <a href="https://twitter.com/davidhussman" target="_blank">David Hussman</a>, we highly recommend becoming familiar. David is most well-known for his coining of <a href="https://pragprog.com/magazines/2012-01/the-dude-abides" target="_blank">Dude's Law</a>, which states that "Value = Why / How". The intent behind Dude's Law was to help teams avoid what David refers to as the "Recipe Trap" - doing things because that's what the "recipe" (read prescribed methodology or management mandate) says you're supposed do.<br />
<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/AVvXsEi9WAwELecDHKJ_PbgewQzwPppwcArLQ2D_qAcIWIjmGhGJ7nSDSPWk-nKAiWQcpgYd_74FC5_bc49xirWmhJueffkvZE5MTwLa2XySxE65Ver3DHW8C2yT-RvoAI9zuhWgxNLOlcROQm8/s1600/Dudes_Law_Full.png" imageanchor="1" style="margin-left: auto; margin-right: auto;"><img border="0" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEi9WAwELecDHKJ_PbgewQzwPppwcArLQ2D_qAcIWIjmGhGJ7nSDSPWk-nKAiWQcpgYd_74FC5_bc49xirWmhJueffkvZE5MTwLa2XySxE65Ver3DHW8C2yT-RvoAI9zuhWgxNLOlcROQm8/s1600/Dudes_Law_Full.png" width="80%" /></a></td></tr>
<tr><td class="tr-caption" style="text-align: center;">Dude's Law: Value = Why / How</td></tr>
</tbody></table>
<br />
Using Dude's Law as a coach is extremely powerful.It's a simple way for people to question everything they do. It emphasizes the need to know why we do the things we do. It resonates with people at an almost instinctual level.<br />
<br />
<h3>
WSJF</h3>
<div>
The more Todd and I used Dude's Law in our coaching, the more applications we found for it. Eventually, we noticed the similarities between Dude's Law and <a href="https://twitter.com/dreinertsen" target="_blank">Don Reinertsen</a>'s concept of "Weighted Shortest Job First", or WSJF.</div>
<div>
<br /></div>
<div>
WSJF is a powerful prioritization tool. There are basically three underlying principles to WSJF. First, if all the work you have to do is the same size, you do the job with the highest cost of delay first. In other words, we want to do the work that is the most urgent or will cost us the most to <u style="font-style: italic; font-weight: bold;">not</u> do. After all, if all the work items are going to cost us the same amount then we want to get the most out of the time spent.</div>
<div>
<br /></div>
<div>
Second, if all the work you have to do has the same cost of delay, do the shortest job first. In other words, if all work is equally expensive to <u style="font-style: italic; font-weight: bold;">not</u> do then we want to start getting benefit as quickly as possible.</div>
<div>
<br /></div>
<div>
Third, if both the size and cost of delay are variable, do the <u>weighted</u> shortest job first. You do this by dividing the cost of delay by the size; the higher the result, the sooner the work in question should be executed. Since our highest cost is typically the manpower necessary to do the work, size is defined by duration. Duration is also useful as the denominator because it emphasizes the need to get things delivered quickly, so we have a bias towards smaller slices of value.</div>
<div>
<br /></div>
<table align="center" cellpadding="0" cellspacing="0" class="tr-caption-container" style="float: center; margin-right: 1em; text-align: center;"><tbody>
<tr><td style="text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhgqflSRSDXEXJHMmJ0f5TkW_YteNZW3ArDBN7k2sUovwAKY48OMwAA2kFps8_So3NCvRk2jKIRFSq7ZtIzFkDYCGg4BX46YAKMFhPk-rRFRa-tR5iFEyDtVuYE8yMZCCPewtguXdNQFM8/s1600/WSJF_Full.png" imageanchor="1" style="margin-left: auto; margin-right: auto;"><img border="0" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhgqflSRSDXEXJHMmJ0f5TkW_YteNZW3ArDBN7k2sUovwAKY48OMwAA2kFps8_So3NCvRk2jKIRFSq7ZtIzFkDYCGg4BX46YAKMFhPk-rRFRa-tR5iFEyDtVuYE8yMZCCPewtguXdNQFM8/s1600/WSJF_Full.png" width="100%" /></a></td></tr>
<tr><td class="tr-caption" style="text-align: center;">WSJF = Cost of Delay / Duration</td></tr>
</tbody></table>
<div>
<h3>
</h3>
<h3>
Where's the work?</h3>
<div>
Before we go any further, we need work items. If you're applying this within a team, simply use the work that's already on your backlog (or slated to go on your backlog). Application of WSJF (or Dude's Law) tends to work best at the Epic or Feature level, but can be applied to User Stories as well.</div>
<div>
<br /></div>
<div>
If you don't have real-world work, you can do what we do - have the team(s) come up with their own work. We usually run this with multiple "table teams" - teams formed around tables in the room. We like to get one set of Features for the whole room so we can see the differences in prioritization by each group (it makes for some interesting conversation at the end of the workshop). To do this, we tell the room that we have a great idea for a game, but all we have is a title. Based on our market research, we know this title is a winner. We want to build "Angry Flappy Candy Bird Crush Saga". We then solicit five Features from the room that we think are essential to become profitable as quickly as possible. Voila! We now have the beginnings of a backlog.</div>
<div>
<br /></div>
<h3>
Estimation Game</h3>
</div>
<div>
The key to applying WSJF (or Dude's Law) in the context of prioritization is the quantification of those values. We need numbers so we can do an actual numeric division to get a numeric value for WSJF (or Value). How do we do this? We highly recommend relative estimation! The most common way to use relative estimation is to use Fibonacci numbers to size items relative to each other. If you've never done this before, this can be daunting - especially for your first work item, when you do not yet have anything to compare the item's size against.</div>
<div>
<br /></div>
<div>
The technique that we use in this workshop is called the "<a href="http://www.agilelearninglabs.com/2012/05/how-to-play-the-team-estimation-game/" target="_blank">Team Estimation Game</a>". This technique works well to quickly get an initial backlog estimated. Since most people are used to estimating size anyway, we have teams estimate the size (what we refer to as "Cost of Implementation") first using the Team Estimation game. Once they're done, we have them write the number on the bottom of each story card, in the center.</div>
<div>
<br /></div>
<table align="center" cellpadding="0" cellspacing="0" class="tr-caption-container" style="float: center; margin-right: 1em; text-align: center;"><tbody>
<tr><td style="text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEicNfdAbiYOs6Ly6UQRxJQ3syzFl3h_ZP3d7a004X3d9vmCz35v7NE4r9RCBE2OwAR8mG6qnwb-FWhUKt7zXbnuRzXWH2FOgH5-f8FVM7JFiD8Br3FBrQ27xm9xucF0cGfIIUy4sXY-rYc/s1600/Team_Estimation_Game_Full.png" imageanchor="1" style="margin-left: auto; margin-right: auto;"><img border="0" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEicNfdAbiYOs6Ly6UQRxJQ3syzFl3h_ZP3d7a004X3d9vmCz35v7NE4r9RCBE2OwAR8mG6qnwb-FWhUKt7zXbnuRzXWH2FOgH5-f8FVM7JFiD8Br3FBrQ27xm9xucF0cGfIIUy4sXY-rYc/s1600/Team_Estimation_Game_Full.png" width="100%" /></a></td></tr>
<tr><td class="tr-caption" style="text-align: center;">The Team Estimation Game summarized</td></tr>
</tbody></table>
<div>
<br />
<h3>
Cost of Delay</h3>
</div>
<div>
Now that we've estimated the cost of implementation, we need to estimate the cost of delay. We do this with the <i style="font-weight: bold;">exact same approach</i> we used for cost of implementation. When trying to figure out cost of delay, think of it in terms of, "How expensive is this to <u style="font-style: italic; font-weight: bold;">not</u> do?"</div>
<div>
<br /></div>
<div>
When considering cost of delay, there are several factors we need to consider: inherent value to the business; urgency due to any number of reasons (legal deadlines, market demands, partner collaboration, etc.); the value of other work that's dependent on this work item being done first; risks that this item may reduce; and so on.</div>
<div>
<br /></div>
<div>
When we're talking about benefit, we usually use the priority scale where 1 is most important, then 2, then 3, etc. That is <u style="font-weight: bold;">not</u> what we're doing here. In this case, a 1 is something with a very low cost of delay - it's not very urgent, valuable, etc. The higher the number, the more expensive it is to <u style="font-style: italic; font-weight: bold;">not</u> do.</div>
<div>
<br /></div>
<div>
Once each card has a number value, write it in the bottom left corner of the card.</div>
<div>
<br /></div>
<h3>
Run the Math</h3>
<div>
Now that we have the two variables on the right side of the equation, we need to "run the math" to see what our WSJF (or Dude's Law) number - what we call the Value Index - comes out to be. For each card, divide the Cost of Delay (bottom-left number) by the Cost of Implementation (bottom-center number) and put the result, the Value Index, in the bottom-right corner. Order the cards from highest Value Index to lowest Value Index. This is now the priority that the math recommends you complete the work in.</div>
<div>
<br /></div>
<div>
As long as your estimation was honest, doing the work in this order will give you the greatest return on your investment over time. We can maximize how much we capitalize on our work as soon as possible. The below graphs help illustrate this.</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/AVvXsEiob8SHDoBw9c5wCwhUXlX6VSx5TUUw_tGR6X5BiPJYJ8A71eXP8Dg6D35YBqaYXyffBrKG1B1CP8k06FcKFt1YMS9w6zRI_OiGCp6oVAFLRo8CB64AYvfvQCTEUlQdqR20I_sm9aLB_gI/s1600/Graphs_Full.png" imageanchor="1" style="margin-left: auto; margin-right: auto;"><img border="0" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiob8SHDoBw9c5wCwhUXlX6VSx5TUUw_tGR6X5BiPJYJ8A71eXP8Dg6D35YBqaYXyffBrKG1B1CP8k06FcKFt1YMS9w6zRI_OiGCp6oVAFLRo8CB64AYvfvQCTEUlQdqR20I_sm9aLB_gI/s1600/Graphs_Full.png" width="100%" /></a></td></tr>
<tr><td class="tr-caption" style="text-align: center;">Add value sooner with WSJF/Dude's Law</td></tr>
</tbody></table>
<div>
<br />
<h3>
Remember Dude's Law</h3>
</div>
<div>
What we often find is that the first time people use this approach their prioritization is a little wonky. That's okay - the purpose of this exercise isn't to mandate what order you do things in. This approach is a <a href="http://www.mlcarey321.com/2014/02/introspective-conversation-framework.html" target="_blank">conversation framework</a> to help teams make sure they're working on things in the right order, factoring cost of implementation into the prioritization process instead of looking only at short-term benefit. Teams also find that this tool becomes more beneficial as they gain experience with it - they learn what they need to discuss in order to come to proper estimates that lead to better prioritization.</div>
<div>
<br /></div>
<div>
Remember the original intent behind Dude's Law: to avoid the Recipe Trap. This approach is not intended to be a recipe for the team to follow blindly. This is a tool, one that the team should understand the benefits of before they decide to adopt it. Understand the <a href="http://www.mlcarey321.com/2013/08/understanding-why.html" target="_blank">Why</a> before jumping into the <a href="http://www.mlcarey321.com/2015/02/tell-me-why-not-how.html" target="_blank">How</a>.</div>
<div>
<br /></div>
<div>
You may also decide to elaborate on the formula. You may take the <a href="http://www.scaledagileframework.com/wsjf" target="_blank">SAFe approach</a> and discuss different factors to Cost of Delay instead of having a single number. You may decide to incorporate IBM's approach of <a href="ftp://public.dhe.ibm.com/la/documents/imc/la/pe/news/events/mit_2010/the_value_of_transparency_in_it_management.pdf" target="_blank">Value Dials and ITBV</a>. You may end up with a multi-sheet Excel workbook with dozens of numeric inputs that feed into a complicated formula. In the end, it all boils down to Why/How. Be careful how much extra time you put into prioritization and make sure the improvements to your prioritization justify that extra time.</div>
Anonymoushttp://www.blogger.com/profile/07829612743920787477noreply@blogger.com0tag:blogger.com,1999:blog-8737362623239996105.post-85973303667918842272015-02-27T14:01:00.001-07:002015-02-27T14:01:13.922-07:00Revisiting Normalized Story PointsIt has been just over 18 months since I published my most popular blog post to-date: <a href="http://www.mlcarey321.com/2013/08/normalized-story-points.html" target="_blank">"Normalized Story Points"</a>. As of this writing, it has received over 5,400 page views, thanks primarily to the reference it has from <a href="http://www.scaledagileframework.com/author/deanleffingwell/" target="_blank">Dean Leffingwell</a>'s blog post from <a href="http://scaledagileframework.com/">ScaledAgileFramework.com</a> entitled <a href="http://www.scaledagileframework.com/more-on-normalizing-story-point-estimating/" target="_blank">"More on Normalizing Story Point Estimating"</a>.<br />
<br />
As an Agile Coach who takes continuous improvement seriously, I have learned much and grown much over the last year and a half. Here are a few of the things I've learned regarding Normalized Story Points.<br />
<br />
<h3>
Know Why You Want Them</h3>
<div>
I've become a HUGE fan of <a href="https://twitter.com/davidhussman" target="_blank">David Hussman</a>'s <a href="https://pragprog.com/magazines/2012-01/the-dude-abides" target="_blank">"Dude's Law"</a>. Before you do anything, you need to know WHY you're doing it, not just HOW to do it.</div>
<div>
<br /></div>
<div>
The purpose of Normalized Story Pointing is to enable high-level estimation of work for a <a href="http://www.scaledagileframework.com/agile-release-train/" target="_blank">SAFe Release Train</a> comprised of closely aligned teams, any one of which may pull a <a href="http://scaledagileframework.com/feature" target="_blank">Feature</a> off the <a href="http://www.scaledagileframework.com/program-backlog/" target="_blank">Program Backlog</a> for implementation. Normalized Story Points should not be used for:</div>
<div>
<ol>
<li>Comparing teams against each other</li>
<li>Forcing teams to use the same story point size (so that "1 Story Point" means exactly the same thing to everyone forever and ever amen)</li>
<li>Defining "Story Point" to mean "Ideal Man-Day"</li>
<li>Any punitive purpose</li>
</ol>
<div>
If you don't know why you're using Normalized Story Points, don't use them. If your intended use of Normalized Story Points violates the mindset established by the <a href="http://agilemanifesto.org/" target="_blank">Agile Manifesto</a>, don't use them (although, if this is the case then you probably won't realize it unless someone points it out to you).</div>
</div>
<div>
<br /></div>
<h3>
Beware the Ideal Man-Day</h3>
<div>
The 4-step process for getting started with Normalized Story Points involves using time as a reference. This works well because you're using a very small story, one with very little complexity, which means the primary factor for determining "bigness" is lapsed time. That being said, I've found that teams that start with this approach have a very, very difficult time recovering from the mindset of "1 point == 1 ideal man-day". This is bad for <a href="http://blog.crisp.se/2008/12/05/tomasbjorkholm/1228470417545" target="_blank">reasons</a>.</div>
<div>
<br /></div>
<div>
This also leads to teams always using days of availability to forecast velocity rather than taking a rolling average velocity or "yesterday's weather" as an indicator of what they're likely to deliver. Data trumps theory; the approach to get started is based on theory, while average velocity is data.</div>
<div>
<br /></div>
<h3>
Individuals and Interactions over Processes and Tools</h3>
<div>
Processes and tools exist to enhance and enable interactions between individuals, not replace them. As I've explained in a <a href="http://www.mlcarey321.com/2014/02/introspective-conversation-framework.html" target="_blank">previous post</a>, the process of Agile estimation is beneficial primarily because of the conversation that it fosters. It's a well-formed game that drives a shared mental model of the work for the entire team.</div>
<div>
<br /></div>
<div>
I've found that teams that use Normalized Story Points may skimp on the conversation, especially if one team ends up with work that another team has already estimated (after all, we all share the same definition of story point, right?). This was never the intent behind Normalized Story Points, but that doesn't mean it doesn't happen.</div>
<div>
<br /></div>
<h3>
Beware the Recipe Trap</h3>
<div>
David Hussman explained that he uses "Dude's Law" to help teams avoid what he calls the "Recipe Trap" - doing something because that's what the recipe says to do, without understanding what the intended benefits are. When it comes to Normalized Story Points, the recipe trap is very real and very dangerous. If you use it, be very careful about how you explain and implement it with your teams. If your teams can't all pull from a common backlog; if you're going to use them to run punitive metrics; if you want to streamline your process by reducing meaningful conversation; or if you're looking to use it because that's what SAFe says to do, I plead with you to reconsider.</div>
<div>
<br /></div>
<div>
<b>TL;DR</b>: Normalized Story Points can be a useful tool for your organization, but it's not a one-size-fits-all solution. </div>
Anonymoushttp://www.blogger.com/profile/07829612743920787477noreply@blogger.com0tag:blogger.com,1999:blog-8737362623239996105.post-2728191141217714512015-02-17T09:20:00.001-07:002015-02-17T09:20:28.880-07:00Tell Me Why, not How<span style="font-size: large;">If you're familiar with the concept of User Stories then you've likely been exposed to the concept of a User Story "script". One of the most common scripts goes something like:</span><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/AVvXsEjKHD_RAzSmqdyVGp_uIiu7hPjWDeJex2iuBNyJI77WtSZkkufOdSfIWzhv4O79fCEHLsmrgvfrbhqvjGH97k2oPHqaJRHWME9hh7MK65HvKxYYXbYUWtZMsp5lUsV7OL13cdOSfbrTBU0/s1600/good_story.png" imageanchor="1" style="margin-left: auto; margin-right: auto;"><img alt="As a <who> I want <what> So that <why>" border="0" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjKHD_RAzSmqdyVGp_uIiu7hPjWDeJex2iuBNyJI77WtSZkkufOdSfIWzhv4O79fCEHLsmrgvfrbhqvjGH97k2oPHqaJRHWME9hh7MK65HvKxYYXbYUWtZMsp5lUsV7OL13cdOSfbrTBU0/s1600/good_story.png" title="As a <who> I want <what> So that <why>" width="80%" /></a></td></tr>
<tr><td class="tr-caption" style="text-align: center;"><span style="font-size: small;">As a <who> I want <what> So that <why></span></td></tr>
</tbody></table>
<span style="font-size: large;"><br /></span>
<span style="font-size: large;">Looks simple enough, right? The problem is that most people who grew up in a non-Agile environment are not used to articulating the "why" in their requirements. They are used to capturing what it is that needs to built and how. Consequently, that's what usually end up making it into our stories, causing them to look like:</span><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/AVvXsEgHGAtEtRgPbEh_3-gC1aRFCPCTMK1kYC79XgBwsLRYnoJTPvzZpflBJkRQsp_OLdAi8D0fT8muAm_KKoz_-kSakNfUpIGZWkcgRKoyu3yG-OR_0vQwgMrIaWnoh9yqrpFIxR0Y_7WG0x0/s1600/bad_story.png" imageanchor="1" style="margin-left: auto; margin-right: auto;"><img alt="As a <who> I want <how> So that <what>" border="0" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgHGAtEtRgPbEh_3-gC1aRFCPCTMK1kYC79XgBwsLRYnoJTPvzZpflBJkRQsp_OLdAi8D0fT8muAm_KKoz_-kSakNfUpIGZWkcgRKoyu3yG-OR_0vQwgMrIaWnoh9yqrpFIxR0Y_7WG0x0/s1600/bad_story.png" title="As a <who> I want <how> So that <what>" width="80%" /></a></td></tr>
<tr><td class="tr-caption" style="text-align: center;"><span style="font-size: small;">As a <who> I want <how> So that <what></span></td></tr>
</tbody></table>
<span style="font-size: large;"><br /></span>
<span style="font-size: large;">What's the difference? Let's look at an example.</span><br />
<span style="font-size: large;"><br /></span>
<br />
<h3>
<span style="font-size: large;">Old Habits Die Hard</span></h3>
<span style="font-size: large;">It's not uncommon to see a story that reads like, "As an administrator I want unique group IDs for tickets so that I can easily group tickets." On the surface it looks like a good user story. What's the "what"? The author would argue that it's "unique group IDs for tickets", but that's not the need. The need is to "easily group tickets". The author is trying to dictate how to meet that need in the user story. Those familiar with the <a href="http://en.wikipedia.org/wiki/INVEST_%28mnemonic%29" target="_blank">INVEST</a> model for user stories will recognize that this violates the "N" - Negotiable.</span><br />
<span style="font-size: large;"><br /></span>
<span style="font-size: large;">So we need to move the "what" into its place and establish a proper "why", which means we need to have a conversation. What valuable outcome is enabled by being able to group tickets together? Do you want static or dynamic grouping? Are the groups established by pre-established rules, or is the intent for users to group tickets however they like? Once we have our answers, we may end up with a better user story, something like, "As an administrator I want to easily group tickets so that I can sort and filter to easily find tickets of interest for a given task".</span><br />
<span style="font-size: large;"><br /></span>
<br />
<h3>
<span style="font-size: large;">Why? Why?! WHY?!?</span></h3>
<span style="font-size: large;">What have we gained by phrasing the story this way? A couple of things (at least). First, we have context for the story that will enable the team of professional problem-solvers to create the best solution for the problem within the bounds of the NFRs (<a href="http://www.mountaingoatsoftware.com/blog/non-functional-requirements-as-user-stories" target="_blank">Non-Functional Requirements</a>) and FSRA (Future State Reference <a href="https://www.scrumalliance.org/community/articles/2013/august/agile-architecture-emerges-or-does-it" target="_blank">Architecture</a>).</span><br />
<span style="font-size: large;"><br /></span>
<span style="font-size: large;">The second benefit is that we can better decompose the story. With the original wording, we would likely decompose the work into the layers of the system - creating a grouping cross-reference table structure first, then the business logic and virtual object code to associate tickets to groups, and finally the user interface layer for the administrator to actually use this functionality.</span><br />
<span style="font-size: large;"><br /></span>
<span style="font-size: large;">With the revised wording, we can leverage the advice from Agile Learning Labs at <a href="http://smallerstories.com/">SmallerStories.com</a> and split our story into smaller stories that are vertical slices through the entire system. This enables us to deliver value sooner and test our architecture as it's being built instead of all at the end.</span><br />
<span style="font-size: large;"><br /></span>
<br />
<h3>
<span style="font-size: large;">Living in Reality</span></h3>
<span style="font-size: large;">This is the most common anti-pattern that I've seen in the real world of user stories. What anti-patterns have you seen? What advice do you have for overcoming user story anti-patterns? Is this even really an anti-pattern?</span>Anonymoushttp://www.blogger.com/profile/07829612743920787477noreply@blogger.com0tag:blogger.com,1999:blog-8737362623239996105.post-79835709113011020512014-12-12T09:59:00.002-07:002014-12-12T09:59:41.667-07:00The Socratic Coaching Approach<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/AVvXsEjEd0cEGMycCVJGjFmhM7ahk82eC37koBt-Is1Old-E36QmCyfA8iqf1aIjVff0zVTnJyNVEbsLU9DhCbkwL6hQsiczwZ5y9LWRMMdjK9QM1DylHiWatZKKqDJ0TKi0vfvcSJoa6wg6vu8/s1600/socrates_quote.png" imageanchor="1" style="margin-left: auto; margin-right: auto;"><img border="0" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjEd0cEGMycCVJGjFmhM7ahk82eC37koBt-Is1Old-E36QmCyfA8iqf1aIjVff0zVTnJyNVEbsLU9DhCbkwL6hQsiczwZ5y9LWRMMdjK9QM1DylHiWatZKKqDJ0TKi0vfvcSJoa6wg6vu8/s1600/socrates_quote.png" width="80%" /></a></td></tr>
<tr><td class="tr-caption" style="text-align: center;">"The secret of change is to focus all of your energy, not on fighting the old, but on building the new." -- Socrates</td></tr>
</tbody></table>
<br />
I recently read "<a href="http://www.walmart.com/ip/33215828" target="_blank">The Goal: A Process of Ongoing Improvement</a>" by <a href="http://en.wikipedia.org/wiki/The_Goal_%28novel%29" target="_blank">Eliyahu M. Goldratt</a>. For those of you unfamiliar with this masterful work, it is the book that introduced the Theory of Constraints and was a primary predecessor of "<a href="http://www.walmart.com/ip/38541102" target="_blank">The Phoenix Project</a>" - in fact, "The Phoenix Project" not only makes mention of "The Goal", it is written in a similar style and format!<br />
<br />
I learned a lot from "The Goal", but I was able to apply a couple of learnings immediately to my coaching: 1) The Goal itself; 2) the Socratic method. Granted, I'm very new to this and still have a lot to learn about the Socratic method, but that's not stopping me from giving it a try!<br />
<br />
This is the basic conversation I've been having for the past couple of weeks, usually in response to "How do I convince so-and-so to be more Agile?"<br />
<br />
<b>Me:</b> What is the goal of any company?<br />
<b>Them </b><i>(usually after some thinking and a few guesses)</i><b>:</b> Make money?<br />
<b>Me:</b> That's right! Now, as a development center, how do we help the company make money?<br />
<b>Them: </b>We provide solutions/capabilities/cost savings/etc.<br />
<b>Me: </b>Okay, and when do we provide them? When we finish requirements?<br />
<b>Them: </b>No...<br />
<b>Me: </b>When we finish Coding? Testing?<br />
<b>Them: </b>No.<br />
<b>Me: </b>Then when?<br />
<b>Them: </b>When we deploy.<br />
<b>Me: </b>Okay, so we deliver value when we deploy. How often do we deploy?<br />
<b>Them: </b>Not often enough.<br />
<b>Me: </b>I agree! So as soon as we deploy something and start working on something new, we are basically just accruing expense until the day we release again. Yet, in Agile, we often find ourselves sitting on "Production-ready" code without releasing it. What are some other consequences to releasing code in large, infrequent batches?<br />
<b>Them: </b>It's more difficult for our customers to handle the change. They require weeks of User-Acceptance Testing and have to build Change Management plans around each release.<br />
<b>Me: </b>Precisely! Also, what happens if we find a defect?<br />
<b>Them: </b>Defects can be very expensive because we find them late, which means they are large and highly impactful. Plus the defect may be something that we developed a long time ago and have forgotten about.<br />
<b>Me: </b>Right. So... what I'm hearing is that when we deploy less frequently then we delay delivery of value and increase risk, both of which are contradictory to our goal to make money, is that right?<br />
<b>Them: </b>Yes, exactly!<br />
<b>Me: </b>So why don't we just define Agile as a mindset of striving to deliver more valuable functionality with high quality at faster rates? Then "Being Agile" means doing whatever makes sense to reach that goal. Do you think they could get on board with that?<br />
<b>Them: </b>Absolutely - they'd have to be foolish not to!<br />
<br />
Notice that I didn't say Agile until the very end. The idea is to help them realize for themselves the obvious truths that Agile espouses in a way that solves their problems or aligns with their current paradigm. This results in a more natural mindset shift, as opposed to one that feels forced or alien in a classroom environment. I've seen a lot of success with this approach so far, and I'm hoping to get even better with experience.<br /><br />How about you? Have you used the Socratic approach in your coaching? What ideas, successes, or failures would you share with someone just getting started with this approach?Anonymoushttp://www.blogger.com/profile/07829612743920787477noreply@blogger.com0tag:blogger.com,1999:blog-8737362623239996105.post-59097057341006358762014-10-07T09:44:00.000-06:002014-10-07T09:44:45.519-06:00Agile vs. non-Agile Value DeliveryOne of the key differences between Agile and non-Agile approaches is how scope is managed. Agile techniques use some form of continuous backlog management, while non-Agile approaches set the scope up-front and changes to that scope are painful. As a result, I'm often asked how this impacts budgeting. I respond that I prefer a budgeting approach that aligns with <a href="http://www.bbrt.org/beyond-budgeting/bbwhat.html" target="_blank">"Beyond Budgeting"</a> thinking, but I recognize that such a shift likely won't occur at the same time the team wants to start using Agile. I advise them to secure budget the same way they have been (due primarily to lack of choice), but use the money in a more Agile way. Here are three scenarios that illustrate why.<br />
<br />
<h4>
The Perfect Planning Scenario</h4>
<div>
First, let's look at what happens if both Agile and non-Agile approaches were to deliver exactly the same value implemented exactly the same way and we knew up-front exactly how much it would cost. If we took an iterative delivery approach then we would see an "S-curve" in the delivery of value (in blue), as explained in the video <a href="https://www.youtube.com/watch?v=502ILHjX9EE" target="_blank">"Agile Product Ownership in a Nutshell"</a> by <a href="https://www.youtube.com/channel/UCW0cG4zyFG8oKAlOom4KonQ" target="_blank">Henrik Kniberg</a> (starting at the 8:27mark). This allows us to capitalize on what we're building faster, so we start making or saving money faster. Compare this with the non-Agile approach (in red), where we don't see any value until the end. The area between the blue line and the red line is additional realized value over time, even though we ended up in the exact same place at the exact same time.<br />
<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/AVvXsEgk0MmfZktFihIMvFsoXlD-iEVCh7uaaVpJKRoV_0zfQYjlbkH4ATgqray0_ez65UQqcatj2MnUbe3GDalnGdZLGeC4faLHUmM7sjN6ZcxNzAeF-gBKtPoyxpwYyjMav1SZN7m0UjTw51E/s1600/value_graph_100.png" imageanchor="1" style="margin-left: auto; margin-right: auto;"><img border="0" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgk0MmfZktFihIMvFsoXlD-iEVCh7uaaVpJKRoV_0zfQYjlbkH4ATgqray0_ez65UQqcatj2MnUbe3GDalnGdZLGeC4faLHUmM7sjN6ZcxNzAeF-gBKtPoyxpwYyjMav1SZN7m0UjTw51E/s1600/value_graph_100.png" width="80%" /></a></td></tr>
<tr><td class="tr-caption" style="text-align: center;">Blue = Agile; Red = non-Agile</td></tr>
</tbody></table>
<br />
<div class="separator" style="clear: both; text-align: center;">
</div>
<h4>
The Bad Estimate / Budget Cut Scenario</h4>
<div>
Now let's imagine (if you can) a scenario where we don't have sufficient time to deliver all of the value. Maybe it's because our estimates are off. Maybe because it's because our budget is cut. Whatever the case, we end up with 60% of the time and money necessary to deliver all of the planned value. If we take an Agile approach, we end up with the top 60% of the functionality, 100% completed. If we take a non-Agile approach, we end up with 100% of the functionality 60% completed. This means that we're either delivering nothing but documentation and partially-coded functionality, or we end up begging for the money required to finish delivering what we started out to deliver.</div>
<div>
<br /></div>
<div class="separator" style="clear: both; text-align: center;">
</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/AVvXsEh55w2mZz_0jLvisOM-qmS_26bE-iwuJlIRxOpnEQIK6zpWWoVxz11EwVMS70BXXYwFwVCiv2QGNXgHGhh_gNmYBTyhSIiP5P82Z8jIqApqoYrZV9Tk5LvjWGhgfk5-lbuheggan4_7Xfs/s1600/value_graph_60.png" imageanchor="1" style="margin-left: auto; margin-right: auto;"><img border="0" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEh55w2mZz_0jLvisOM-qmS_26bE-iwuJlIRxOpnEQIK6zpWWoVxz11EwVMS70BXXYwFwVCiv2QGNXgHGhh_gNmYBTyhSIiP5P82Z8jIqApqoYrZV9Tk5LvjWGhgfk5-lbuheggan4_7Xfs/s1600/value_graph_60.png" width="80%" /></a></td></tr>
<tr><td class="tr-caption" style="text-align: center;">Blue=Agile; Red=non-Agile</td></tr>
</tbody></table>
<br />
<h4>
The Imperfect Human Scenario</h4>
</div>
<div>
This scenario was difficult to name - I'm open to alternatives. Basically, this is the scenario where the humans responsible for doing all of the non-Agile prep work of requirements elicitation, design, and coding end up delivering something that not only took longer than anticipated but didn't provide the desired value. By taking an Agile approach, we do "Just Enough, Just in Time" everything, so we're always as smart as possible when we make decisions. We work in short iterations and get fast feedback so that our defects are cheaper and our direction is constantly being corrected. As a result, we end up delivering more value sooner.</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/AVvXsEi6EO50xI8w_fmDzfGV4qVYsN9gmww3ihPgzY7fTMv9EUiW0GnfXfNKOl8Y_IhuhVH89Ujq0WQsGeIS8eyJZ7zk5VcTApwk4DYeEjt-LPEqHbGqtrga1Z2qLMNeYF8ZzLuDatweuaJyJpk/s1600/value_graph_real_100.png" imageanchor="1" style="margin-left: auto; margin-right: auto;"><img border="0" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEi6EO50xI8w_fmDzfGV4qVYsN9gmww3ihPgzY7fTMv9EUiW0GnfXfNKOl8Y_IhuhVH89Ujq0WQsGeIS8eyJZ7zk5VcTApwk4DYeEjt-LPEqHbGqtrga1Z2qLMNeYF8ZzLuDatweuaJyJpk/s1600/value_graph_real_100.png" width="80%" /></a></td></tr>
<tr><td class="tr-caption" style="text-align: center;">Blue=Agile; Red=non-Agile</td></tr>
</tbody></table>
<div>
<br />
<h4>
Making a Point</h4>
</div>
<div>
As per usual, my drawings are overly-simplified to make a point. Agile is not a silver bullet, but taking an Agile approach means you're more likely to deliver more value sooner and end up with a better end-product. Hopefully this approach propagates throughout the entire organization and the way you manage work-intake, scope approval, and value execution become leaner and more continuous from end-to-end. In the meantime, do what you can within the reality of the world you live in to make the most of the resources you have. I'd love to hear your perspectives and additional scenarios that illustrate the differences in Value over Time between Agile and non-Agile approaches.</div>
Anonymoushttp://www.blogger.com/profile/07829612743920787477noreply@blogger.com0tag:blogger.com,1999:blog-8737362623239996105.post-517022714698364912014-09-08T13:35:00.001-06:002014-09-08T13:35:56.040-06:00"I Like that Old Time Rock 'n Roll"I'm am constantly amazed with the power of first impressions. As much as we may try to avoid it, the initial impressions we get when we're first introduced to a person, place, or idea tend to stick with us for the rest of our lives. This sentiment is embodied in the classic Bob Segal hit, "Old Time Rock and Roll". The song starts with its thesis:<br />
<br />
<i>"Just take those old records off the shelf, I'll sit and listen to 'em by myself. Today's music ain't got the same soul; I like that old time Rock 'n Roll"</i><br />
<div class="separator" style="clear: both; text-align: center;">
<br /></div>
<div style="text-align: center;">
<div class="separator" style="clear: both; text-align: center;">
<iframe allowfullscreen='allowfullscreen' webkitallowfullscreen='webkitallowfullscreen' mozallowfullscreen='mozallowfullscreen' src='https://www.youtube.com/embed/SsSVcRYh8dE?feature=player_embedded' frameborder='0'></iframe></div>
<br /></div>
This same phenomenon happens in Agile as well. When people think of Agile Transformations being hindered by first impressions, they usually jump to those who "didn't do it right", who failed and were left with a bitter taste in their mouth. I would argue that, in the long-term, the more hazardous first impression comes from those who have greater-than-anticipated success with the first thing they try. From that point on Agile is defined solely by what they did the first time.<br />
<br />
Let's say your first approach was Scrum - and I mean by-the-Scrum-Guide Scrum. It works so well for you that you scoff at Kanban, DevOps, or anything else that violates your 5 ceremony, 3 role, pure and holy Agile approach. Nevermind that you are supposed to be looking for ways to improve every Sprint. Nevermind that the best way to improve team performance is adjustments to the process, not the people. "I'm sorry, you don't use time boxes?" "How do you plan without using User Stories?" "Clearly you don't know what Agile means."<br />
<br />
I find it telling that the first line in the Agile Manifesto states that "we are <b><i>uncovering</i></b> better ways of developing software by <b><i>doing it</i></b> and <b><i>helping others</i></b> do it" (<a href="http://agilemanifesto.org/">AgileManifesto.org</a>, emphasis added). They didn't say that they had uncovered the best way of developing software, they were in the never-ending process of uncovering better ways. They didn't come up with the Manifesto by getting doctorate degrees and jumping into a think tank, they came up with it based on their experiences in doing it and helping others.<br />
<br />
I find it highly narcissistic for anyone to have claimed the best way to do anything. Given how long mankind has been on the earth and the fact that nothing has yet been proven beyond improvement, saying that you've "figured it out" means you're either selling something, deluding yourself, or both. Those who really get Agile know that it's about the journey, not the destination. If you keep reliving the glory days of your first Scrum team then you'll never give proper attention to challenging the status quo and innovating the next big idea for delivering software in a better way.<br />
<br />
I know, I know, it's hard to give up those first impressions, the glory days, the golden years when everything was perfect and your selective memory hadn't kicked in yet. But you have to if you want long-term success. It's risky business, but somebody's got to do it.Anonymoushttp://www.blogger.com/profile/07829612743920787477noreply@blogger.com0tag:blogger.com,1999:blog-8737362623239996105.post-80119413026684457992014-09-03T12:33:00.000-06:002014-09-03T12:33:07.146-06:00Is Agile Skub?On a long wall at work, there's a glass board (probably 40 feet or so wide) on which our CIO will ask questions and anyone passing by can answer using dry erase markers. The question most recently posed is something to the effect of "What are you doing to be more Agile?".<br />
<br />
I found it interesting that somebody wrote "Pro Skub" on one end of the board and "Anti Skub" at the other end. What is Skub, you ask? It's a reference to a Perry Bible Fellowship comic, penned by Nicholas Gurewitch.<br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="http://pbfcomics.com/20/" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" src="http://pbfcomics.com/archive_b/PBF020-Skub.gif" width="90%" /></a></div>
<br />
This raises an interesting question for me: is Agile nothing more than a meaningless buzzword that arouses passion on the fringes that comes across as absurd to everyone else? To at least one person in my organization, it would seem the answer is "Yes!"<br />
<br />
To me, this is an indicator of the "Trough of Disillusionment" on they Hype Curve. It reminded me of an article titled <a href="http://effectivesoftwaredesign.com/2014/03/17/the-end-of-agile-death-by-over-simplification/" target="_blank">"The End of Agile: Death by Over-Simplification"</a>. To me, the points made by this article and others that it references indicate an over-emphasis on practices or principles in silos. In other words, teams will focus on one specific principle, practice, or approach under the banner of Agile and claim that it will solve all of their problems. Of course it doesn't, and when it doesn't it leads to disillusionment and cynicism.<br />
<br />
It is so crucially important that we take a step back and look at the whole <a href="http://agilemanifesto.org/" target="_blank">Agile Manifesto</a>, with all of its <a href="http://agilemanifesto.org/principles.html" target="_blank">Principles</a>, along with complementary principles and approaches (such as <a href="http://www.lean.org/whatslean/principles.cfm" target="_blank">Lean</a> and <a href="http://www.celeritaspublishing.com/PDFS/ReinertsenFLOWChap1.pdf" target="_blank">Flow</a>). Practices, approaches, and methodologies are all tools, and none of them sacred, in an attempt to align more with the Lean|Agile paradigm that will drive successful teams.Anonymoushttp://www.blogger.com/profile/07829612743920787477noreply@blogger.com0tag:blogger.com,1999:blog-8737362623239996105.post-53300082146826803352014-08-07T09:10:00.000-06:002014-08-07T09:10:13.882-06:00WSJF - What to do in a tie?<a href="https://www.linkedin.com/profile/view?id=29871434" target="_blank">Todd Kromann</a> and I facilitated a <a href="http://agile2014.sched.org/event/13c6bb5895ac70e21231df62698b37da" target="_blank">workshop at Agile2014</a> on the subjects of <a href="http://devjam.com/2010/08/05/dudes-law-gordon-pask-shoveler/" target="_blank">Dude's Law</a> and <a href="http://scaledagileframework.com/wsjf/" target="_blank">Weighted Shortest Job First (WSJF)</a>. We helped the group understand how to apply relative estimation not only to Cost of Implementation (size, expense, complexity, etc.) but also Cost of Delay (urgency, risk, dependency, compliance, etc.). We used the modified Fibonacci sequence most often used for Story Points to quantify both of these numbers, which was done by table teams. Each feature's Value Index, used to prioritize, was determined by its Cost of Delay number divided by its Cost of Implementation number. (You can get a soft copy of the handout we used <a href="http://schd.ws/hosted_files/agile2014/85/1691_Dude's_Law_Handout.pdf" target="_blank">here</a>).<br />
<br />
At the end of the workshop we had, as we usually do, a team whose features included a tie. This sometimes happens because they have the exact same Cost of Delay and Cost of Implementation numbers. More often, this happens because the numbers used in the equation are different, but the division comes out the same. One of the questions that invariable arises is: which feature should be prioritized first?<br />
<br />
In theory, it doesn't matter - the ratio of urgency to expense is the same. Once both are implemented the ROI is equal. The decision of which to do first should be determined by the organization. In reality, I believe that the smaller feature should be implemented first. I've drawn up an example to illustrate.<br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEije3_qalZdwsy-rFZZgcpSqhyW24PIARiceEhiX9o7zl9Tlg9zX0iJlq4oTx2ZknIffnMWbBt1XO3K8KuzeH2LCog9fP97f4LwNZzCW4bfunQkFvHMDw3o-iK3Q5gukfM65eatgSz6XMg/s1600/wsjf_chart.jpg" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEije3_qalZdwsy-rFZZgcpSqhyW24PIARiceEhiX9o7zl9Tlg9zX0iJlq4oTx2ZknIffnMWbBt1XO3K8KuzeH2LCog9fP97f4LwNZzCW4bfunQkFvHMDw3o-iK3Q5gukfM65eatgSz6XMg/s1600/wsjf_chart.jpg" height="192" width="320" /></a></div>
<br />
In this scenario, we have two features, A and B. Feature B is 20 times more expensive than A, but also 20 times as valuable. Let's look at what would happen if we implemented Feature A first.<br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEi8eTcCBGflCfxwONtNKhC53qW5ofQPCv5eGjS8DA5YPBeFmn85aX5muKcerzvjy1KZXq88pjlB2Fh8CisR4F8yArzKKI_ssx6w9Z9BufiDl8V5c4pjNYjoUF_OeYo6R0rILs6NmccCNGQ/s1600/wsjf_a-first.jpg" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEi8eTcCBGflCfxwONtNKhC53qW5ofQPCv5eGjS8DA5YPBeFmn85aX5muKcerzvjy1KZXq88pjlB2Fh8CisR4F8yArzKKI_ssx6w9Z9BufiDl8V5c4pjNYjoUF_OeYo6R0rILs6NmccCNGQ/s1600/wsjf_a-first.jpg" height="320" width="214" /></a></div>
<br />
As you can see, we get a little value very quickly and significantly more after a delay. If we say that the y-axis represents millions of dollars and the x-axis represents quarters of the year, then we get $2MM/quarter after our first three months with no increase until five years later, when our quarterly revenue jumps to $42MM. By the end of our 22nd quarter, we will have earned $82MM.<br />
<br />
Now let's see what it would look like if we did Feature B first.<br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhADGH3WUJmZ1sbpKU0F_Zw8JD4Nwdr7riqUNu5sFqzdg4gvgfIQ32mlajTsD-UrNNK1xqK5-IAbwezKUwbbpaJzO4mX-B_DoxwQWhdwWA6_8uLSd2dE7mR1aaQXSKv5L_3XU4Y88W6AjQ/s1600/wsjf_b-first.jpg" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhADGH3WUJmZ1sbpKU0F_Zw8JD4Nwdr7riqUNu5sFqzdg4gvgfIQ32mlajTsD-UrNNK1xqK5-IAbwezKUwbbpaJzO4mX-B_DoxwQWhdwWA6_8uLSd2dE7mR1aaQXSKv5L_3XU4Y88W6AjQ/s1600/wsjf_b-first.jpg" height="320" width="215" /></a></div>
<br />
Using the same axis values as before, we're basically going five years without any revenue. However, after five years of development, our revenue jumps to $40MM/quarter, with a $2MM/quarter bump immediately after. Just like before, we will have earned $82MM by the end of our 22nd quarter and will be earning $42MM/quarter thereafter.<br />
<br />
So which one's better?<br />
<br />
Do you really want to go five years without bringing in any revenue? Of course not! You'd much rather start capitalizing on your work after only one quarter's worth of work. Not only do you now have some money in to fund yourself, you're learning from the market based on how they use what you've released. This new-found knowledge will improve the quality of subsequent releases.<br />
<br />
The reality is that, although the former option is better than the latter, neither are great. What you should do is, while you implement Feature A, break down Feature B into smaller components. It is highly unlikely that all of these components will have a 2:1 ratio of CoD:CoI. You'll identify which sub-Features provide the highest relative ROI and implement them as soon as you finish with Feature A. There may be sub-Features that you never get around to implementing because the value doesn't justify the expense. You can instead move on to a new Feature and begin decomposing and prioritizing its pieces. By the end of your 22nd quarter, you'll end up bringing in much more than the $82MM/quarter number that the two options above afforded.<br />
<br />
That's my take on what to do in the event of a WSJF tie. What would you do?Anonymoushttp://www.blogger.com/profile/07829612743920787477noreply@blogger.com0tag:blogger.com,1999:blog-8737362623239996105.post-16921232488030122882014-08-04T21:05:00.001-06:002014-08-04T21:07:22.494-06:00Personal WIPAs my faithful subscribers (all both of you) may have noticed, I haven't posted anything in a while. Despite my commitment at the beginning of the year to blog at least weekly, I found myself recently with too much Personal WIP (Work In Progress). Let me catch you up on what's been going on.<br />
<br />
<h3>
New Baby!</h3>
<div class="separator" style="clear: both; text-align: center;">
<img border="0" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjbijTEwpkr95cwUNXyh5wLKzDhfjXpOzS7ToOnESD8Dsqji-8vSpFLG27Ve1cfeVWJ6nQQji6lDCOObDizXuIm2NuDX2KUurFGNWJQeZz0TuoeZ7dCYlTwkk_ARMQdzNIWLb-S722iImc/s1600/Gus+with+siblings.jpg" width="90%" /></div>
<br />
We recently welcomed our third child into the world! His older brother and sister are both very excited, as you can see. He's been a joy, one that's kept us quite busy! He came in at 10 and a half pounds, which means that I spent more and more time helping at home to alleviate the burden on my already overburdened wife. This was a no-brainer - as my WIP increased, the priority went to my family.<br />
<br />
<h3>
Agile2014</h3>
<div class="separator" style="clear: both; text-align: center;">
<a href="http://schd.ws/hosted_files/agile2014/85/1691_Dude's_Law_Handout.pdf" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhd3UwnZy6j7Om1nSnXwa9QH8dRbdDgmN32toxBfP1tN4q6ZnONxuOfHDjZd5ia5m7Q2UURQ7iblY1RpApZzsJRuuM7BM_UX2DdthQzr0hka_i2D_5i8Gqafsy0EkmxR18PC1ga1LfOCyQ/s1600/agiledude.jpg" width="90%" /></a></div>
<div>
<br /></div>
<div>
Last week I had two firsts: I attended my first Agile Alliance conference and presented at my first Agile conference! I made sure that I had family and friends in place to assist my wife with our 2-week-old and flew to Orlando to co-present with fellow Agile Coach, <a href="https://www.linkedin.com/profile/view?id=29871434" target="_blank">Todd Kromann</a>. We didn't use any slides, just a hand-written handout (<a href="http://schd.ws/hosted_files/agile2014/85/1691_Dude's_Law_Handout.pdf" target="_blank">available here</a>), some index cards, markers, and tape. We played a game and had a great discussion. We even had the Dude himself, David Hussman, show up and commend us on our use of his Intellectual Property. We had a blast! Of course, in order for it to go as smoothly as it did, I had to spend some time before the baby came tweaking the handout and rehearsing the workshop.<br />
<br />
<h3>
Walmart Agile Summit</h3>
</div>
<div>
Prior to Agile2014, I participated in a 3-day Walmart Agile Summit in June. While I wasn't as involved as I'd have liked (again, that pesky WIP), I was on the core team and got to present a dry-run of my Dude's Law workshop. I got to meet Al Shalloway and Don Reinertsen, and I got to see Pat Reed and Rich Sheridan again. It was a fantastic experience made possible through the hard work and dedication of many people. I may not have had a lot of bandwidth, but I wanted to make sure I dedicated at least some of my WIP went to the Summit.</div>
<div>
<br /></div>
<h3>
Walmart Agile Transformation</h3>
<div>
Of course, as the Agile Summit might have indicated, we're taking the Agile effort at Walmart quite seriously. I'm not going to disclose a lot of information or details - this isn't going to be a case study - but Todd and I were the first 2 Agile Coaches in Walmart's Bentonville office, and we wanted to make sure the Agile Transformation was done by invitation, not edict. We've had fantastic support from senior leadership, and the success of our Agile teams has accelerated the grassroots momentum that's been building. The Agile Summit served as gasoline to the proverbial fire, and interest in Agile began to rise sharply, even before the first day of the Summit. My time at work has been exciting, challenging, and incredibly rewarding. As much as I wanted to keep sharing my thoughts with the blogosphere, I owe my professional efforts first and foremost to my fellow Associates.</div>
<div>
<br /></div>
<div>
So that's what I've been up to. I can't promise I'll resume blogging on a weekly basis, but I am cautiously optimistic that I'll be posting more regularly that I have the past few months!</div>
Anonymoushttp://www.blogger.com/profile/07829612743920787477noreply@blogger.com0tag:blogger.com,1999:blog-8737362623239996105.post-72478323911140727902014-05-27T15:06:00.001-06:002014-05-27T15:06:10.483-06:00Understanding Agile Planning part 2: Decomposition GuidelinesI recently wrote a post explaining the process of <a href="http://careytechblog.blogspot.com/2014/03/understanding-agile-planning.html" target="_blank">Agile Planning</a>. When done correctly, your work is decomposed to just the right level, just in time. If you haven't read this yet, please take a few minutes to familiarize yourself. I'll wait.<br />
<div>
<br /></div>
<div>
Good. Now that you understand the context, I want to address a concern that's been brought up recently: how do I know when to decompose my work? The short answer is always, but that's a little too ambiguous for most people. I'm going to share my guidelines here, and I'd ask that you share your advice in the comments.</div>
<div>
<br /></div>
<div>
<b><span style="font-size: large;">Five Thresholds of Decomposition</span></b></div>
<div>
Of course, as we decompose our work from high-level strategy (i.e. themes) to the low level work that team members execute on (i.e. stories or tasks), we rarely find that it fits neatly into 5 iterations of decomposition. Interestingly enough, that doesn't really matter. What does matter is the threshold that you establish for each level.</div>
<div>
<br /></div>
<div>
I'll start with User Stories, as that's the size that most people are already familiar with. Most teams have an upper-limit for how many Story Points a User Story can be in order for them to commit to it. Most of the time this is 8 points, though I've seen as high as 13 and as low as 3. Regardless, it's easy to see how the team has established a threshold for their User Stories. Whether you classify work larger than the team's threshold as a different type of work (Feature, Epic, etc.) or just call it a big User Story, the fact remains that it does not fit within the threshold for that level of planning. It must be decomposed.</div>
<div>
<br /></div>
<div>
Let's say that anything larger than 13 points is a Feature - but to what threshold? I would recommend something that can be done within 3 Sprints or less. Features are the lowest level of value as seen from the end-user's perspective, and end-to-end value should be production-ready with no more than 3 Sprints of development, depending on the product.</div>
<div>
<br /></div>
<div>
If your team's average velocity is 42, then your upper threshold for Features would be 126. That number's a little too precise for me, so let's call it 100. As Features become high priority, they should be broken into User Stories and prioritized for the coming Sprints' Planning ceremonies. Until that time, however, there is no need to decompose lower than the 100 point threshold.</div>
<div>
<br /></div>
<div>
Let's call Epics anything that take a quarter or less to deliver. This would be 13 weeks, so let's be conservative and call that six Sprints. We're now looking at 252 points, which can be rounded to 200, 250, or 400, depending on the scale you prefer. We now know that the work we're considering doing within the next quarter or two should be broken down into Epics that are within that threshold. While Epics may logically be broken down to under 100 points, we shouldn't feel compelled to split Epics that are already under our Epic threshold until they're a month or two out.</div>
<div>
<br /></div>
<div>
Anything larger than an Epic could be considered a Theme, with no upper-limit. You may decide that even Themes need an upper limit, but I generally don't include that in my recommendations.</div>
<div>
<br /></div>
<div>
<b><span style="font-size: large;">Guidelines</span></b></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: left;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhMVIMjbD7qrTnMnhahIqbRjKvJhpSKTVERc6w8bgqdOoVi7BRyxOsO2tyZxmvzJTe7LpJpaWyve19iBO6KDGb4msKqKPqckdcnJboRtPJE-GQhfEPMqXbHzJlbWJJqv6SEf9RY36-lxvE/s1600/guidelines.gif" imageanchor="1" style="margin-left: auto; margin-right: auto;"><img border="0" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhMVIMjbD7qrTnMnhahIqbRjKvJhpSKTVERc6w8bgqdOoVi7BRyxOsO2tyZxmvzJTe7LpJpaWyve19iBO6KDGb4msKqKPqckdcnJboRtPJE-GQhfEPMqXbHzJlbWJJqv6SEf9RY36-lxvE/s1600/guidelines.gif" width="100%" /></a></td></tr>
<tr><td class="tr-caption" style="text-align: center;"><i>This blog is more what you'd call guidelines than actual rules.</i></td></tr>
</tbody></table>
<div>
As I stated previously, these are simply guidelines. You may take a totally different approach. I find that some areas may define a Feature as something that takes two teams 4 weeks to do, knocking the threshold up to over 300. Others may decide that 100 is their Epic threshold. However you decide to define them, using thresholds as part of your working agreements make it very easy to tell when work needs to be decomposed and when it's better to wait so as to avoid rework or unnecessary work.</div>
Anonymoushttp://www.blogger.com/profile/07829612743920787477noreply@blogger.com0tag:blogger.com,1999:blog-8737362623239996105.post-47453272105894163722014-05-14T19:48:00.001-06:002014-05-14T19:48:15.627-06:00Hope and Direction<div class="separator" style="clear: both; text-align: center;">
</div>
<div style="background-color: white; border: 0px; color: #333333; font-family: Arial, sans-serif; font-size: 15px; line-height: 20px; margin-left: 1em; margin-right: 1em; margin-top: 1em; outline: 0px; padding: 0px; vertical-align: baseline;">
</div>
<br />
<br />
<div style="background-color: white; border: 0px; color: #333333; font-family: Arial, sans-serif; line-height: 20px; margin-bottom: 1em; margin-top: 1em; outline: 0px; padding: 0px; vertical-align: baseline;">
<span style="font-size: x-small;"><i>(Note: Originally posted without the Agile context at https://www.linkedin.com/today/post/article/20140515013228-19267203-hope-and-direction)</i></span></div>
<div style="background-color: white; border: 0px; color: #333333; font-family: Arial, sans-serif; font-size: 15px; line-height: 20px; margin-bottom: 1em; margin-top: 1em; outline: 0px; padding: 0px; vertical-align: baseline;">
My primary responsibility is to help teams unlock their full potential. That means introducing change, and change is usually difficult. As I describe the possibilities of what a team can accomplish, they become incredulous that they'll ever get to that point, and therefore are hesitant to start.</div>
<div style="background-color: white; border: 0px; color: #333333; font-family: Arial, sans-serif; font-size: 15px; line-height: 20px; margin-bottom: 1em; margin-top: 1em; outline: 0px; padding: 0px; vertical-align: baseline;">
They hear about this amazing team that continuously deploys to production by leveraging cross-functional team members who are experts at automation, test-driven development, SOA design patterns, and a dozen other practices.</div>
<div style="background-color: white; border: 0px; color: #333333; font-family: Arial, sans-serif; font-size: 15px; line-height: 20px; margin-bottom: 1em; margin-top: 1em; outline: 0px; padding: 0px; vertical-align: baseline;">
</div>
<div style="background-color: white; border: 0px; color: #333333; font-family: Arial, sans-serif; font-size: 15px; line-height: 20px; margin-bottom: 1em; margin-top: 1em; outline: 0px; padding: 0px; vertical-align: baseline;">
I reassure them by explaining that I'm giving them direction, something to work towards. I encourage them to take that direction and make it their own. I then give them hope that they can begin changing - indeed must begin changing - before that vision is realized. I have them ask themselves what small change they can enact now to begin on their journey.</div>
<div style="background-color: white; border: 0px; color: #333333; font-family: Arial, sans-serif; font-size: 15px; line-height: 20px; margin-bottom: 1em; margin-top: 1em; outline: 0px; padding: 0px; vertical-align: baseline;">
</div>
<div style="background-color: white; border: 0px; color: #333333; font-family: Arial, sans-serif; font-size: 15px; line-height: 20px; margin-bottom: 1em; margin-top: 1em; outline: 0px; padding: 0px; vertical-align: baseline;">
</div>
<div class="separator" style="clear: both; text-align: center;">
<a href="https://media.licdn.com/mpr/mpr/p/5/005/05f/360/1ef2f32.jpg" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img alt="" border="0" class="left" src="https://media.licdn.com/mpr/mpr/p/5/005/05f/360/1ef2f32.jpg" style="border: 0px; font-family: inherit; font-style: inherit; font-variant: inherit; font-weight: inherit; line-height: inherit; margin-top: 0px; max-width: 606px; outline: 0px; padding: 0px; vertical-align: baseline;" /></a></div>
<div style="background-color: white; border: 0px; color: #333333; font-family: Arial, sans-serif; font-size: 15px; line-height: 20px; margin-bottom: 1em; margin-top: 1em; outline: 0px; padding: 0px; vertical-align: baseline;">
I've learned that teams with hope but not direction become too scattered in their efforts, and their enthusiasm and passion becomes too dispersed to be sustained. Perhaps the team has both hope and direction, but that direction is too short-sighted, resulting in the team achieving a new status quo before fully realizing their potential.</div>
<div style="background-color: white; border: 0px; color: #333333; font-family: Arial, sans-serif; font-size: 15px; line-height: 20px; margin-bottom: 1em; margin-top: 1em; outline: 0px; padding: 0px; vertical-align: baseline;">
</div>
<div style="background-color: white; border: 0px; color: #333333; font-family: Arial, sans-serif; font-size: 15px; line-height: 20px; margin-bottom: 1em; margin-top: 1em; outline: 0px; padding: 0px; vertical-align: baseline;">
Inversely, teams with direction and no hope quickly become discouraged and cynical, viewing such a perfect end-state as unrealistic, unattainable, and not worth pursuing. They give up before starting. The worst part is that they feel they've been peddled snake oil, and they become jaded to future change initiatives. They become the defenders of the status quo.</div>
Anonymoushttp://www.blogger.com/profile/07829612743920787477noreply@blogger.com0tag:blogger.com,1999:blog-8737362623239996105.post-16475214584890928702014-04-21T09:17:00.002-06:002014-04-21T09:17:23.125-06:00Not just Agile - ____ Agile!<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/AVvXsEj7WgC8lEl62mWz0bbZO6M4Mb-BNPB_hNVtGyu5Pq9KF7gZF2KQwJMTuCQuWAudUnQKj_g9ZwSz4RiGhsULCNcMPN067tegnXvSl6GoIGuxWoF4q0la1wjTSSQsvfoZoC3W4MRjRd2faK8/s1600/dilbert.png" imageanchor="1" style="margin-left: auto; margin-right: auto;"><img src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEj7WgC8lEl62mWz0bbZO6M4Mb-BNPB_hNVtGyu5Pq9KF7gZF2KQwJMTuCQuWAudUnQKj_g9ZwSz4RiGhsULCNcMPN067tegnXvSl6GoIGuxWoF4q0la1wjTSSQsvfoZoC3W4MRjRd2faK8/s1600/dilbert.png" width="90%" /></a></td></tr>
<tr><td class="tr-caption" style="text-align: center;">Let's do whatever we want and call it a new flavor of Agile!</td></tr>
</tbody></table>
Every now and again, I meet a team that's doing things very differently than your traditional Agile team. They often label themselves with a prefix - they're not just Agile, they're "Extreme Agile" or "Hyper Agile". Personally, I think that the term Agile encompasses all that a team would ever aspire to be, though Agile teams may be at varying levels of maturity. Scrum, Kanban, SAFe, DevOps - whatever you want to call yourselves, your team should strive to get better and better at aligning with the <a href="http://agilemanifesto.org/" target="_blank">Agile Manifesto</a> and its <a href="http://agilemanifesto.org/principles.html" target="_blank">Principles</a>. This means your practices reflect Agility and your are continuously improving.<br />
<br />
So how can you tell if you're Agile? I recommend asking three groups of people: your peers, your clients, and yourselves.<br />
<br />
<b><span style="font-size: large;">Your Peers</span></b><br />
If you're an Agile team operating as part of a larger organization, there should be a balance between competition and collaboration between teams. Everyone wants their team to be the best, but not because the other teams are so bad. You should be working hard to improve your competition, a.k.a. the other teams in the company, so that they, in turn, will push you to be better.<br />
<br />
Ask your peers how Agile you are and be prepared for some candid yet constructive feedback. Remember, you're all in this together. Cross-pollination and frequent feedback from your peers makes everyone better.<br />
<br />
<b><span style="font-size: large;">Your Clients</span></b><br />
It doesn't matter what the nature of your team is, your code is being used by someone. Whether it's an end-customer, a business user in another division, another system within your technical organization, etc., there's somebody who uses what it is you're building. The <a href="http://agilemanifesto.org/" target="_blank">Agile Manifesto</a> and its <a href="http://agilemanifesto.org/principles.html" target="_blank">Principles</a> make it very clear what kind of relationship with and service to our customers we should be striving for. All you have to do is ask your clients whether they feel that relationship and service is there.<br />
<br />
You should also look for ways to continuously improve how your interact with and serve your clients. What delights your customers today will soon become the status quo. If you're a good Agile team, you're meeting with your customers and getting feedback on a frequent basis, anyway. Take some time to go over how you're delivering, not just what you're delivering.<br />
<br />
<b><span style="font-size: large;">Yourselves</span></b><br />
We are often our harshest critics. I encourage all Agile teams to have everyone on the team fill out some sort of self-assessment on a regular basis (a <a href="https://www.google.com/search?q=agile+team+self+assessment" target="_blank">quick search</a> will provide you some examples). By getting as many responses as possible, you avoid the extreme ups and downs that come from individuals. Look at the mean and median results, then discuss your perceived strengths and weaknesses as a team.<br />
<br />
Sometimes we feel we're at the top of our class because we're excelling at what we understand Agile to be. It's important to stay involved with the greater Agile community so you can find out the latest and (potentially) greatest practices and techniques for driving Agility. Even more importantly, recognize that there's no such thing as perfection, only better, and instill a passion for continuous improvement within your team.<br />
<br />
<b><span style="font-size: large;">And Also...</span></b><br />
I'm sure there are other ways to gauge a team's Agility. What other ways would you recommend for teams to assess how Agile they are? Is there a place for "Extreme" or "Hyper" Agile in our vernacular? Is it a positive thing to have pockets of disproportionately high Agile maturity in your organization? What are you doing to drive an overall increasing Agile maturity?Anonymoushttp://www.blogger.com/profile/07829612743920787477noreply@blogger.com0tag:blogger.com,1999:blog-8737362623239996105.post-929548034798826142014-04-07T08:03:00.001-06:002014-04-07T08:06:28.677-06:00Discord in AgilelandI've seen a lot of blog posts and articles circulating about how horrible the state of Agile has become. The central theme to these is that the term "Agile" has moved away from the principles that they established to the practices that are commonly used by "Agile" teams and organizations. I'd like to gently suggest that we not throw the baby out with the bath water.<br />
<div>
<br /></div>
<div>
Look, I totally get it. I really do. A quick glance at my own blog's history will tell you that I'm a huge advocate of sticking to the <a href="http://agilemanifesto.org/principles.html" target="_blank">Agile principles</a> and paradigm. Adopting practices, techniques, frameworks, or methodologies without internalizing the <a href="http://agilemanifesto.org/" target="_blank">Agile Manifesto</a> and its <a href="http://agilemanifesto.org/principles.html" target="_blank">Principles</a> is an exercise in diminishing returns (if any). However, it's also very difficult to ascertain how well an organization has internalized Agile into its culture. Like the saying goes, "The proof is in the tasting of the pudding," meaning that Agile teams do, in fact, behave differently because of how they've internalized Agile.<br />
<br />
<span style="font-size: large;"><b>Theological Agility</b></span><br />
<table align="center" class="tr-caption-container" style="margin-left: auto; margin-right: auto; text-align: center;"><tbody>
<tr><td style="text-align: center;"><a href="http://williamgill.de/2011/11/10/5-reasons-agile-is-like-a-cult/" imageanchor="1" style="margin-left: auto; margin-right: auto;"><img border="0" src="http://williamgill.de/blog/images/agile-is-a-cult-manifesto.jpg" width="90%" /></a></td></tr>
<tr><td class="tr-caption" style="text-align: center;">"You will respect the sacred parchment" -- 5 reasons Agile is like a cult</td></tr>
</tbody></table>
One of the better blog posts that I've read on the subject was written by Dave Thomas, one of the <a href="http://agilemanifesto.org/" target="_blank">Agile Manifesto</a>'s original signatories. In <a href="http://pragdave.me/blog/2014/03/04/time-to-kill-agile/" target="_blank">"Agile is Dead (Long Live Agility)"</a>, he writes, "Once the Manifesto became popular, the word <i>agile</i> became a magnet for anyone with points to espouse, hours to bill, or products to sell. It became a marketing term, coopted to improve sales in the same way that words such as <i>eco</i> and <i>natural</i> are. A word that is abused in this way becomes useless—it stops having meaning as it transitions into a brand."<br />
<br />
People have exploited the agile brand to push their own agendas, that's for sure. All too often these days you meet someone trying to sell a practice or approach who can't name more than a couple of the <a href="http://agilemanifesto.org/principles.html" target="_blank">Agile Principles</a> (if any). I have personally trained people on Agile who had "heard so much about it", yet had never heard of such a thing as the <a href="http://agilemanifesto.org/" target="_blank">Agile Manifesto</a>.<br />
<br />
So yes, we do need to work on getting back to our roots. However, that does not make all practices and approaches evil. This way of thinking is way too <a href="http://williamgill.de/2011/11/10/5-reasons-agile-is-like-a-cult/" target="_blank">theological</a> for an approach that must be practically applicable.<br />
<br />
Making a living off of changing people's lives is not a crime against Agile. Furthermore, there are some practices that have existed for long enough that I would consider a team to be un-Agile or a low-maturity Agile team if they weren't doing them.<br />
<br />
<span style="font-size: large;"><b>By their Fruits</b></span><br />
<table align="center" 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/AVvXsEgUSpTAJgdWkt4VjkP7GmQqwpF8Y5Vwh8qxBrxEjPDpROJbesU6qBbZlkdCk4cbQgb-1sIWJNHmiTCPerNs-gvGj_qRcMhDw5wHQOImADgVVMV8XnRYbz9eVnVL6aRP7S-rjje8KqxoKUa_/s1600/fruit.jpg" imageanchor="1" style="margin-left: auto; margin-right: auto;"><img border="0" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgUSpTAJgdWkt4VjkP7GmQqwpF8Y5Vwh8qxBrxEjPDpROJbesU6qBbZlkdCk4cbQgb-1sIWJNHmiTCPerNs-gvGj_qRcMhDw5wHQOImADgVVMV8XnRYbz9eVnVL6aRP7S-rjje8KqxoKUa_/s1600/fruit.jpg" width="90%" /></a></td></tr>
<tr><td class="tr-caption" style="text-align: center;">By their fruits ye shall know them - Agile Teams have Agile practices, produce quality value, and are happy!</td></tr>
</tbody></table>
In his blog post <a href="http://www.drdobbs.com/architecture-and-design/the-corruption-of-agile/240166698" target="_blank">"The Corruption of Agile"</a>, Andrew Binstock writes about the evils of building a brand off of Agile. He states that teams can be doing Agile practices without being Agile, and they can be Agile without doing Agile practices. My confusion is: how do you know a team is Agile if they aren't acting Agile? Practices such as TDD and Continuous Integration enable the team to deliver the values stated in the Agile Manifesto and its principles. If a team's not doing them, what are they doing to get there? Do they inspect and adapt on a regular basis? Are they striving to deliver something to their customers every 2 weeks to 2 months (with a preference for the shorter timescale)? How do you know they are Agile if their practices aren't Agile?<br />
<br />
Agile practices can be a good gauge for a team's Agility. I do not advocate their use as the only metric of Agility, but they provide a good starting point for assessing a team. If a team is using Scrum and has implemented TDD and Continuous Integration, it's going to take a fair amount of convincing for me to believe they aren't "Agile", for how did they get to that point if they weren't continuously improving? Perhaps they were Agile at one time and had grown stale, but there is certainly evidence that they were at least Agile at one point in time.<br />
<br />
<span style="font-size: large;"><b>Keep an Open Mind</b></span><br />
Do we need to focus on our roots, the foundation of Agile culture that will breed lasting success in our teams? Absolutely! Our people should be consistently reminded of what it means to be Agile to ensure they are adapting towards greater Agility instead of away from it. Are people who introduce practices, approaches, and techniques that enable and empower a team to become more Agile inherently evil? Absolutely not! A team that understands what Agility is can tell when someone's trying to pull one over on them versus a person who genuinely has their best interests at heart.<br />
<br />
I love going to conferences and learning about the latest and greatest in the Agile world. I love being a part of a community that is so obsessed with making people's lives better. I love the healthy debate and pragmatism that comes with experience. And I loathe those who are clearly pushing their own agenda without a reality check or an understanding of what Agile is really all about. I think it's time we took a more measured approach to our criticism, understanding that not all Agile consultants are wolves in sheep's clothing; indeed, more of them than you think are just trying to make the world a better place.</div>
Anonymoushttp://www.blogger.com/profile/07829612743920787477noreply@blogger.com0tag:blogger.com,1999:blog-8737362623239996105.post-6404743190723355292014-04-04T09:57:00.003-06:002014-04-04T09:57:30.455-06:00Favorite Agile PrincipleThere's been a lot of buzz lately in the Agile community about how far we've gotten from our roots. Most of the talk is around the evils of associating specific approaches with Agile; some have gone so far as to say if you advocate a practice as standard for Agile then you've lost your compass. I have some ideas brewing around those ideas. In the mean time, I thought I'd throw out a positive post to encourage people to get back to their Agile roots. My question is simple: What's your favorite <a href="http://agilemanifesto.org/principles.html" target="_blank">Agile Principle</a>?<br />
<br />
Mine is easy: "Simplicity -- the art of maximizing the amount of work not done -- is essential". This principle is elegant and <i style="font-weight: bold;">so</i> applicable to my life. I am constantly over-complicating my life, so I've made this principle my mantra to keep me in check.<br />
<br />
I understand that all of the <a href="http://agilemanifesto.org/principles.html" target="_blank">Principles </a>are important, so don't get hung up on the question. I'm not asking which one is best or most "Agile", I just want to know which is your favorite.<br />
<br />
If you need a refresher, they can be found here:<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="http://agilemanifesto.org/principles.html"><img src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjwYAIm5hTaD7zgMDRsUvCiaHFVsdASa6E6vGH1VBMJeLNcLupF8vj_StFSqMw5MWqOMTGgG7Ttfurp3P5dI4wDtCQBa4598FHlz_r6qgrX5H4wKz6c59CYjsY6LdsWhG4_sjCn-xksjhI/s1600/Agile_Principles_Header.png" width="100%" /></a></div>
<ol>
<li>Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.</li>
<li>Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage.</li>
<li>Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.</li>
<li>Business people and developers must work together daily throughout the project.</li>
<li>Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.</li>
<li>The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.</li>
<li>Working software is the primary measure of progress.</li>
<li>Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.</li>
<li>Continuous attention to technical excellence and good design enhances agility.</li>
<li>Simplicity--the art of maximizing the amount of work not done--is essential.</li>
<li>The best architectures, requirements, and designs emerge from self-organizing teams.</li>
<li>At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.</li>
</ol>
<br />Anonymoushttp://www.blogger.com/profile/07829612743920787477noreply@blogger.com0tag:blogger.com,1999:blog-8737362623239996105.post-42519738061228439342014-04-02T08:12:00.001-06:002014-04-02T08:12:18.865-06:00Introspective: Where are the Introspectives?I mentioned <a href="http://careytechblog.blogspot.com/2014/03/introspective-trying-new-things.html" target="_blank">a couple of weeks ago</a> that I was going to try out LinkedIn's publishing tool. I've really enjoyed using it, so I've decided to keep this blog to more technical subjects and use LinkedIn for more general advice and introspection. I'll continue to blog here for the foreseeable future, especially on Agile topics that are too technical for a broad, diverse audience. If you'd like to follow my posts on LinkedIn, you can find them on my <a href="https://www.linkedin.com/today/author/19267203" target="_blank">LinkedIn author page</a>.Anonymoushttp://www.blogger.com/profile/07829612743920787477noreply@blogger.com0tag:blogger.com,1999:blog-8737362623239996105.post-75746034992060961722014-03-25T10:26:00.001-06:002014-03-25T10:26:36.571-06:00Agile2014 Proposal Accepted<span style="font-family: Arial, Helvetica, sans-serif;">Today is a big day for me; today I accepted an invitation to speak at a conference for the first time! Todd Kromann and I will be co-facilitating a workshop I've put together on value-driven prioritization, based on the concepts of Hussman's "Dude's Law" and WSJF. I've copied my abstract below. If you're going to be at Agile2014, let me know! I'd love to meet you in Orlando this summer!</span><br />
<div>
<span style="font-family: Arial, Helvetica, sans-serif;"><br /></span></div>
<div>
<h1 style="background-color: white; color: #222222; margin: 0px; position: relative;">
<a href="https://submissions.agilealliance.org/sessions/1691" style="color: #888888; text-decoration: none;"><span style="font-family: Arial, Helvetica, sans-serif; font-size: x-large;">Practical Application of Dude's Law: Come Play the Value Estimation Game!</span></a></h1>
<span style="font-family: Arial, Helvetica, sans-serif; font-size: large;"><b>Abstract:</b></span><br />
<div class="MsoNormal" style="background-color: white; color: #222222; line-height: 18.479999542236328px;">
<span style="font-family: Arial, Helvetica, sans-serif;">You know how you determine the "bigness" of your work and establishing commitments, but how do your customers ensure you're committing to the right thing?</span><br />
<span style="font-family: Arial, Helvetica, sans-serif;"><br /></span></div>
<div class="MsoNormal" style="background-color: white; color: #222222; line-height: 18.479999542236328px;">
<span style="font-family: Arial, Helvetica, sans-serif;">Come experience relative estimation to determine value. We'll use David Hussman's "Dude's Law" (Value = Why? / How?) to prioritize the work.</span><br />
<span style="font-family: Arial, Helvetica, sans-serif;"><br /></span></div>
<div class="MsoNormal" style="background-color: white; color: #222222; line-height: 18.479999542236328px;">
<span style="font-family: Arial, Helvetica, sans-serif;">We will share techniques for determining the "Why?" so that you can generate a Value Index. What many people will be surprised to learn is that they already have tools for sizing that can be used for determining value and prioritization.</span></div>
<div class="MsoNormal" style="background-color: white; color: #222222; line-height: 18.479999542236328px;">
<span style="font-family: Arial, Helvetica, sans-serif;"><br /></span></div>
<span style="font-family: Arial, Helvetica, sans-serif; font-size: large;"><b>Information for Review Team:</b></span><br />
<span style="font-family: Arial, Helvetica, sans-serif;">The break-out of the 75 minutes would include:</span><br />
<span style="font-family: Arial, Helvetica, sans-serif;"><strong>3 minutes:</strong> Introduction to Dude's Law and the Value-Driven Heuristic</span><br />
<span style="font-family: Arial, Helvetica, sans-serif;"><strong>10 minutes:</strong> Explain and model the first exercise (Team Estimation Game for relative sizing)</span><br />
<span style="font-family: Arial, Helvetica, sans-serif;"><strong>10 minutes:</strong> Have round-table teams execute first exercise with a set of 10 features</span><br />
<span style="font-family: Arial, Helvetica, sans-serif;"><strong>5 minutes:</strong> Explain and model the second exercise (Team Estimation Game for relative benefit - same mechanism, so it takes less time to explain and model)</span><br />
<span style="font-family: Arial, Helvetica, sans-serif;"><strong>10 minutes:</strong> Have the round-table teams execute second exercise with the same set of 10 features</span><br />
<span style="font-family: Arial, Helvetica, sans-serif;"><strong>10 minutes:</strong> Have each team determine the Value Index of each card by applying Dude's Law</span><br />
<span style="font-family: Arial, Helvetica, sans-serif;"><strong>15 minutes:</strong> Have teams share their outcomes, insights</span><br />
<span style="font-family: Arial, Helvetica, sans-serif;"><strong>12 minutes (or less, if previous sections have run over):</strong> Q&A *</span><br />
<span style="font-family: Arial, Helvetica, sans-serif;"><br /></span>
<span style="font-family: Arial, Helvetica, sans-serif;">* In the case that there are not enough questions to fill the remaining time, I will explain the flexibility of Dude's Law (you can use Planning Poker or whatever technique works best for you) and introduce them to concepts such as Weighted Shortest Job First and Value Dial weighting.</span><br />
<div class="MsoNormal" style="background-color: white; color: #222222; line-height: 18.479999542236328px;">
<span style="font-family: Arial, Helvetica, sans-serif;"><br /></span></div>
<span style="font-family: Arial, Helvetica, sans-serif; font-size: large;"><b>Prerequisite Knowledge:</b></span><br />
<div class="MsoNormal" style="background-color: white; color: #222222; line-height: 18.479999542236328px;">
<span style="font-family: Arial, Helvetica, sans-serif;">The concept of Relative Sizing (Story Points, T-shirt sizing, etc.)</span></div>
<div class="MsoNormal" style="background-color: white; color: #222222; line-height: 18.479999542236328px;">
<span style="font-family: Arial, Helvetica, sans-serif;"><br /></span></div>
<span style="font-family: Arial, Helvetica, sans-serif; font-size: large;"><b>Learning Outcomes:</b></span>
<br />
<ul>
<li><span style="background-color: white; color: #222222; font-family: Arial, Helvetica, sans-serif; line-height: 18.479999542236328px; text-indent: -0.25in;">Experience and learn how to apply a practical, proven game for prioritizing your work based on value</span></li>
<li><span style="background-color: white; color: #222222; font-family: Arial, Helvetica, sans-serif; line-height: 18.479999542236328px; text-indent: -0.25in;">Understand that using a heuristic for valuation is better than both gut-feel and over-engineering</span></li>
<li><span style="background-color: white; color: #222222; font-family: Arial, Helvetica, sans-serif; line-height: 18.479999542236328px; text-indent: -0.25in;">Understand that, as with estimating size/cost, the real value comes from the conversation</span></li>
</ul>
<div style="text-indent: -24px;">
<span style="color: #222222;"><span style="font-family: Arial, Helvetica, sans-serif; line-height: 18.479999542236328px;"><br /></span></span></div>
<b><span style="font-family: Arial, Helvetica, sans-serif; font-size: large;">Presentation History:</span></b><br />
<div class="MsoNormal" style="background-color: white; color: #222222; line-height: 18.479999542236328px;">
<span style="font-family: Arial, Helvetica, sans-serif;">I've done the Team Estimation Game dozens of times before with as many teams and have done the exercise including benefit to determine a Value Index with at least one of those teams. I also have led Program Management teams through a very similar prioritization matrix model that leverages the concept of Weighted Shortest Job First.</span></div>
<div class="MsoNormal" style="background-color: white; color: #222222; line-height: 18.479999542236328px;">
<span style="font-family: Arial, Helvetica, sans-serif;"><br /></span></div>
<span style="font-family: Arial, Helvetica, sans-serif; font-size: large;"><b>Comment:</b></span><br />
<span style="background-color: white; color: #222222; font-family: Arial, Helvetica, sans-serif; line-height: 18.479999542236328px;">My presentation is a reflection of my own beliefs and experiences. None of the material I present should be interpreted as an endorsement by my employer. I have received express written permission from David Hussman to reference Dude's Law, and I am a Certified SAFe Program Consultant (SPC), which qualifies me to speak on their Weighted Shortest Job First (WSJF) Framework.</span></div>
Anonymoushttp://www.blogger.com/profile/07829612743920787477noreply@blogger.com0tag:blogger.com,1999:blog-8737362623239996105.post-75662864453108603302014-03-24T14:08:00.000-06:002014-03-24T14:11:24.467-06:00Understanding Agile PlanningOne common myth about Agile is that those who practice Agile don't plan. I've found the opposite to be true: those who truly understand Agile are planning all the time. The difference is that the planning they do is much more lightweight. They also anticipate change, rather than pretend it doesn't exist, resulting in plans that are living documents instead of notarized relics. Their plans are always accurate, but with varying levels of precision. How do they do this? Using one of the simplest, most powerful planning tools out there: the backlog.<br />
<br />
<span style="font-size: large;"><b>The Backlog</b></span><br />
A backlog is really nothing more than a prioritized list. If you've ever made a To-Do List (or its popular cousin, the Honey-Do List) then you've made a backlog. If your backlog was short, you probably got a lot done and felt a great swell of accomplishment. If your backlog was exhaustive and poorly prioritized, you probably got overwhelmed and did little to "move the needle".<br />
<br />
<span style="font-size: large;"><b>Levels of Planning</b></span><br />
I'm tackling this from an enterprise view of Scrum, but the concepts are the same regardless of how many levels you use or the terminology you pick. In general, an enterprise using Scrum should have five levels of planning.<br />
<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/AVvXsEhueJ-JWyOR1WrhxPXbKp7L5jY_8xpP0sDKwuKY30dZdUl_nDijVtPrY5OrnbGl3WIAJeUvtXivSWJXqW_R6X7Hjzcm9aQR5K2cYzWCKQkj96CDfwsSfNeWXdnECamEsP39HY5wOj1PkJY/s1600/Planning_five_levels.jpg" imageanchor="1" style="margin-left: auto; margin-right: auto;"><img border="0" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhueJ-JWyOR1WrhxPXbKp7L5jY_8xpP0sDKwuKY30dZdUl_nDijVtPrY5OrnbGl3WIAJeUvtXivSWJXqW_R6X7Hjzcm9aQR5K2cYzWCKQkj96CDfwsSfNeWXdnECamEsP39HY5wOj1PkJY/s1600/Planning_five_levels.jpg" height="241" width="320" /></a></td></tr>
<tr><td class="tr-caption" style="text-align: center;">Levels of Planning</td></tr>
</tbody></table>
<br />
I'm not the first to notice these five levels, so I can't take credit for the concept. The idea is that you start with a Vision that serves as your "True North". Everything that you do should align with your Vision, and your Vision statement should be updated infrequently. At this level, you're looking at Themes or Strategies that execute the Vision at a very high level.<br />
<br />
Everything in your Roadmap - lets call them Epics - should align to one or more Theme. You may call it something different, and the word Epic may mean something different to you. When I say Epic, I refer to a set of one or more Features that provide significant strategical value to your organization. Waterfall project charters usually consist of one or more Epics as I've defined them here. Your Roadmap may go out 3-5 years or more, but becomes more "squishy" the further out you go. Roadmaps should be revisited at least quarterly and updated whenever necessary.<br />
<br />
Releases should align to the Roadmap and should consist of one or more Features. When I say "Release", I'm referring to a production release with significant functionality. If you're in a shop that employs Continuous Delivery, this would obviously not refer to the type of release that happens multiple times each day; perhaps the word "Release" doesn't even make sense in that context. Regardless of the term, this is the level that is easiest for end-users to understand. Everything above this level is too abstract, and everything below this level is too granular.<br />
<br />
Sprints should have goals that align with the Release plan. The Scrum teams do this by committing to User Stories that contribute to the completion of the next Releases Feature(s). My recommendation for Sprint Duration is two weeks. I've tried 3-week, 4-week, and month-long Sprints and I didn't care for any of them. Two weeks seems to be the sweet spot. Changes to the Sprint plan should be kept to a minimum, especially if the team is a less-mature Agile team. Again, the mechanics of this change for Kanban, DevOps, or similar teams.<br />
<br />
At the lowest level, the team aligns in their Daily Scrum on how they will work together to accomplish the Sprint's goals. They may be aligning in the context of tasks, which may or may not be planned out at the beginning of the Sprint, but they are not likely to be discussing their daily work in terms more abstract than User Stories. After all, they know how their Stories are tied to Features, how those Features are tied to Epics, and how those Epics are tied to Themes; there's no reason to revisit the higher levels every day.<br />
<br />
<span style="font-size: large;"><b>The Planning Engine</b></span><br />
The mechanism for moving work intake to something that's actionable is actually quite similar across all levels. The cadence, level-of-detail, and people involved may differ, but the process is essentially the same.<br />
<br />
<ol>
<li>Discuss the item</li>
<li>Estimate the item</li>
<li>Prioritize the item</li>
<li>Implement or Decompose the item</li>
<ul>
<li>If Decomposing, the sub-items are fed to the next level down and the process repeats at step #1.</li>
</ul>
</ol>
<div>
At the team level, this is done in the Backlog Grooming sessions (or, as I like to call them, "Story Time"). The same concept can and should be used at the other levels of Planning, simply modified to be appropriate for said level. For example, you may have more executive people meeting quarterly to groom the Epic backlog; you may have representatives from each Scrum team in a product area get together monthly to groom the Feature backlog; and you may meet as a Scrum team each Sprint to groom the Product (User Story) backlog. Use whatever cadence and team members that makes sense for your organization and circumstances.</div>
<div>
<br /></div>
<div>
<span style="font-size: large;"><b>A SAFe Approach</b></span></div>
<div>
If you're familiar with the <a href="http://www.scaledagileframework.com/" target="_blank">Scaled Agile Framework (SAFe)</a>, then you know that what I just described is accounted for in their <a href="http://www.scaledagileframework.com/" target="_blank">Big Picture</a>. If you wanted more advice on how to implement this planning engine then I recommend you view the abstracts found on their website. I've found their advice to be very useful and pragmatic.</div>
<div>
<br /></div>
<div>
You can implement the five levels of planning with a backlog-driven planning engine without SAFe. Indeed, there are many non-SAFe Agile companies that have established an Agile planning process before the advent of SAFe. I'm simply suggesting that, if you're new to this and don't know where to start or if you're in the middle of this and struggling with what you have, check out what SAFe has to offer. Take what works for you and toss the rest.</div>
<div>
<br /></div>
<div>
<span style="font-size: large;"><b>A Rose by Any Other Name...</b></span></div>
<div>
As I stated at the beginning, mine is only one perspective on Agile Planning, and the terms I use may be different (or defined differently) than what you use in your organization. I would love to get your perspective on how Agile Planning can be done. After all, I'm always on the lookout for better, more Agile ways to do things!</div>
Anonymoushttp://www.blogger.com/profile/07829612743920787477noreply@blogger.com0tag:blogger.com,1999:blog-8737362623239996105.post-6817641641855653272014-03-21T13:13:00.002-06:002014-03-21T13:13:53.125-06:00Agile Documentation<table cellpadding="0" cellspacing="0" class="tr-caption-container" style="float: right; text-align: center;"><tbody>
<tr><td style="text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjHJITM7jwC6J_zFNf33plu-5Nt54Hf2BguiOHiqS9Zxo0blubUuKB6vwXl1wfr6vlc2o6Ya_y0dQOulIIRKq2JOcbzEs8qB8wGFDwzhV0fcl5_cQ4ccTjMP2FfgVkxbJJJe1Q2P7wJLDQ/s1600/dilbert_agile_programming.gif" imageanchor="1" style="margin-left: auto; margin-right: auto;"><img border="0" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjHJITM7jwC6J_zFNf33plu-5Nt54Hf2BguiOHiqS9Zxo0blubUuKB6vwXl1wfr6vlc2o6Ya_y0dQOulIIRKq2JOcbzEs8qB8wGFDwzhV0fcl5_cQ4ccTjMP2FfgVkxbJJJe1Q2P7wJLDQ/s1600/dilbert_agile_programming.gif" width="80%" /></a></td></tr>
<tr><td class="tr-caption" style="text-align: center;">And this, class, is what we call BLASPHEMIES!!!</td></tr>
</tbody></table>
One of the most common myths I get to dispel as an Agile Coach is that Agile teams don't document. After all, they value Working Software, not Comprehensive Documentation. I have to remind them that the Manifesto states "over" instead of "not", and that true Agilists still see the value in documentation inasmuch as it enhances the working software being developed. These conversations have helped me refine my message over time to the four questions I believe should be asked before documentation is produced.<br />
<br />
<span style="font-size: large;"><b>Who are you documenting for?</b></span><br />
<table cellpadding="0" cellspacing="0" class="tr-caption-container" style="float: left; margin-right: 1em; text-align: left;"><tbody>
<tr><td style="text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiZQAq8Nnt6zpuonIur64Gvrp1Qg0A4Kh_8C6lrsYySF9n34Irc6CZU-a0ulAtuS9f3iof2Yg4R7xLJpaui8QQf3R4Sl5IbVT7V8XK32F4QDEMaJTzJEjM6Y7Xp-lBklN0Er7ZNQWvbW0g/s1600/write-only.png" imageanchor="1" style="clear: left; margin-bottom: 1em; margin-left: auto; margin-right: auto;"><img border="0" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiZQAq8Nnt6zpuonIur64Gvrp1Qg0A4Kh_8C6lrsYySF9n34Irc6CZU-a0ulAtuS9f3iof2Yg4R7xLJpaui8QQf3R4Sl5IbVT7V8XK32F4QDEMaJTzJEjM6Y7Xp-lBklN0Er7ZNQWvbW0g/s1600/write-only.png" height="56" width="320" /></a></td></tr>
<tr><td class="tr-caption" style="text-align: center;">Set permissions to 'write-only'</td></tr>
</tbody></table>
Who is going to read this document that you're going to write? <a href="http://deanleffingwell.com/" target="_blank">Dean Leffingwell</a> once told me that Agile means avoiding "write-only" documentation. If it's not going to be read, why write it?<br />
<br />
Understanding your audience also impacts how you write your documentation. Speak to the level and with the verbiage which which your consumer is most comfortable. This is similar logic to why we include the user in the standard User Story format.<br />
<br />
<span style="font-size: large;"><b>How will you communicate your documentation?</b></span><br />
Documentation is not one-size-fits-all. There are hundreds of ways to document, from wikis to man files to interactive wizards. What format are you going to use to publish your documentation?<br />
<br />
Another interpretation of this is where will you put the documentation for your consumers to pull? Most documentation is living, not static, so mediums like email are usually very bad. Do you have a team site, knowledge repository, or some other digital location that your consumers can bookmark to find the latest and greatest? Is the location easy to find and "on the main path", or do they have to dig for it? Make your life easy by making your documentation easy to consume.<br />
<br />
<span style="font-size: large;"><b>What will be done with your documentation?</b></span><br />
This is more a corollary for the first two questions. For example, you may think you know who you're documenting for, but what if all they do is file the information away and never look at it? Your audience may not be who you think it is - indeed, your audience may not exist at all.<br />
<br />
As for the second question, building a README file to document your smartphone game won't be useful, regardless of how well you know your customer or how accessible you make said file - an in-game tutorial will be much better received.<br />
<br />
Bottom line: don't start documenting until you know what your consumers' intended purpose is for the documentation.<br />
<br />
<span style="font-size: large;"><b>Can it be automated?</b></span><br />
The first three questions speak more to the elimination or simplification of the documentation you produce. By the time you get to this question, you've determined that the documentation is necessary for your end-user, future maintenance team, or whomever to do what they need with your software. So can this documentation be automated?<br />
<br />
Documentation for future development and maintenance is often quite simple to automate. You can use certain comment formatting to generate Javadoc or Sandcastle documentation for Java and .NET applications, respectively. You can use tools to generate your class and sequence diagrams as part of each build. There are several forms of technical documentation that can almost always be automated.<br />
<br />
User-facing automation is trickier, but not impossible. For instance, you could generate LaTeX templates that are plugged in with data that's auto-fed to it and output documentation in the format that works best for your users. Get creative with it and see what you can come up with.<br />
<br />
<span style="font-size: large;"><b>Questions?</b></span><br />
Those are the questions I've developed over time; what are yours? How do you determine what to document and how? Do you find yourself documenting more or less using Agile than Waterfall? How has the nature of documentation changed? I'd love to learn from your experiences.Anonymoushttp://www.blogger.com/profile/07829612743920787477noreply@blogger.com0tag:blogger.com,1999:blog-8737362623239996105.post-85216427609633080602014-03-19T14:27:00.000-06:002014-03-19T15:04:01.288-06:00Introspective: Trying new thingsThis week my Introspective turned my thoughts towards trying new things. In that spirit, I've <a href="http://www.linkedin.com/today/post/article/20140319202441-19267203-introspective-trying-new-things" target="_blank">published this week's Introspective on LinkedIn</a>. Let me know if you like it better, worse, or are indifferent.<br />
<div>
<br /></div>
<div>
<a href="http://www.linkedin.com/today/post/article/20140319202441-19267203-introspective-trying-new-things">http://www.linkedin.com/today/post/article/20140319202441-19267203-introspective-trying-new-things</a></div>
Anonymoushttp://www.blogger.com/profile/07829612743920787477noreply@blogger.com0