Everyone's Blog Posts - Agile Philly2024-03-29T13:47:29Zhttp://agilephilly.ning.com/profiles/blog/feed?xn_auth=noSPaMCAST 630 – It’s All About the People, A Panel Discussion with Laberge, Parente, Voris, Sweeney, and Cagleytag:agilephilly.ning.com,2020-12-24:3783271:BlogPost:10308952020-12-24T16:36:34.000ZJohn Voris, Lead Coordinatorhttp://agilephilly.ning.com/profile/JohnVoris
<h2 class="post-title">SPaMCAST 630 – It’s All About the People, A Panel Discussion with Laberge, Parente, Voris, Sweeney, and Tom Cagley</h2>
<p></p>
<p>In March 2020, as our world was shrinking and words like ‘lockdown’ and ‘zoom-bombing’ were becoming a reality, we recorded and aired in <a href="https://bit.ly/2VX7tTu">SPaMCAST 597</a> </p>
<p></p>
<p><strong>Paul Laberge, Susan Parente, Jo Ann Sweeney, John Voris, and Tom Cagley</strong> returned to talk about how we could create or…</p>
<h2 class="post-title">SPaMCAST 630 – It’s All About the People, A Panel Discussion with Laberge, Parente, Voris, Sweeney, and Tom Cagley</h2>
<p></p>
<p>In March 2020, as our world was shrinking and words like ‘lockdown’ and ‘zoom-bombing’ were becoming a reality, we recorded and aired in <a href="https://bit.ly/2VX7tTu">SPaMCAST 597</a> </p>
<p></p>
<p><strong>Paul Laberge, Susan Parente, Jo Ann Sweeney, John Voris, and Tom Cagley</strong> returned to talk about how we could create or preserve interactions leading to serendipity.</p>
<p>Remote working was new for many people. This week we discuss what went well and what have we learned from nearly a year of working remotely.</p>
<p></p>
<p>Tom Cagley as the editor of SPaMCAST reconvened the group to gather insights we need about People Skills. The discussion is full of great ideas to improve remote and hybrid working environments, but most of all it is full of ideas to help respect people in tough times or not.</p>
<p></p>
<p><span style="font-size: 14pt;"><strong>Go to the SPAMCAST webpage to see the Bios of the Panel</strong></span></p>
<p><span style="font-size: 14pt;"><strong>and to hear the Podcast</strong></span></p>
<p></p>
<p><a href="https://tcagley.wordpress.com/2020/12/21/spamcast-630-its-all-about-the-people-a-panel-discussion-with-laberge-parente-voris-sweeney-and-cagley" target="_blank" rel="noopener">https://tcagley.wordpress.com/2020/12/21/spamcast-630-its-all-about-the-people-a-panel-discussion-with-laberge-parente-voris-sweeney-and-cagley</a> </p>
<p></p>
<p></p>SPaMCAST 597 – Intentional Serendipity, A Panel Discussiontag:agilephilly.ning.com,2020-12-24:3783271:BlogPost:10309712020-12-24T16:28:52.000ZJohn Voris, Lead Coordinatorhttp://agilephilly.ning.com/profile/JohnVoris
<p></p>
<p><strong>SPaMCAST 597 – Intentional Serendipity, A Panel Discussion</strong><br></br> <strong>with Laberge, Parente, Voris, Sweeney, and Cagley</strong><br></br> URL :…<br></br></p>
<p></p>
<p><strong>SPaMCAST 597 – Intentional Serendipity, A Panel Discussion</strong><br/> <strong>with Laberge, Parente, Voris, Sweeney, and Cagley</strong><br/> URL :<br/> <a href="https://tcagley.wordpress.com/2020/04/26/spamcast-597-intentional-serendipity-a-panel-discussion-with-laberge-parente-voris-sweeney-and-cagley/" target="_blank"">https://tcagley.wordpress.com/2020/04/26/spamcast-597-intentional-serendipity-a-panel-discussion-with-laberge-parente-voris-sweeney-and-cagley/</a><br/> Posted : April 26, 2020 at 9:10 pm<br/> Author : tcagley Tom Cagley)<br/> Tags : Agile, Remote, Teams<br/> Categories : Agile</p>
<p><span style="font-size: 14pt;">The panel is composed of Paul Laberge, Susan Parente, John Voris, Jo Ann Sweeney, and the host Tom Cagley.</span></p>
<p><br/> <a href="https://tcagley.files.wordpress.com/2019/02/spamcast-1400dpi.jpg" target="_blank"">https://tcagley.files.wordpress.com/2019/02/spamcast-1400dpi.jpg</a><br/> <a href="http://www.spamcast.net" target="_blank"">http://www.spamcast.net</a><br/> <br/> Play Now! ( <a href="https://bit.ly/2VX7tTu" target="_blank"">https://bit.ly/2VX7tTu</a> )<br/> Subscribe: Apple Podcast (<br/> <a href="https://itunes.apple.com/us/podcast/software-process-measurement/id213024387?mt=2" target="_blank"">https://itunes.apple.com/us/podcast/software-process-measurement/id213024387?mt=2</a><br/> )<br/> Check out the podcast on Google Play Music (<br/> <a href="https://goo.gl/app/playmusic?ibi=com.google.PlayMusic&isi=691797987&ius=googleplaymusic&link=">https://goo.gl/app/playmusic?ibi=com.google.PlayMusic&isi=691797987&ius=googleplaymusic&link=</a><a href="https://play.google.com/music/m/Iivswiy4ppyulme7pbsaidbodpm?t%3DSoftware_Process_and_Measurement_Cast" target="_blank"">https://play.google.com/music/m/Iivswiy4ppyulme7pbsaidbodpm?t%3DSoftware_Process_and_Measurement_Cast</a><br/> )<br/> <br/> The SPaMCAST 597 features a <strong>special panel of leaders</strong> discussing working<br/> from home now and after the initial reaction to being remote has worn<br/> off.</p>
<p><strong>One of the important points that we discussed was the need to make</strong><br/> <strong>space for intentional serendipity.</strong></p>
<p>The panel is composed of Paul Laberge, Susan Parente, John Voris, Jo Ann Sweeney, and the host Tom Cagley.<br/> <br/> <em><strong>Panelist Bios</strong></em><br/> <br/> Jo Ann Sweeney FCIM FIIC MCIPR is an engagement and communication<br/> consultant. Typically, she acts as change management lead on complex<br/> programmes, facilitating development of effective engagement, training,<br/> and communication strategies and then assisting as the strategies are<br/> implemented.<br/> <br/> Clients value her deep understanding of audiences. Jo Ann is known for<br/> clarifying the complex and for persuading key stakeholders to get<br/> involved and actively support change.<br/> <br/> You are welcome to download a complimentary copy of Jo Ann’s guide How<br/> to Explain Change in 8 Easy Steps at<br/> <a href="https://freeguide.explaining-change.com/" target="_blank"">https://freeguide.explaining-change.com/</a> (<br/> <a href="https://freeguide.explaining-change.com/" target="_blank"">https://freeguide.explaining-change.com/</a> )<br/> <br/> Contact Jo Ann at jo.ann@sweeneycomms.com<br/> <br/> John Voris is the current leader of AgilePhilly, the local user group in<br/> the Philadelphia area for Scrum, Kanban, and Lean Software.<br/> (<a href="http://www.AgilePhilly.com">www.AgilePhilly.com</a> ( <a href="http://www.agilephilly.com" target="_blank"">http://www.agilephilly.com</a> ) ) His day job is<br/> working on financial applications for Crown Cork & Seal, an essential<br/> company with over 100 years of manufacturing food and beverage cans. <br/> Prior to Crown, John was an independent software consultant for 30+<br/> years helping both small companies and Fortune 100 large companies with<br/> both applications and operating systems.<br/> <br/>  <br/> <br/> Reach out on LinkedIn: linkedin.com/in/john-voris-7b20525 (<br/> <a href="https://www.linkedin.com/in/john-voris-7b20525" target="_blank"">https://www.linkedin.com/in/john-voris-7b20525</a> )<br/> <br/>  <br/> <br/> With more than 30 years in the information technology industry, Paul<br/> Laberge – CGI Director Consulting-Expert, has a wide range of<br/> experience providing IT project management. He enjoys coaching leaders<br/> in deploying business technology solutions. His experience in<br/> organizational change management spans many different lifecycles<br/> including transitions to Agile frameworks (RUP, XP, Scrum, SAFe, Nexxus,<br/> LeSS) and incorporating Lean (Kanban) methodologies.<br/> <br/> Reach out on LinkedIn: linkedin.com/in/paullaberge (<br/> <a href="https://www.linkedin.com/in/paullaberge" target="_blank"">https://www.linkedin.com/in/paullaberge</a> )<br/> <br/> Susan Parente is a Principal Consultant at S3 Technologies, LLC and a<br/> University Professor at multiple Universities. Mrs. Parente is an<br/> author, mentor and professor focused on risk management, traditional and<br/> Agile project management. Her experience is augmented by her Masters in<br/> Engineering Management with a focus in Marketing of Technology from<br/> George Washington University, DC, along with a number of professional<br/> certifications. Ms. Parente has 23+ years’ experience leading software<br/> and business development projects in the private and public sectors,<br/> including a decade of experience implementing IT projects for the DoD.<br/> <br/> Contact Susan at parente.s3@gmail.com<br/> <br/> Re-Read Saturday News <br/> <br/> This week we tackle Chapter 9 of Crucial Conversations: Tools for Talking<br/> When Stakes Are High, Second Edition by Patterson, Grenny, McMillan,<br/> Switzler ( <a href="https://amzn.to/34RuZ6V" target="_blank"">https://amzn.to/34RuZ6V</a> ) . The subtitle of this chapter is a<br/> fair summary of the ideas in the chapter: how to turn crucial<br/> conversations into action and results. Let’s face it if you don’t do<br/> anything with what you learn in a crucial conversation you are wasting a<br/> lot of value.<br/> <br/> Week 1 - Logistics, Forewards, and Preface ( <a href="http://bit.ly/2wls1Mq" target="_blank"">http://bit.ly/2wls1Mq</a> ) -<br/> <a href="http://bit.ly/2wls1Mq">http://bit.ly/2wls1Mq</a> ( <a href="http://bit.ly/2wls1Mq" target="_blank"">http://bit.ly/2wls1Mq</a> )  <br/> <br/> Week 2 - Chapter 1: What’s a crucial conversation? And who cares? (<br/> <a href="http://bit.ly/3a7Kivp">http://bit.ly/3a7Kivp</a> ) - <a href="http://bit.ly/3a7Kivp">http://bit.ly/3a7Kivp</a> ( <a href="http://bit.ly/3a7Kivp" target="_blank"">http://bit.ly/3a7Kivp</a><br/> )  <br/> <br/> Week 3 – Chapter 2: The Power of Dialogue ( <a href="http://bit.ly/3aO4cMa" target="_blank"">http://bit.ly/3aO4cMa</a> )<br/> – <a href="http://bit.ly/3aO4cMa">http://bit.ly/3aO4cMa</a> ( <a href="http://bit.ly/3aO4cMa" target="_blank"">http://bit.ly/3aO4cMa</a> )   <br/> <br/> Week 4 - Chapter 3: Start With Heart ( <a href="http://bit.ly/2UbJizK" target="_blank"">http://bit.ly/2UbJizK</a> ) -<br/> <a href="http://bit.ly/2UbJizK">http://bit.ly/2UbJizK</a> ( <a href="http://bit.ly/2UbJizK" target="_blank"">http://bit.ly/2UbJizK</a> )  <br/> <br/> Week 5 - Learn To Look ( <a href="https://bit.ly/3djnnPX" target="_blank"">https://bit.ly/3djnnPX</a> ) -<br/> <a href="https://bit.ly/3djnnPX">https://bit.ly/3djnnPX</a> ( <a href="https://bit.ly/3djnnPX" target="_blank"">https://bit.ly/3djnnPX</a> )<br/> <br/> Week 6 - Make It Safe ( <a href="https://bit.ly/39p4Xu4" target="_blank"">https://bit.ly/39p4Xu4</a> ) -<br/> <a href="https://bit.ly/39p4Xu4">https://bit.ly/39p4Xu4</a> ( <a href="https://bit.ly/39p4Xu4" target="_blank"">https://bit.ly/39p4Xu4</a> )  <br/> <br/> Week 7 - Master my Stories ( <a href="https://bit.ly/2V1DJUZ" target="_blank"">https://bit.ly/2V1DJUZ</a> ) -<br/> <a href="https://bit.ly/2V1DJUZ">https://bit.ly/2V1DJUZ</a> ( <a href="https://bit.ly/2V1DJUZ" target="_blank"">https://bit.ly/2V1DJUZ</a> )  <br/> <br/> Week 8 - State My Path ( <a href="https://bit.ly/2XtqTSr" target="_blank"">https://bit.ly/2XtqTSr</a> ) -<br/> <a href="https://bit.ly/2XtqTSr">https://bit.ly/2XtqTSr</a> ( <a href="https://bit.ly/2XtqTSr" target="_blank"">https://bit.ly/2XtqTSr</a> )  <br/> <br/> Week 9 - Explore Others’ Paths ( <a href="https://bit.ly/2ViOGD5" target="_blank"">https://bit.ly/2ViOGD5</a> ) -<br/> <a href="https://bit.ly/2ViOGD5">https://bit.ly/2ViOGD5</a> ( <a href="https://bit.ly/2ViOGD5" target="_blank"">https://bit.ly/2ViOGD5</a> )  <br/> <br/> Week 10 - Move to Action ( <a href="https://bit.ly/2y1ddUb" target="_blank"">https://bit.ly/2y1ddUb</a> ) -<br/> <a href="https://bit.ly/2y1ddUb">https://bit.ly/2y1ddUb</a> ( <a href="https://bit.ly/2y1ddUb" target="_blank"">https://bit.ly/2y1ddUb</a> )  <br/> <br/> We are starting the poll for the next book in the re-read series. Crucial<br/> Conversations has two more chapters and an afterword left which means we<br/> have approximately three weeks to choose what we will read next. I am<br/> going to try something a little different this time by focusing on books<br/> I’ve read in late 2019 early 2020 and that I carry around with me when<br/> I am working. One exception is the inclusion of the runner up from our<br/> last poll.<br/> <br/> Poll – let me know what you’d like to revisit next!<br/> <br/> View Poll ( <a href="http://polldaddy.com/poll/10543339/" target="_blank"">http://polldaddy.com/poll/10543339/</a> )<br/> <br/> If you do not have a copy or have tossed it at someone during a crucial<br/> conversation, it is time to buy a copy. Please use the link<br/> <a href="https://amzn.to/34RuZ6V">https://amzn.to/34RuZ6V</a> ( <a href="https://amzn.to/34RuZ6V" target="_blank"">https://amzn.to/34RuZ6V</a> ) (using the link<br/> helps support the blog and podcast).<br/> <br/> Next SPaMCAST<br/> <br/> SPaMCAST 598 will feature our essay titled Recognizing A Toxic Meeting<br/> Culture. Just because you are meeting remotely doesn’t mean meeting<br/> culture has been reset.  <br/> <br/> We will also return to the QA Corner with Jeremy Berriault.<br/> <br/>  <br/> <br/> Add a comment to this post:<br/> <a href="https://tcagley.wordpress.com/2020/04/26/spamcast-597-intentional-serendipity-a-panel-discussion-with-laberge-parente-voris-sweeney-and-cagley/#respond" target="_blank"">https://tcagley.wordpress.com/2020/04/26/spamcast-597-intentional-serendipity-a-panel-discussion-with-laberge-parente-voris-sweeney-and-cagley/#respond</a><br/></p>The Neglected Product Owner Roletag:agilephilly.ning.com,2020-08-07:3783271:BlogPost:9639612020-08-07T01:17:54.000ZDuane Kenneyhttp://agilephilly.ning.com/profile/DuaneKenney
<p>While working with Agile transformations, I’ve been noticing as I’m sure most of you have as well, the focus on development teams shifting to some form of Agile delivery, in most cases Scrum. And with this focus, the Scrum Master typically is part of this early shift, however, the Product Owner role seems to be an afterthought, as is the Business in whole.</p>
<p></p>
<p>Why do organizations start from the delivery side, and try to bring the business along at a later time? Is it because it…</p>
<p>While working with Agile transformations, I’ve been noticing as I’m sure most of you have as well, the focus on development teams shifting to some form of Agile delivery, in most cases Scrum. And with this focus, the Scrum Master typically is part of this early shift, however, the Product Owner role seems to be an afterthought, as is the Business in whole.</p>
<p></p>
<p>Why do organizations start from the delivery side, and try to bring the business along at a later time? Is it because it seems easier to re-align delivery teams? Is there less friction, therefore the path of least resistance for this type of re-organization?</p>
<p></p>
<p>Typically, when true Product Ownership is introduced, the business finds they need to re-organize themselves to allow the dedication of the Product Owner, possibly re-defining their products, org chart hierarchy shifts, etc. Is this effort what puts them on the back burner in the early stages of transformation? Get the quick wins and come back to the more difficult part later?</p>
<p></p>
<p>Whatever the reason is, it seems to always make the transformation more difficult by leaving a critical role to the latter part of the journey. This role always seems to be playing catch up, causing more friction as they try to acclimate to what the delivery team has already grown accustomed to. I can’t see how you increase your chances of success when you start with such a disconnect between roles that are so critical to be aligned.</p>
<p></p>
<p>What are some of your thoughts or observations when it comes to the development of the Product Owner role in transformations you’ve been a part of?</p>What ever happened to Shu?tag:agilephilly.ning.com,2020-07-13:3783271:BlogPost:9378392020-07-13T00:34:47.000ZDuane Kenneyhttp://agilephilly.ning.com/profile/DuaneKenney
<p>I find it curious when organizations that want to take on significant change with an Agile Transformation, immediately start to look at what they can change about the chosen framework before the ink is dry on the decision to change.</p>
<p>The conversation typically follows a similar path each time, “I’ve heard Agile can make us (<em>better/faster/insert improvement here</em>), so we want to learn how to do it, but…here’s how we want to do it here because (<em>insert any ‘we are different’…</em></p>
<p>I find it curious when organizations that want to take on significant change with an Agile Transformation, immediately start to look at what they can change about the chosen framework before the ink is dry on the decision to change.</p>
<p>The conversation typically follows a similar path each time, “I’ve heard Agile can make us (<em>better/faster/insert improvement here</em>), so we want to learn how to do it, but…here’s how we want to do it here because (<em>insert any ‘we are different’ excuse here</em>).</p>
<p>Already the organization has determined they know more than they do, and have a plan to execute it in a manner that suits their needs. And yet they have not taken the first step to learning prior to changing.</p>
<p>I recently came across a great article about<span> </span><em>Shu Ha Ri</em><span> </span>that made me think about how much we disregard it. I’ve been familiar with the concept, it’s a standard topic in any Agile training as a way to describe the phases of mastery. As a coach, it’s not only applicable to my learning journey, and recognition of where I am, but it’s also my responsibility to help those that I am coaching understand where they are, and more importantly, where they are not.</p>
<p>This is the summary of<span> </span><em>Shu Ha Ri</em><span> </span>taken from the article:</p>
<ul>
<li class="ql-align-justify"><strong>Shu</strong> (守), <em>“protect”</em>, <em>“follow the rule”</em>: in this phase the practitioner applies every method, approach or rule that the teacher provides. The rule is followed to the letter. This is where it’s important to follow every detail, even if it seems unimportant, and not deviate from the teachings. This is the phase when a new discipline, approach or technique is learned in its intimacy, step by step. The rules are also repeated over and over in order to assimilate them. This is important not because a specific path is better than the other, but because following a single path till the end is the most efficient way to learn.</li>
</ul>
<p class="ql-align-justify"></p>
<ul>
<li class="ql-align-justify"><strong>Ha</strong> (破), <em>“cut”</em>, <em>“break the rule”</em>: the practitioner has now reached a level where all the rules are well known and it’s possible to break them when necessary. The practitioner is also able to teach other learners, discuss the topic and improve the discipline itself. This is when the rules are questioned, the reason of their existence is put into the spotlight and the foundation becomes visible from the high point of the <em>Shu</em> studies.</li>
</ul>
<p class="ql-align-justify"></p>
<ul>
<li class="ql-align-justify"><strong>Ri</strong> (離), <em>“depart”</em>, <em>“be the rule”</em>: the practitioner now doesn’t just follow the rule, methods and approaches: the practitioner is the rule, transcends the rule. The concepts are so well assimilated that are second nature, and they can be even completely abandoned if the goal requires it. The practitioner is extending the discipline.</li>
</ul>
<p>How many of us enable the organizations we are here to help, feel empowered to jump past<span> </span><em>Shu</em><span> </span>before they are ready? They have not mastered the muscle memory of ‘wax on/wax off’ before they want to jump into creating their own framework. We sometimes fall into the trap of trying to please our employers or clients, and allow this slippage into an area they are not ready for, and we risk setting them up for failure.</p>
<p>When we ask them to follow the framework as it is to start, we are called ‘fanatics’ and that we need to be more flexible, to not follow the framework so rigidly. We are asked to ‘adapt’ the principles and processes of the framework to their ‘very unique situation’.</p>
<p>While there will be adaptation to their needs, that comes later in the process. Truthfully if there was no adaptation and evolution, we would not be able to claim success. But there needs to be ‘patience Daniel-san, first learn to stand, then learn to fly.’</p>
<p>There will be time for Ri, to depart from the rule, but for now, let’s try to understand the rule and why it is there, and what it is meant to teach us, before we determine we don’t need it.</p>
<p>Trust me to protect and guide you as you have asked me to.</p>
<p></p>
<p><a href="https://www.straightscrum.com/blog/What-ever-happened-to-Shu">https://www.straightscrum.com/blog/What-ever-happened-to-Shu</a></p>Response to article "Applying Agile in a Mixed Feature Development and SLA-Bound Bug-Fixing Team"tag:agilephilly.ning.com,2018-03-11:3783271:BlogPost:675512018-03-11T13:29:37.000ZJohn H. McHughhttp://agilephilly.ning.com/profile/JohnHMcHugh
<p>What is your experience dealing with product maintenance while managing development in a Sprint? This article was posted on the Scrum Alliance website.…</p>
<p>What is your experience dealing with product maintenance while managing development in a Sprint? This article was posted on the Scrum Alliance website.</p>
<h1 style="background-color: transparent; color: #000000; font-family: Georgia,Palatino,&quot; palatino linotype&quot;,times,&quot;times new roman&quot;,serif; font-size: 26px; font-style: normal; font-variant: normal; font-weight: bold; letter-spacing: normal; margin-bottom: 13px; orphans: 2; text-align: left; text-decoration: none; text-indent: 0px; text-transform: none; -webkit-text-stroke-width: 0px; white-space: normal; word-spacing: 0px;">Applying Agile in a Mixed-Feature Development and SLA-Bound Bug-Fixing Team</h1>
<p style="background-color: transparent; color: #000000; font-family: Georgia,Palatino,&quot; palatino linotype&quot;,times,&quot;times new roman&quot;,serif; font-size: 13px; font-style: normal; font-variant: normal; font-weight: 400; letter-spacing: normal; orphans: 2; text-align: left; text-decoration: none; text-indent: 0px; text-transform: none; -webkit-text-stroke-width: 0px; white-space: normal; word-spacing: 0px; margin: 0px;"><a style="cursor: auto; outline-color: transparent; outline-style: none; outline-width: 0px;" href="https://www.scrumalliance.org/community/articles/2012/may/applying-agile-in-a-mixed-feature-development-and">https://www.scrumalliance.org/community/articles/2012/may/applying-agile-in-a-mixed-feature-development-and</a></p>
<p style="background-color: transparent; color: #000000; font-family: Georgia,Palatino,&quot; palatino linotype&quot;,times,&quot;times new roman&quot;,serif; font-size: 13px; font-style: normal; font-variant: normal; font-weight: 400; letter-spacing: normal; orphans: 2; text-align: left; text-decoration: none; text-indent: 0px; text-transform: none; -webkit-text-stroke-width: 0px; white-space: normal; word-spacing: 0px; margin: 0px;"></p>
<p style="margin: 0px;"><span style="margin: 0px;"><span style="background: white; margin: 0px; color: #999999; font-family: 'Helvetica',sans-serif; font-size: 10.5pt;">05/21/2012 by Albert Arul Prakash Rajendran</span></span></p>
<p style="background: white; margin: 0in 0in 7.5pt 0in;"><em><span style="margin: 0px; color: #333333; font-family: 'Helvetica',sans-serif; font-size: 10.5pt;">Note: This article is based on a Scrum Alliance Google groups thread called "</span></em><a href="http://groups.google.com/group/scrumalliance/browse_thread/thread/6d9ee0cac375f46"><i><span style="margin: 0px; color: #ff6319; font-family: 'Helvetica',sans-serif; font-size: 10.5pt;">How to apply scrum in a mixed feature development and SLA-bou[n]d bug fixing team</span></i></a><em><span style="margin: 0px; color: #333333; font-family: 'Helvetica',sans-serif; font-size: 10.5pt;">." I have compiled most of the solutions that were provided in the thread. Not all parts of the article are my contributions.</span></em></p>
<p style="background: white; margin: 0in 0in 7.5pt 0in;"><span style="margin: 0px; color: #333333; font-family: 'Helvetica',sans-serif; font-size: 10.5pt;">In most software development organizations today, there is no dedicated sustaining engineering (SE) team to take care of post-release maintenance and support. The engineering (R&D) team doubles up to complete SE tasks in addition to feature development. However, support service-level agreements (SLAs) with maintenance-paying customers are usually rigid, so SE often takes higher priority than R&D. Engineering teams that follow Scrum then fail to deliver committed features due to the high influx of SE issues and the need for their speedy resolution. Juggling between feature development and bug fixes also adversely affects team morale and motivation levels.</span></p>
<p style="background: white; margin: 0in 0in 7.5pt 0in;"><span style="margin: 0px; color: #333333; font-family: 'Helvetica',sans-serif; font-size: 10.5pt;">The following Scrum-based options were suggested by group members to overcome the problem in such situations.</span></p>
<p style="background: white; margin: 0in 0in 7.5pt 0in;"><span style="margin: 0px; color: #333333; font-family: 'Helvetica',sans-serif; font-size: 10.5pt;"> </span></p>
<p style="background: white; margin: 0in 0in 7.5pt 0in;"><strong><span style="margin: 0px; color: #333333; font-family: 'Helvetica',sans-serif; font-size: 10.5pt;">Dedicating members for SE in every sprint</span></strong></p>
<p style="background: white; margin: 0in 0in 7.5pt 0in;"><span style="margin: 0px; color: #333333; font-family: 'Helvetica',sans-serif; font-size: 10.5pt;">Using this option, one or two team members per sprint are dedicated to SE issues in a round-robin fashion. This eliminates the need to juggle tasks, and the team retains its morale and motivation. As all team members take turns working on SE tasks, they get insights into code quality, recurring development issues, and the cost/effort to fix issues post-release. Over time, this can result in a natural improvement in code quality.</span></p>
<p style="background: white; margin: 0in 0in 7.5pt 0in;"><span style="margin: 0px; color: #333333; font-family: 'Helvetica',sans-serif; font-size: 10.5pt;">Furthermore, since the capacity of only the remaining members is considered for feature development, this method ensures that sprint commitments are largely met. In case of low SE influx, the SE-dedicated members can fix other internal bugs and thus raise the overall product quality.</span></p>
<p style="background: white; margin: 0in 0in 7.5pt 0in;"><span style="margin: 0px; color: #333333; font-family: 'Helvetica',sans-serif; font-size: 10.5pt;"> </span></p>
<p style="background: white; margin: 0in 0in 7.5pt 0in;"><strong><span style="margin: 0px; color: #333333; font-family: 'Helvetica',sans-serif; font-size: 10.5pt;">Kanban</span></strong></p>
<p style="background: white; margin: 0in 0in 7.5pt 0in;"><span style="margin: 0px; color: #333333; font-family: 'Helvetica',sans-serif; font-size: 10.5pt;">The team prioritizes all SE tasks and takes them up in order of priority. Using Kanban minimizes the work-in-progress items, because each member is allowed to work on only one task at a time. This model does pose certain challenges with respect to accurately forecasting the product release cycle, but it also significantly improves product quality.</span></p>
<p style="background: white; margin: 0in 0in 7.5pt 0in;"><span style="margin: 0px; color: #333333; font-family: 'Helvetica',sans-serif; font-size: 10.5pt;"> </span></p>
<p style="background: white; margin: 0in 0in 7.5pt 0in;"><strong><span style="margin: 0px; color: #333333; font-family: 'Helvetica',sans-serif; font-size: 10.5pt;">Shorter sprint</span></strong></p>
<p style="background: white; margin: 0in 0in 7.5pt 0in;"><span style="margin: 0px; color: #333333; font-family: 'Helvetica',sans-serif; font-size: 10.5pt;">The sprint duration is reduced to one week, and bugs are prioritized each week. The success of this approach depends on SLA expectations.</span></p>
<p style="background: white; margin: 0in 0in 7.5pt 0in;"><span style="margin: 0px; color: #333333; font-family: 'Helvetica',sans-serif; font-size: 10.5pt;"> </span></p>
<p style="background: white; margin: 0in 0in 7.5pt 0in;"><strong><span style="margin: 0px; color: #333333; font-family: 'Helvetica',sans-serif; font-size: 10.5pt;">Divide and conquer</span></strong></p>
<p style="background: white; margin: 0in 0in 7.5pt 0in;"><span style="margin: 0px; color: #333333; font-family: 'Helvetica',sans-serif; font-size: 10.5pt;">The team velocity is distributed evenly between R&D and SE. The team works with two simultaneous product backlogs, one for feature development and the other for SE tasks or tickets.</span></p>
<p style="background: white; margin: 0in 0in 7.5pt 0in;"><span style="margin: 0px; color: #333333; font-family: 'Helvetica',sans-serif; font-size: 10.5pt;">SE tickets, along with their SLA goals, are brought into the Scrum ceremonies in a similar manner as development stories. For example, there may be a story to improve response times to meet SLA. During sprint reviews, the team studies ticket metrics to determine if SLAs were achieved. The team has ITIL (information technology infrastructure library) built in as part of its definition of done and as part of its Scrum board. A scheduled task is created as a reusable story and goes through the Scrum process.</span></p>
<p style="background: white; margin: 0in 0in 7.5pt 0in;"><span style="margin: 0px; color: #333333; font-family: 'Helvetica',sans-serif; font-size: 10.5pt;">There needs to be some flexibility here to change goals during the sprint if required, in case there's a major incident mid-sprint. But if capacity is well allocated between plan-driven work and incident-driven work, reprioritization is rare.</span></p>
<p style="background: white; margin: 0in 0in 7.5pt 0in;"><strong><span style="margin: 0px; color: #333333; font-family: 'Helvetica',sans-serif; font-size: 10.5pt;">Single-day sprint</span></strong></p>
<p style="background: white; margin: 0in 0in 7.5pt 0in;"><span style="margin: 0px; color: #333333; font-family: 'Helvetica',sans-serif; font-size: 10.5pt;">This is a new approach to resolve the problem when SLAs are extremely stringent and none of the other approaches are viable. A single-day sprint is one that starts in the morning and ends that evening and includes all the standard components, such as sprint planning, velocity calculation, and review. However, the sprint retrospective may take a backseat or may be done on an on-demand basis.</span></p>
<p style="background: white; margin: 0in 0in 7.5pt 0in;"><span style="margin: 0px; color: #333333; font-family: 'Helvetica',sans-serif; font-size: 10.5pt;">The single-day sprint model looks like this:</span></p>
<ul type="disc">
<li style="background: white; margin: 0px; color: #333333; font-family: 'Times New Roman',serif; font-size: 12pt; font-style: normal; font-weight: normal;"><span style="margin: 0px; font-family: 'Helvetica',sans-serif; font-size: 10.5pt;">1st minute of the day: Product owner provides a list of tickets that need fixes, plus pending features.</span></li>
<li style="background: white; margin: 0px; color: #333333; font-family: 'Times New Roman',serif; font-size: 12pt; font-style: normal; font-weight: normal;"><span style="margin: 0px; font-family: 'Helvetica',sans-serif; font-size: 10.5pt;">20th minute: Team holds a sprint planning session and commits to tickets and features for the day.</span></li>
<li style="background: white; margin: 0px; color: #333333; font-family: 'Times New Roman',serif; font-size: 12pt; font-style: normal; font-weight: normal;"><span style="margin: 0px; font-family: 'Helvetica',sans-serif; font-size: 10.5pt;">4th hour of the day: Team provides a small update (e.g., "Fixed this ticket and ready to go live") to others in an informal way.</span></li>
<li style="background: white; margin: 0px; color: #333333; font-family: 'Times New Roman',serif; font-size: 12pt; font-style: normal; font-weight: normal;"><span style="margin: 0px; font-family: 'Helvetica',sans-serif; font-size: 10.5pt;">7.5th hour: Team winds down committed tasks for the day.</span></li>
<li style="background: white; margin: 0px; color: #333333; font-family: 'Times New Roman',serif; font-size: 12pt; font-style: normal; font-weight: normal;"><span style="margin: 0px; font-family: 'Helvetica',sans-serif; font-size: 10.5pt;">8th hour: Team moves the day's work to a staging machine and demonstrates all fixes done for the day, then ends the sprint.</span></li>
</ul>
<p style="background: white; margin: 0in 0in 7.5pt 0in;"><span style="margin: 0px; color: #333333; font-family: 'Helvetica',sans-serif; font-size: 10.5pt;">This way the complete turnaround for a ticket is one day and the team is inside the framework.</span></p>
<p style="background: white; margin: 0in 0in 7.5pt 0in;"><strong><span style="margin: 0px; color: #333333; font-family: 'Helvetica',sans-serif; font-size: 10.5pt;">Hardening sprint</span></strong></p>
<p style="background: white; margin: 0in 0in 7.5pt 0in;"><span style="margin: 0px; color: #333333; font-family: 'Helvetica',sans-serif; font-size: 10.5pt;">If the team continues to be overburdened with a high influx of SE issues, it's time to talk to management about the possibility of running a couple of hardening sprints to fix existing issues. If run properly, improved product quality will result in a significant potential cost saving. A hardening project focuses exclusively on fixing issues. No new features are developed. This reduces the number of issues and the team gets some breathing space.</span></p>
<p style="background: white; margin: 0in 0in 7.5pt 0in;"><strong><span style="margin: 0px; color: #333333; font-family: 'Helvetica',sans-serif; font-size: 10.5pt;">Conclusion</span></strong></p>
<p style="background: white; margin: 0in 0in 7.5pt 0in;"><span style="margin: 0px; color: #333333; font-family: 'Helvetica',sans-serif; font-size: 10.5pt;">In addition to all the approaches listed above, investing in the following areas will lead to better results over time:</span></p>
<ul type="disc">
<li style="background: white; margin: 0px; color: #333333; font-family: 'Times New Roman',serif; font-size: 12pt; font-style: normal; font-weight: normal;"><span style="margin: 0px; font-family: 'Helvetica',sans-serif; font-size: 10.5pt;">Understanding the root cause of maintenance issues</span></li>
<li style="background: white; margin: 0px; color: #333333; font-family: 'Times New Roman',serif; font-size: 12pt; font-style: normal; font-weight: normal;"><span style="margin: 0px; font-family: 'Helvetica',sans-serif; font-size: 10.5pt;">Automating your testing</span></li>
<li style="background: white; margin: 0px; color: #333333; font-family: 'Times New Roman',serif; font-size: 12pt; font-style: normal; font-weight: normal;"><span style="margin: 0px; font-family: 'Helvetica',sans-serif; font-size: 10.5pt;">Code refactoring and maintainability</span></li>
</ul>
<p style="background: white; margin: 0in 0in 7.5pt 0in;"><span style="margin: 0px; color: #333333; font-family: 'Helvetica',sans-serif; font-size: 10.5pt;">Group discussion brought up all these possible solutions, and there are likely other innovative ideas out there. If your team found some, let's hear about them. Meanwhile, all the best!</span></p>
<p style="background: white; margin: 0in 0in 7.5pt 0in;"></p>
<p> </p>
<p style="margin: 0px;"></p>
<p></p>Slides from "Are Fixed Price Agile Contracts possible?" AgilePhilly 2/20/18tag:agilephilly.ning.com,2018-02-21:3783271:BlogPost:675242018-02-21T14:00:00.000ZMichael Harrishttp://agilephilly.ning.com/profile/MichaelHarris
<p><a href="http://storage.ning.com/topology/rest/1.0/file/get/1561425944?profile=original" target="_self">Are%20Fixed%20Price%20Contracts%20Possible%20With%20Agile%20-%20Agile%20Philly%20Feb%2020%202018%20Final.pdf</a></p>
<p><a href="http://storage.ning.com/topology/rest/1.0/file/get/1561425944?profile=original" target="_self">Are%20Fixed%20Price%20Contracts%20Possible%20With%20Agile%20-%20Agile%20Philly%20Feb%2020%202018%20Final.pdf</a></p>One Free ticket to Philly ETE Conferencetag:agilephilly.ning.com,2016-11-30:3783271:BlogPost:600202016-11-30T20:30:00.000ZJohn Voris, Lead Coordinatorhttp://agilephilly.ning.com/profile/JohnVoris
<p></p>
<p></p>
<p><span class="font-size-5">We need a Slogan for our Stickers.</span></p>
<p><span class="font-size-5">Enter the contest, and</span></p>
<p><span class="font-size-5">Win a ticket to Philly ETE Conference.</span></p>
<p></p>
<p></p>
<p><span class="font-size-5"><a href="http://www.agilephilly.com/page/one-free-ticket-to-philly-ete-conference">one-free-ticket-to-philly-ete-conference</a></span></p>
<p></p>
<p></p>
<p><span class="font-size-5">We need a Slogan for our Stickers.</span></p>
<p><span class="font-size-5">Enter the contest, and</span></p>
<p><span class="font-size-5">Win a ticket to Philly ETE Conference.</span></p>
<p></p>
<p></p>
<p><span class="font-size-5"><a href="http://www.agilephilly.com/page/one-free-ticket-to-philly-ete-conference">one-free-ticket-to-philly-ete-conference</a></span></p>We are working on an SDT Conference coming in Junetag:agilephilly.ning.com,2015-04-12:3783271:BlogPost:502002015-04-12T15:00:00.000ZJohn Voris, Lead Coordinatorhttp://agilephilly.ning.com/profile/JohnVoris
<p>There is suddenly talk of a SD&T conference in Philly or Washington area. Narish Jain (one of the founders of AgilePhilly) started these in the Philly area 5 to 7 years ago, and runs them in India where he now permanently lives.</p>
<p></p>
<p>( SD&T is Simple Design and Test Conference. Done in a true Open Space Conference style, it usually went both Saturday and Sunday. </p>
<p>If I remember right, at one of the conferences, one thing that made it different = The price of…</p>
<p>There is suddenly talk of a SD&T conference in Philly or Washington area. Narish Jain (one of the founders of AgilePhilly) started these in the Philly area 5 to 7 years ago, and runs them in India where he now permanently lives.</p>
<p></p>
<p>( SD&T is Simple Design and Test Conference. Done in a true Open Space Conference style, it usually went both Saturday and Sunday. </p>
<p>If I remember right, at one of the conferences, one thing that made it different = The price of admission was that you had to be ready to present on SOMETHING , and put it on a stickie – even if it was just a 5 minute lightning talk. The various choices we then had to vote on were so varied and so amazing ! )</p>
<p> </p>
<p>Narish is coming to the states from June 10-24, we would love to "welcome him home" by having one here in Philly or in the Washington area.</p>
<p>Narish also has given some entertaining and thoughtful presentations at conferences, that make you laugh as well as think.</p>
<p>You will find his card decks throughout the internet.</p>
<p></p>
<p>To follow the conversation on when it will happen ,</p>
<p> <a href="http://groups.google.com/group/sdtconf/t/e091e1e857604c2f" target="_blank"">http://groups.google.com/group/sdtconf/t/e091e1e857604c2f</a></p>Selling Agile Contracts Slides from Agile Philly 1/2 Day Event 10/6/2014tag:agilephilly.ning.com,2014-10-12:3783271:BlogPost:475162014-10-12T02:30:00.000ZPaul Eisenberghttp://agilephilly.ning.com/profile/PaulEisenberg
<p>Hi All.</p>
<p>Noticed that the Dropbox link to my preso in the mail John circulated was broken so...</p>
<p>I renamed the preso to remove spaces, posted the thing on slide share, and create a tiny URL so you can get to it easy!</p>
<p></p>
<p>Enjoy: <a href="http://tinyurl.com/agile-contracts">http://tinyurl.com/agile-contracts</a></p>
<p></p>
<p>I really enjoyed sharing this with the group. Please do not hesitate to contact me if you have questions or just want to discuss. I am definitely…</p>
<p>Hi All.</p>
<p>Noticed that the Dropbox link to my preso in the mail John circulated was broken so...</p>
<p>I renamed the preso to remove spaces, posted the thing on slide share, and create a tiny URL so you can get to it easy!</p>
<p></p>
<p>Enjoy: <a href="http://tinyurl.com/agile-contracts">http://tinyurl.com/agile-contracts</a></p>
<p></p>
<p>I really enjoyed sharing this with the group. Please do not hesitate to contact me if you have questions or just want to discuss. I am definitely learning more about this topic everyday!</p>
<p>Regards,</p>
<p>Paul</p>Dan Mezick's slides from Nov 20th 2013 ( 35 Meg download as PDF )tag:agilephilly.ning.com,2013-12-18:3783271:BlogPost:377652013-12-18T01:30:00.000ZJohn Voris, Lead Coordinatorhttp://agilephilly.ning.com/profile/JohnVoris
<p>We finally have the slides from AgilePhilly's November 20th 2013 meeting.</p>
<p>Dan Mezick's slides -</p>
<p>Topic was Open Agile Adoption</p>
<p>Format is in PDF format</p>
<p><a href="https://www.dropbox.com/s/t1l0hn3kuymm31a/OpenAgileAdoption4Q2013.pdf">https://www.dropbox.com/s/t1l0hn3kuymm31a/OpenAgileAdoption4Q2013.pdf</a></p>
<p> </p>
<p> </p>
<p>We finally have the slides from AgilePhilly's November 20th 2013 meeting.</p>
<p>Dan Mezick's slides -</p>
<p>Topic was Open Agile Adoption</p>
<p>Format is in PDF format</p>
<p><a href="https://www.dropbox.com/s/t1l0hn3kuymm31a/OpenAgileAdoption4Q2013.pdf">https://www.dropbox.com/s/t1l0hn3kuymm31a/OpenAgileAdoption4Q2013.pdf</a></p>
<p> </p>
<p> </p>Pics from the AgileTour 2013 (October 7th 2013)tag:agilephilly.ning.com,2013-11-25:3783271:BlogPost:367892013-11-25T15:30:00.000ZJohn Voris, Lead Coordinatorhttp://agilephilly.ning.com/profile/JohnVoris
<p>I know I put the link up for the AgileTour 2013 pictures, but heck if I can find it.</p>
<p>So I thought I would shove the Dropbox link up here on the Blog Post pages.</p>
<p>If we have any other materials ( like the BIG files that don't fit anywhere) - - Dropbox appears to be the way to go.</p>
<p>(Yes we have still have the <a href="http://www.yahoogroups.com/group/AgilePhilly">http://www.YahooGroups.com/group/AgilePhilly</a> website that can handle photos and more, but for the big files…</p>
<p>I know I put the link up for the AgileTour 2013 pictures, but heck if I can find it.</p>
<p>So I thought I would shove the Dropbox link up here on the Blog Post pages.</p>
<p>If we have any other materials ( like the BIG files that don't fit anywhere) - - Dropbox appears to be the way to go.</p>
<p>(Yes we have still have the <a href="http://www.yahoogroups.com/group/AgilePhilly">http://www.YahooGroups.com/group/AgilePhilly</a> website that can handle photos and more, but for the big files or big collections of files - - - Dropbox it.</p>
<p><a href="https://www.dropbox.com/sh/hkpbmllzmjla4g0/VW7zakpJSk">https://www.dropbox.com/sh/hkpbmllzmjla4g0/VW7zakpJSk</a></p>
<p> </p>
<p>If you like Snapfish, the pics are up there too. <a class="bitmark-shortlink" href="http://bit.ly/1eki3Xu"><span class="protocol">http://</span>bit.ly/1eki3Xu</a> </p>
<p> </p>
<p> </p>Some Free and Cheap eBooks on Behavior Driven Developmenttag:agilephilly.ning.com,2013-06-10:3783271:BlogPost:295552013-06-10T15:27:09.000ZJohn Voris, Lead Coordinatorhttp://agilephilly.ning.com/profile/JohnVoris
<p>(1)</p>
<p>A free eBook in pre-release on Acceptance Testing, and comments are being collected. You can use the voucher code 91YmqbaAzuEu all of this month to download a free copy.<br></br><br></br>Go to the book’s blog page at <a href="http://baddotrobot.com/book">http://baddotrobot.com/book</a> for more info or use the voucher directly on the Leanpub book page to download …</p>
<p>(1)</p>
<p>A free eBook in pre-release on Acceptance Testing, and comments are being collected. You can use the voucher code 91YmqbaAzuEu all of this month to download a free copy.<br/><br/>Go to the book’s blog page at <a href="http://baddotrobot.com/book">http://baddotrobot.com/book</a> for more info or use the voucher directly on the Leanpub book page to download <a href="https://leanpub.com/essential_acceptance_testing">https://leanpub.com/essential_acceptance_testing</a><br/><br/>(2)</p>
<p>And on the Technical Topic of Testing, here are some free eBooks on Testing. <a href="http://www.ministryoftesting.com/resources/ebooks/">http://www.ministryoftesting.com/resources/ebooks/</a></p>
<p> </p>
<p>(3) 50 % off a Manning Book on BDD</p>
<p><strong>Save 50%</strong> on <a href="http://r20.rs6.net/tn.jsp?e=0012TK11yu063t_wtrfwKBoyflrPSkxzsGc39WrXLWQp0hSh0kduAJH20Y7kQBGZRXvoN-IlbKbrU5pnMZ0Zy6jQFy6TPVyZplQBOVCB4nJs2F5Q2IoG3GRXu8kHni-FF_A" target="_blank">BDD in Action</a> and these other selected books. Just enter <strong>bddlaunch50</strong> in the Promotional Code box when you check out. Expires Thursday, June 13. Only at <a href="http://r20.rs6.net/tn.jsp?e=0012TK11yu063sMKFqRfFQAXqmLzx5sItFRWVl589zXPHl1KnLMql879hvulxr1CYUXfbEBhqsHcYtnYXgbgXBbLdR9QgJv9r4YHkw5DFsrBmuGhrWq0HHI4Q==" target="_blank">manning.com</a>.</p>
<p> </p>
<p>Go there just for the free Intro chapter</p>
<p> </p>
<p> </p>CULTUREcon Recaptag:agilephilly.ning.com,2012-09-26:3783271:BlogPost:267352012-09-26T14:30:00.000ZD. André Dhondthttp://agilephilly.ning.com/profile/DAndreDhondt
<p>Have you blogged about #CULTUREcon? Reply in the comments with a link! More chronicles at <a href="http://dhondtsayitsagile.blogspot.com" target="_blank">André's blog</a> and at <a href="http://www.facebook.com/l/AAQG3kARs/www.freestandingagility.com/resources/the-culture-conversation/" target="_blank">FreeStandingAgility</a> .</p>
<p><a href="http://storage.ning.com/topology/rest/1.0/file/get/1561425649?profile=original" target="_self"><img class="align-left" src="http://storage.ning.com/topology/rest/1.0/file/get/1561425649?profile=original" width="275"></img></a> Thanks to …</p>
<p>Have you blogged about #CULTUREcon? Reply in the comments with a link! More chronicles at <a href="http://dhondtsayitsagile.blogspot.com" target="_blank">André's blog</a> and at <a href="http://www.facebook.com/l/AAQG3kARs/www.freestandingagility.com/resources/the-culture-conversation/" target="_blank">FreeStandingAgility</a> .</p>
<p><a target="_self" href="http://storage.ning.com/topology/rest/1.0/file/get/1561425649?profile=original"><img class="align-left" src="http://storage.ning.com/topology/rest/1.0/file/get/1561425649?profile=original" width="275"/></a>Thanks to <a href="http://hhgttg.de/blog/" target="_blank">Olaf Lewitz</a> for the photos!</p>
<p>Here's what conference organizer and Agile Philly Maggie Churchville captured:</p>
<p></p>
<div><p><strong>Dan Mezick- How To Game Your Meetings<a target="_self" href="http://storage.ning.com/topology/rest/1.0/file/get/1561428571?profile=original"><img class="align-right" src="http://storage.ning.com/topology/rest/1.0/file/get/1561428571?profile=original" width="275"/></a></strong></p>
<p>A game is a group activity with clear goals, clear rules, a way to track progress and voluntary players; Daniel Mezick, author of The Culture Game: Tools For The Agile Manager (<a href="http://newtechusa.net" target="_blank">newtechusa.net</a>), demonstrated how to structure any meeting by these parameters. He started the 20-minute talk by saying, “It’s mandatory that I be here but you’re here by choice, you may leave at any time. Our goal is to learn about applying game mechanics to meetings, and we’ll be here for 20 minutes.” During that time, Dan used an easel as a scoreboard, moving sticky notes with his talking points from a ToDo column to a Doing column and finally to a Done column as a way to give progress information to the listener. Dan’s premise is that we need a sense of control and progress to feel happy; if you put a game layer over any meeting you build in clearer goals and identifiable progress to help your “teammates” stay involved.</p>
<p>Games and happiness are related. Control, progress, belonging to a team and working on a large project that you can’t do alone, these are the things that make people happy at work. Meetings can be fun again by stating a clear objective, or goal for the meeting. Then, lay out a few rules, for instance, how long you will take, when to offer feedback, or the timetable for discussion, do these rules apply to everyone. Provide a way to show progress throughout the meeting, and let your teammates know that they may leave at any time. </p>
<p>When individuals are free to decide whether to join any social opportunity they bring a motivation and eagerness that is absent under traditional, mandatory events. To get people to come to your meetings, Dan suggested sending a series or invitations, structuring your space so that people can mingle, and even offering the choice of short courses to earn a badge, knowing that we feed off symbols and signs.</p>
<p>Explicitly structuring your meetings provides a working agreement that teammates buy into. As participants, we know what we are giving up and what we are getting from the meeting; we’re all in, we’re building a little culture, we’re situating ourselves in the same story, we are having strong and satisfying interactions, and we are happy. Meetings don’t have to suck.</p>
<p> </p>
<p><strong>Eric Raymond, Culture Hacking The Open-Source Movement<a target="_self" href="http://storage.ning.com/topology/rest/1.0/file/get/1561428693?profile=original"><img class="align-left" src="http://storage.ning.com/topology/rest/1.0/file/get/1561428693?profile=original" width="275"/></a></strong></p>
<p>Cultures are defined by the language, jokes and myths they share. By editing the “jargon file” you shape the culture. Be aware of what “language maps” show about a given culture. For instance, jokes are extremely important because they subtly define what a culture values and fears; they reveal emotional substructure.</p>
<p>Technology in any form is enabled by stories because narratives are social ways connecting technology to people. The causality never stops. Strong conversation around product creation maximizes the numbers of iterations. Decentralized and open peer review creates a better product. Re-branding and dropping ideological packaging influences the adoption of technology.</p>
<p> </p>
<p>Culture influencers find a concept central to the culture and find the right label; they create something useful. Ultimately, what counts as success in culture hacking? When people begin using the names, places and stories you establish. Culture hacking stands or falls on its own success but in the end, you can only engineer a culture in a direction that it wants to go anyway.</p>
<p></p>
<p><strong>Bob Gower, Agile coach w/ rally software. Kicking The Habit</strong></p>
<p>Much of what people do is habit, autopilot. If we change our habits we allow more bandwidth to be freed up for creativity.</p>
<p>To change a habit, understand what it does for you. Find deep gratitude that the habit gave you something you needed. Realize you can have this something fulfilled by other means. These are things in your control; make them a keystone habit. Habits have a trigger and a reward. The trigger is what starts the habit in action and the reward is the end result fromthe habit. Changing a habit is a matter of Inserting a new habit in between the trigger and the reward.</p>
<p>In business, they also have habits that they want to change, but they must understand the benefit cycle, or, the trigger and rewards. What habits should a business change? Where should we intervene in a business? In complex businesses all things impact all other things. Pay attention to what the individuals at the company have agreed to to be part of something important. They feel part of and cared for by company. What are the keystone habits that hold your group together. Retrospect a very regular basis, Release your product often, measure people engagement.</p>
<p>The prologue to change is that you have to hit bottom. But we get to choose where our bottom is. The best thing an organization can do is hit bottom, make your troubles visible. You can begin to change your habits to rebuild the organization. Read <a href="http://charlesduhigg.com/the-power-of-habit/">Charles Duhigg, The Power Of Habit</a>.</p>
<p><b> </b></p>
<p><strong>Michael Margolis, Get Storied. The Power Of Cultural Storytelling</strong></p>
<p>Culture and storytelling. What is our role as individuals in culture hacking /change. “When a culture is in trouble, it calls back the outsiders.” We are the outsiders/mavericks. The experience of being rejected/opt out of culture qualifies us, once we stop stumbling in the dark. The circle is at the heart of culture hacking. Culture is about boundary-setting, a line of what’s in /out, possible/ impossible, acceptable/unacceptable. Get in touch with the shadow of the cultural dynamic. We each see something different, frustrating to articulate it and try to get others to see what we see. We want to create new culture where we fit in, yet we are steeped in the stories of old culture and not fitting in.</p>
<p><br/> “Jump Start Story Telling” why am I so emotionally invested in this work? What’s the riddle I’m trying to solve? We all want to feel loving acceptance, by working together with people on something meaningful. We learn to appreciate the uniqueness of others when the connection is more important than the product.</p>
<p>We are hardwired to find ourselves in others…if you are permitted to get close to someone. Story telling reveals the invisible lines of connection, and allows other people to locate themselves inside the story. Build a big story where there is more room for people to locate themselves. Story of self (motivation), story of tribe (collective motivation), universal story that transcends (the thing that everybody wants.)</p>
<p>Before you can help others, you have to examine and understand your own story. You’ve been on a journey and now can help people- not from a place of obligation or virtue for helping, but from a place of humility and empathy because we walked the path.</p>
</div>
<p></p>
<p><a target="_self" href="http://storage.ning.com/topology/rest/1.0/file/get/1561428745?profile=original"><img class="align-center" src="http://storage.ning.com/topology/rest/1.0/file/get/1561428745?profile=original" width="275"/></a></p>Nominations for Philly ETE's Project of the Yeartag:agilephilly.ning.com,2012-02-08:3783271:BlogPost:237372012-02-08T21:40:29.000ZD. André Dhondthttp://agilephilly.ning.com/profile/DAndreDhondt
<div>Chariot Solutions and Technically Philly are sponsoring the first annual Philly ETE Project of the Year Award.</div>
<div>We want to spotlight great software made in the Philadelphia region! We're looking for the coolest, most innovative software developed in 2011 in the Philadelphia region. We want to celebrate the art of software development and how it makes a difference in how organizations can thrive and grow.</div>
<div>The award will be given out in the afternoon of the first day on…</div>
<div>Chariot Solutions and Technically Philly are sponsoring the first annual Philly ETE Project of the Year Award.</div>
<div>We want to spotlight great software made in the Philadelphia region! We're looking for the coolest, most innovative software developed in 2011 in the Philadelphia region. We want to celebrate the art of software development and how it makes a difference in how organizations can thrive and grow.</div>
<div>The award will be given out in the afternoon of the first day on ETE, April 10th. The criteria and nomination form are located here: <a href="http://phillyemergingtech.com/2012/award" target="_blank">http://phillyemergingtech.com/2012/award</a></div>
<p>Nominate your company or send it along to an organization you think deserves to be recognized. It can be a specific team within a company or an entire firm. Help us help celebrate Philadelphia's software developers.</p>Agile Teams - Chili Cook Off Contesttag:agilephilly.ning.com,2012-01-27:3783271:BlogPost:235132012-01-27T20:16:51.000ZRobert Shawhttp://agilephilly.ning.com/profile/RobertShaw
<div><p>It's winter here in PA and nothing goes better with lousy weather than a bowl of chili. </p>
<p>We have a very competitive group and we do not need much motivation to turn anything into a compitition. </p>
<p>One week prior to cooking day we gathered all the teams and unveiled the event and rules. The feedback from teams and tasters was that it was a rousing team building success..</p>
<p>One team took it as far as to execute a prototype and feedback session every morning to dial in…</p>
</div>
<div><p>It's winter here in PA and nothing goes better with lousy weather than a bowl of chili. </p>
<p>We have a very competitive group and we do not need much motivation to turn anything into a compitition. </p>
<p>One week prior to cooking day we gathered all the teams and unveiled the event and rules. The feedback from teams and tasters was that it was a rousing team building success..</p>
<p>One team took it as far as to execute a prototype and feedback session every morning to dial in their recipe. This is also the team that won. </p>
<p></p>
<p>The slides are attached..</p>
<p><a href="http://storage.ning.com/topology/rest/1.0/file/get/1561424943?profile=original" target="_self">1st%20Annual%20It%E2%80%99s%20Chilly%20Out.pptx</a></p>
</div>Microsoft Code Camp in Philly is now a truly Agile Conferencetag:agilephilly.ning.com,2011-08-30:3783271:BlogPost:147042011-08-30T15:19:07.000ZJohn Voris, Lead Coordinatorhttp://agilephilly.ning.com/profile/JohnVoris
<p> </p>
<p>The Microsoft Code Camp on Oct 15th will be having an Open Spaces Track. In my mind, that brings a lot of new people around to the idea of Open Spaces during conferences.</p>
<p> </p>
<p><strong>Open Spaces</strong> - Jess Chadwick - Room 105</p>
<p>An open discussion forum lasting the entire day. The format is deliberately fluid, with the general flow consisting of: participants shout out topics to discuss, vote on a topic, discuss it for 10 minutes (or more... or less), and then…</p>
<p> </p>
<p>The Microsoft Code Camp on Oct 15th will be having an Open Spaces Track. In my mind, that brings a lot of new people around to the idea of Open Spaces during conferences.</p>
<p> </p>
<p><strong>Open Spaces</strong> - Jess Chadwick - Room 105</p>
<p>An open discussion forum lasting the entire day. The format is deliberately fluid, with the general flow consisting of: participants shout out topics to discuss, vote on a topic, discuss it for 10 minutes (or more... or less), and then pick a new topic. Rinse and repeat for an entire day of lively and intriguing group conversation!</p>
<p> </p>
<p>And do not forget the Philly Alt Net group, led by our own Brian Donahue, moving the discussion forward for Agile Practices in the dot Net world. </p>
<p><strong>alt.NET -</strong> <a href="http://codecamp.phillydotnet.org/2011-2/Lists/Track/DispForm.aspx?ID=22">Brian Donahue</a> - Room 141</p>
<p> </p>
<p><a href="http://phillydotnet20111015.eventbrite.com/">http://phillydotnet20111015.eventbrite.com/</a> Saturday Oct 15th</p>
<p> </p>Agile Coding - a truism about good codingtag:agilephilly.ning.com,2011-03-07:3783271:BlogPost:73022011-03-07T04:16:30.000ZJohn Vorishttp://agilephilly.ning.com/profile/JohnVoris589
<p>Naresh Jain, one of our original founders, has a great quote via a Corey Hains Code Retreat. It is a truism about agile coding:</p>
<p> </p>
<p>"write thrice, erase twice, release once, work small."</p>
<p>Naresh Jain, one of our original founders, has a great quote via a Corey Hains Code Retreat. It is a truism about agile coding:</p>
<p> </p>
<p>"write thrice, erase twice, release once, work small."</p>Free talks by our previous speakerstag:agilephilly.ning.com,2011-01-21:3783271:BlogPost:55822011-01-21T16:16:46.000ZJohn Voris, Lead Coordinatorhttp://agilephilly.ning.com/profile/JohnVoris
<p>Free Talks by Mary Poppendieck & Gojko Adzic among others<br></br>are listed in the <strong>lower right hand corner</strong> of <a href="http://skillsmatter.com/go/home">http://skillsmatter.com/go/home</a> </p>
<p>These were listed in the newsletter of Skills Matters. Times are London times.</p>
<p>======= Upcoming talks =======================-</p>
<p>Near as I can tell, their podcasts of recent talks listed in their newsletter is not condensed well on any page of their site. These…</p>
<p>Free Talks by Mary Poppendieck & Gojko Adzic among others<br/>are listed in the <strong>lower right hand corner</strong> of <a href="http://skillsmatter.com/go/home">http://skillsmatter.com/go/home</a> </p>
<p>These were listed in the newsletter of Skills Matters. Times are London times.</p>
<p>======= Upcoming talks =======================-</p>
<p>Near as I can tell, their podcasts of recent talks listed in their newsletter is not condensed well on any page of their site. These include:</p>
<p> </p>
<p>FREE TALK In The Brain of Simon Brown: Software Project SOS, Jan 27<br/>Talk: Software Project SOS<br/>Speaker: Simon Brown<br/>Date: January 27, 2011, 18:30-20:00</p>
<p>FREE TALK In The Brain of Gojko Adzic: Breaking the TDD Mould, Feb 3<br/>Talk: Breaking the TDD Mould<br/>Speaker: Gojko Adzic<br/>Date: February 3, 2011, 18:30-20:00</p>
<p>FREE TALK The Limited WIP Society: Kanban Clinic, Feb 7<br/>User Group: Limited WIP Society<br/>Talk: Kanban Clinic<br/>Speaker: John Stevenson<br/>Date: February 7, 2011, 18:30-20:00</p>
<p>FREE TALK In The Brain of Russ Miles: Getting Architecturally Agile with Event Driven Architectures, Feb 10<br/>Talk: Getting Architecturally Agile with Event Driven Architectures<br/>Speaker: Russ Miles<br/>Date: February 10, 2011, 18:30-20:00</p>
<p>FREE TALK In The Brain of Linda Rising: Who do You Trust? Beware of Your Brain, Feb 14<br/>Talk: Who do You Trust? Beware of Your Brain<br/>Speaker: Linda Rising<br/>Date: February 14, 2011, 18:30-20:00</p>
<p>FREE TALK In The Brain of Steve Freeman, Feb 22<br/>Talk: To be decided<br/>Speaker: Steve Freeman<br/>Date: February 22, 2011, 18:30-20:00</p>
<p>FREE TALK Agile Testing UK: The (Rocky) Road to Agile at the Walt Disney Company, Feb 23<br/>Talk: The (Rocky) Road to Agile at the Walt Disney Company<br/>Speaker: Richard Glew<br/>Date: February 23, 2011, 18:30-20:00</p>
<p>FREE TALK In The Brain of John Stevenson: Kanban vs. the Mafia, Feb 28<br/>Talk: Kanban vs. the Mafia<br/>Speaker: John Stevenson<br/>Date: February 28, 2011, 18:30-20:00</p>
<p>FREE TALK In The Brain of David Laribee, Mar 17<br/>Talk: To be decided<br/>Speaker: David Laribee<br/>Date: March 17, 2011, 18:30-20:00</p>
<p>FREE TALK In The Brain of Alan Shalloway: Applying Lean Software Development Principles Throughout the Organization, Mar 22<br/>Talk: Applying Lean Software Development Principles Throughout the Organization<br/>Speaker: Alan Shalloway<br/>Date: March 22, 2011, 18:30-20:00</p>
<p>FREE TALK In The Brain of Jurgen Appelo: The Big-Ass View on Competence, Mar 30<br/>Talk: The Big-Ass View on Competence<br/>Speaker: Jurgen Appelo<br/>Date: March 30, 2011, 18:30-20:00</p>
<p>FREE TALK In The Brain of Jutta Eckstein: Typical Pitfalls in Agile Software Development, May 18<br/>Talk: Typical Pitfalls in Agile Software Development<br/>Speaker: Jutta Eckstein<br/>Date: May 18, 2011, 18:30-20:00</p>
<p>FREE TALK In The Brain of Mary Poppendieck: A Tale of Two Terminals, May 24<br/>Talk: A Tale of Two Terminals<br/>Speaker: Mary Poppendieck<br/>Date: May 24, 2011, 18:30-20:00</p>
<p> </p>
<p>-============== Prior Talks ==============-</p>
<p><br/><a href="http://skillsmatter.com/podcast/agile-scrum/making-management-work-with-agile/zx-1334">http://skillsmatter.com/podcast/agile-scrum/making-management-work-with-agile/zx-1334</a> Making Management Work with Agile (Patrick Kua)<br/> <a href="http://skillsmatter.com/podcast/agile-scrum/keynote-deliberate-discovery-code-like-you-mean-it/zx-1334">http://skillsmatter.com/podcast/agile-scrum/keynote-deliberate-discovery-code-like-you-mean-it/zx-1334</a> <br/>Deliberate Discovery: Code Like You Mean It (Dan North)</p>
<p><a href="http://skillsmatter.com/podcast/agile-scrum/bdd-atdd-and-page-objects/zx-1334">http://skillsmatter.com/podcast/agile-scrum/bdd-atdd-and-page-objects/zx-1334</a><br/>BDD, ATDD and Page Objects (John Smart)<br/> <br/><a href="http://skillsmatter.com/podcast/agile-scrum/winning-big-with-specification-by-example-lessons-learned-from-50-successful-projects/zx-1334">http://skillsmatter.com/podcast/agile-scrum/winning-big-with-specification-by-example-lessons-learned-from-50-successful-projects/zx-1334</a><br/>Winning Big with Specification by Example (Gojko Adzic</span)</p>
<p><a href="http://skillsmatter.com/podcast/agile-scrum/cucumber-from-the-horses-mouth/zx-1334">http://skillsmatter.com/podcast/agile-scrum/cucumber-from-the-horses-mouth/zx-1334</a></p>
<p>Cucumber from Horse's Mouth (Aslak Hellesøy)</p>
<p><a href="http://skillsmatter.com/podcast/agile-scrum/agile-business-analysis-with-feature-injection-1554/zx-1334">http://skillsmatter.com/podcast/agile-scrum/agile-business-analysis-with-feature-injection-1554/zx-1334</a><br/>Agile Business Analysis with Feature Injection (Andy Palmer, Antony Marcano)<br/> <a href="http://skillsmatter.com/podcast/agile-scrum/objective-agility-what-does-it-take-to-be-an-agile-company/zx-1334">http://skillsmatter.com/podcast/agile-scrum/objective-agility-what-does-it-take-to-be-an-agile-company/zx-1334</a><br/>What Does It Take to be an Agile Company (Allan Kelly)</p>
<p><a href="http://skillsmatter.com/podcast/agile-scrum/using-agile-methods-to-become-competent/zx-1334">http://skillsmatter.com/podcast/agile-scrum/using-agile-methods-to-become-competent/zx-1334</a><br/>Using Agile Methods to Become Competent (David Laribee)</p>
<p><a href="http://skillsmatter.com/podcast/agile-scrum/test-driven-data-warehouse-development/zx-1334">http://skillsmatter.com/podcast/agile-scrum/test-driven-data-warehouse-development/zx-1334</a> <br/>Test Driven Data Warehouse Development (Andy Barker)</p>
<p><a href="http://skillsmatter.com/podcast/agile-scrum/test-driving-at-high-speed-klarnas-agile-story/zx-1334">http://skillsmatter.com/podcast/agile-scrum/test-driving-at-high-speed-klarnas-agile-story/zx-1334</a><br/>Test-driving at High Speed: Klarna's Agile story (David Evans, Erik Stenman)<br/> <br/>href="<a href="http://skillsmatter.com/podcast/agile-scrum/agile-testing-at-trader-media/zx-1334">http://skillsmatter.com/podcast/agile-scrum/agile-testing-at-trader-media/zx-1334</a> <br/>Agile Testing at Trader Media (Stuart Taylor , Vivek)</p>
<p> <br/><a href="http://skillsmatter.com/podcast/agile-scrum/patterns-and-practices-of-building-gherkin-based-living-documentations/zx-1334">http://skillsmatter.com/podcast/agile-scrum/patterns-and-practices-of-building-gherkin-based-living-documentations/zx-1334</a> Patterns and Practices of Building Gherkin Based Living Documentations (Gaspar Nagy, Christian Hassa)</p>
<p><a href="http://skillsmatter.com/podcast/agile-scrum/successful-agile-teams/zx-1334">http://skillsmatter.com/podcast/agile-scrum/successful-agile-teams/zx-1334</a> <br/>Successful Agile Teams (Jan Machacek)<br/> <br/><a href="http://skillsmatter.com/podcast/agile-scrum/agile-retrospectives-part-i/zx-1334">http://skillsmatter.com/podcast/agile-scrum/agile-retrospectives-part-i/zx-1334</a> <br/>Learning from Experience with Retrospectives (Rachel Davies, Liz Sedley)</p>
<p><a href="http://skillsmatter.com/podcast/agile-scrum/enterprise-architecture-in-a-lean-enterprise/zx-1334">http://skillsmatter.com/podcast/agile-scrum/enterprise-architecture-in-a-lean-enterprise/zx-1334</a> Enterprise architecture in a Lean Enterprise (Erik Doernenburg)</p>
<p> </p>Building Trusttag:agilephilly.ning.com,2010-10-25:3783271:BlogPost:34102010-10-25T22:00:45.000ZRavindar Gujralhttp://agilephilly.ning.com/profile/RavindarGujral
<p style="margin-top: 0.7em; margin-right: 0px; margin-bottom: 2em; margin-left: 0px;"><span class="Apple-style-span" style="color: rgb(34, 34, 34); font-family: 'Lucida Grande', 'Lucida Sans Unicode', Verdana, sans-serif; font-size: 14px; line-height: 25px;">Building Trust as you work with a new team is crucial. To achieve a collaborative work environment, trust has to be built between all the involved parties be it team members or outside stakeholders. Trust helps teams function in a manner…</span></p>
<p style="margin-top: 0.7em; margin-right: 0px; margin-bottom: 2em; margin-left: 0px;"><span class="Apple-style-span" style="color: rgb(34, 34, 34); font-family: 'Lucida Grande', 'Lucida Sans Unicode', Verdana, sans-serif; font-size: 14px; line-height: 25px;">Building Trust as you work with a new team is crucial. To achieve a collaborative work environment, trust has to be built between all the involved parties be it team members or outside stakeholders. Trust helps teams function in a manner where they can help each other without fear.</span></p>
<p style="margin-top: 0.7em; margin-right: 0px; margin-bottom: 2em; margin-left: 0px;"><span class="Apple-style-span" style="color: rgb(34, 34, 34); font-family: 'Lucida Grande', 'Lucida Sans Unicode', Verdana, sans-serif; font-size: 14px; line-height: 25px;">Trust is all about letting go of human vulnerability. No one on a team wants to admit that they are wrong or they need help. You have to trust your team members and your management so that you can openly admit things you don’t know or understand. If building cross functional teams is important, having trust between team members is crucial to achieving cross functional teams. What you need to do is create a safe zone for the team members.</span></p>
<p style="margin-top: 0.7em; margin-right: 0px; margin-bottom: 2em; margin-left: 0px;"><span class="Apple-style-span" style="color: rgb(34, 34, 34); font-family: 'Lucida Grande', 'Lucida Sans Unicode', Verdana, sans-serif; font-size: 14px; line-height: 25px;"><strong>Reasons for lack of Trust</strong></span></p>
<p style="margin-top: 0.7em; margin-right: 0px; margin-bottom: 2em; margin-left: 0px;"><span class="Apple-style-span" style="color: rgb(34, 34, 34); font-family: 'Lucida Grande', 'Lucida Sans Unicode', Verdana, sans-serif; font-size: 14px; line-height: 25px;">There are many reasons for lack of trust on a team. Below is a small list of things I have seen in the past that contribute to lack of trust:</span></p>
<ul style="margin-top: 1.5em; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; padding-top: 0px; padding-right: 0px; padding-bottom: 0px; padding-left: 2.2em;">
<li><span class="Apple-style-span" style="color: rgb(34, 34, 34); font-family: 'Lucida Grande', 'Lucida Sans Unicode', Verdana, sans-serif; font-size: 14px; line-height: 25px;">Individualism (Selfishness leading to hidden agendas) and Lack of mutual respect</span></li>
<li><span class="Apple-style-span" style="color: rgb(34, 34, 34); font-family: 'Lucida Grande', 'Lucida Sans Unicode', Verdana, sans-serif; font-size: 14px; line-height: 25px;">Belief that teams become cohesive when they have an outside enemy, ex, Management is the root of all problems.</span></li>
<li><span class="Apple-style-span" style="color: rgb(34, 34, 34); font-family: 'Lucida Grande', 'Lucida Sans Unicode', Verdana, sans-serif; font-size: 14px; line-height: 25px;">Politics</span></li>
<li><span class="Apple-style-span" style="color: rgb(34, 34, 34); font-family: 'Lucida Grande', 'Lucida Sans Unicode', Verdana, sans-serif; font-size: 14px; line-height: 25px;">Defensive Behavior leading to jumping the gun and blaming others or being aggressive.</span></li>
<li><span class="Apple-style-span" style="color: rgb(34, 34, 34); font-family: 'Lucida Grande', 'Lucida Sans Unicode', Verdana, sans-serif; font-size: 14px; line-height: 25px;">Managers that are more into evaluating each individuals actions in a team than understand the reasons. This leads to Fear, fear to admit failure or lack of knowledge.</span></li>
<li><span class="Apple-style-span" style="color: rgb(34, 34, 34); font-family: 'Lucida Grande', 'Lucida Sans Unicode', Verdana, sans-serif; font-size: 14px; line-height: 25px;">Unhealthy competitions</span></li>
<li><span class="Apple-style-span" style="color: rgb(34, 34, 34); font-family: 'Lucida Grande', 'Lucida Sans Unicode', Verdana, sans-serif; font-size: 14px; line-height: 25px;">Constant team member changes or not having dedicated team members.</span></li>
<li><span class="Apple-style-span" style="color: rgb(34, 34, 34); font-family: 'Lucida Grande', 'Lucida Sans Unicode', Verdana, sans-serif; font-size: 14px; line-height: 25px;">Specialization leading to hiding information for the ensuring job security.</span></li>
<li><span class="Apple-style-span" style="color: rgb(34, 34, 34); font-family: 'Lucida Grande', 'Lucida Sans Unicode', Verdana, sans-serif; font-size: 14px; line-height: 25px;">A team leadership that has a know-it-all attitude and arrogance that goes with it.</span></li>
</ul>
<p style="margin-top: 0.7em; margin-right: 0px; margin-bottom: 2em; margin-left: 0px;"><span class="Apple-style-span" style="color: rgb(34, 34, 34); font-family: 'Lucida Grande', 'Lucida Sans Unicode', Verdana, sans-serif; font-size: 14px; line-height: 25px;">The above problems are, in no particular order, a small list of things you might notice on a team that can contribute to lack of trust. Although we understand that we have to collaborate to build software the issues list above can cause team members to retreat and thus not be part of a functioning team. One of the fundamental reasons leading to these kinds of behaviors is a lack of safety that team members perceive. I have been on teams where team members would confide to me that because of the volatile nature of things, they did not know how long they will have there jobs and so they were really careful in what they said, when they said it etc etc making them risk averse and defensive. This is an extreme case but shows what lack of safety can do. It is one thing to have incompetent team members and another when the management is constantly creating a culture of fear.</span></p>
<p style="margin-top: 0.7em; margin-right: 0px; margin-bottom: 2em; margin-left: 0px;"><span class="Apple-style-span" style="color: rgb(34, 34, 34); font-family: 'Lucida Grande', 'Lucida Sans Unicode', Verdana, sans-serif; font-size: 14px; line-height: 25px;"><strong>Things you can do</strong></span></p>
<p style="margin-top: 0.7em; margin-right: 0px; margin-bottom: 2em; margin-left: 0px;"><span class="Apple-style-span" style="color: rgb(34, 34, 34); font-family: 'Lucida Grande', 'Lucida Sans Unicode', Verdana, sans-serif; font-size: 14px; line-height: 25px;">Below are some things that I think can help elevate issues due to lack of trust.</span></p>
<ul style="margin-top: 1.5em; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; padding-top: 0px; padding-right: 0px; padding-bottom: 0px; padding-left: 2.2em;">
<li><span class="Apple-style-span" style="color: rgb(34, 34, 34); font-family: 'Lucida Grande', 'Lucida Sans Unicode', Verdana, sans-serif; font-size: 14px; line-height: 25px;">Ensure that you as a coach or team member voice your concerns about lack of safety. If you have a team coach all the better because chances are that he/she will understand what you are saying and will start interfacing with Management and other leadership within the organization to change the culture of fear.</span></li>
<li><span class="Apple-style-span" style="color: rgb(34, 34, 34); font-family: 'Lucida Grande', 'Lucida Sans Unicode', Verdana, sans-serif; font-size: 14px; line-height: 25px;">Creating a personal link is crucial to leading people through challenging times so ensure that team members build ties that involve a better understanding of each other. Maybe do exercises like Myers Briggs etc to help everyone in the team understand each other’s nature and behavior.</span></li>
<li><span class="Apple-style-span" style="color: rgb(34, 34, 34); font-family: 'Lucida Grande', 'Lucida Sans Unicode', Verdana, sans-serif; font-size: 14px; line-height: 25px;">Establish a common purpose removing personal gain from the equation. Support individuals within and outside team that will help you achieve a more collaborative environment.</span></li>
<li><span class="Apple-style-span" style="color: rgb(34, 34, 34); font-family: 'Lucida Grande', 'Lucida Sans Unicode', Verdana, sans-serif; font-size: 14px; line-height: 25px;">If safety has been an issue set goals in collaboration with the team. You have to let them know that they their view points are important.</span></li>
<li><span class="Apple-style-span" style="color: rgb(34, 34, 34); font-family: 'Lucida Grande', 'Lucida Sans Unicode', Verdana, sans-serif; font-size: 14px; line-height: 25px;">When making decisions start by soliciting everyones buy-in, genuine buy-in, that is not done using brute force but by looking at facts. If you use facts team members will have a way to defend there decisions. I know this can make things slower but in the longer run it will help overall cohesiveness of the team. Also this will help individuals to build mutual respect as now they have to convince each other regarding a particular decision. If decisions are being made in a collaborative way you can be assured of this behavior “<em>Since you also have the authority to decide, if you decide, you must at least follow your decision, and then this(decision) will not be forced upon you at all</em>” – Taiichi Ohno</span></li>
<li><span class="Apple-style-span" style="color: rgb(34, 34, 34); font-family: 'Lucida Grande', 'Lucida Sans Unicode', Verdana, sans-serif; font-size: 14px; line-height: 25px;">Have sessions where you help team members understand each other’s motives and what makes them tick. Deal with relationship issues within and outside team. Your attempt should be to create a cohesive unit not just within the team but with all the stakeholders.</span></li>
</ul>
<p style="margin-top: 0.7em; margin-right: 0px; margin-bottom: 2em; margin-left: 0px;"><span class="Apple-style-span" style="color: rgb(34, 34, 34); font-family: 'Lucida Grande', 'Lucida Sans Unicode', Verdana, sans-serif; font-size: 14px; line-height: 25px;">Trust is the key ingredient to achieving a well functioning cross functional team.</span></p>
<p style="margin-top: 0.7em; margin-right: 0px; margin-bottom: 2em; margin-left: 0px;"><span class="Apple-style-span" style="color: rgb(34, 34, 34); font-family: 'Lucida Grande', 'Lucida Sans Unicode', Verdana, sans-serif; font-size: 14px; line-height: 25px;">Cross Post from <a href="http://nostandardwork.com/2010/10/25/building-trust/">my Blog</a></span></p>Product Sashimi is delicious!tag:agilephilly.ning.com,2010-10-06:3783271:BlogPost:32882010-10-06T15:30:00.000ZAudrey R. Troutthttp://agilephilly.ning.com/profile/AudreyRTroutt
On October 2nd I participated in a <a href="http://productsashimi.com/">Product Sashimi</a> workshop with J. B. Rainsberger and Bonnie Aumann.<br></br>
<br></br>
This workshop was all about learning how to "slice a product thinly" so that you can actually ship something of value quickly. We also spent a lot of time working on how to help turn a fuzzy customer product idea into something concrete that you can start to work on. I summarized it to my team like this: You customer comes in and they are…
On October 2nd I participated in a <a href="http://productsashimi.com/">Product Sashimi</a> workshop with J. B. Rainsberger and Bonnie Aumann.<br/>
<br/>
This workshop was all about learning how to "slice a product thinly" so that you can actually ship something of value quickly. We also spent a lot of time working on how to help turn a fuzzy customer product idea into something concrete that you can start to work on. I summarized it to my team like this: You customer comes in and they are usually asking for a whale. At the end of the project what they really wanted was a crab. Your job is to start from their request for a whale and 1) trim the whale down to the meaty parts they really want/need and 2) slice that meaty part thinly so that you can actually start development and deliver value soon.<br/>
<br/>
I happen to work in an academic environment where my customers are colleagues with ideas for software and tools that will help their research or will be used internally for staff. No money actually changes hands for each project, but my team is a scarce resource and we have a lot of projects to handle, more than we can actually deliver. It's not that different from when I was a consultant with paying customers who need the maximum solution at minimum cost and they need it yesterday. You always want to get to delivering value as soon as possible, which means slicing the problem thinly, and you want to make sure that you know you are working on the most valuable things first, which means understanding their business and their needs.<br/>
<br/>
The biggest challenge is understanding what the customer is asking for. Often times they struggle to put it in to words. Sometimes they can describe the solution they are looking for, but it doesn't match the problem they are describing. As knowledgable tech resources we immediately want to get to the meat of what they want, so our first question is "why do you want that?". A great reminder that J.B. and Bonnie kept mentioning is to consider how what you say sounds to the customer. Have you ever had an exchange like this:<br/>
<br/>
<blockquote>Customer: I want an X. Can you make that for me? <br/>
<br/>
Dev: Why do you want X?<br/>
<br/>
<br/>
Customer: What do you mean, 'why do I want that'?!<br/>
</blockquote>
<br/>
Depending on your tone and your relationship with your customer it can sound like you are questioning <em>their own judgement of their needs</em>, when in fact you are really just trying to understand their needs better. J.B. Gave a lot of great examples for what you can say instead. I won't give them all away, but one of my two favorite takeaways from the workshop was the Magic Wand technique.<br/>
<br/>
<blockquote>Customer: I want an X. Can you make that for me? <br/>
<br/>
Dev: Okay, (using imaginary magic wand) TADA! You have an X. Tell me a little about how you are going to use it.<br/>
<br/>
<br/>
Customer: Well...<br/>
</blockquote>
<br/>
This is going to go much better than the example above. It takes a lot of practice to get good at posing those questions.<br/>
<br/>
My second favorite technique is the Lost Luggage Technique. Have you ever been the last one waiting for your bag to arrive on the luggage belt at the airport and then the belt shut off? So you go to the little room and tell them your bag is missing. Usually they will hand you a laminated sheet with pictures of suicases on it and ask you "which one of these does your bag most closely resemble?" followed by "How does your bag differ from the one in the picture?". This is a great technique because it grounds the conversation in something concrete and focuses both of your attention on the ways in which your understandings of the object in question differ.<br/>
<br/>
For example, the customer describes what they want. It sounds a lot like a blog to you. So you say, "What if I give you a WordPress blog? What more do you think you need?"<br/>
and then listen to what they say. Oh, and write it down. Maybe they don't know everything a blog is capable of, so you might share that with them and check again. At this point it is all about listening, and keeping the conversation grounded in concrete terms as much as possible.<br/>
<br/>
As you are listening and writing down what you are learning this is when the sashimi slicing begins. First you want to want to figure out the scope of this<br/>
You have to identify the simplest most barebones solution that could possibly fit the description of what the customer needs and then build out from there to find a simple solution that you can actually deliver. As J.B. put it succinctly, the goal is to learn what you don't have to do and try not to do it.<br/>
<br/>
Once you have cut down the big fuzzy product description into a smaller fleshy piece now the slicing begins. In the training we went over techniques for identifying the major problem areas (maybe 4-8 of them) and then breaking those down in to features and then generating scenarios for those features.<br/>
<br/>
I just gave my team a recap of some of the things that I learned at the sashimi workshop and it started a great discussion about how we are doing in understanding our customers' needs, how to define what is good enough (if you and your customer are both happy could you still not be done?) and even a quasi-role-playing session with our boss as the customer for a real request that had just come up. I am going to need a lot of practice asking those gently leading questions like "Tell me more about how you'd like to use that" and "I'm curious how you came up with the idea of a X".<br/>
<br/>
When we got out of the meeting another one of our internal customers came over with a real request and we decided to see if we could use our new skills to help us learn more about what she is asking for. They ended up beating her with imaginary magic wands, but at least they didn't start off with "Why do you want that"!?!<br/>
<br/>
I did successfully apply the lost luggage technique earlier this week. It's such a simple technique. I found myself with another developer and a customer and we were all talking in abstract terms about a report that she wanted. So, I drew a picture and I said "What if this was the report? would that meet your needs?" and the conversation became much more productive after that. A lot of practice is definintly needed, but I feel like I'm already getting value out of these techniques. I really wish this workshop was a month long so that I could soak up and really practice all of the things that Bonnie and J.B. were sharing with us.<br/>
<br/>
Cross posted from <a href="http://audittyindeed.blogspot.com/2010/10/product-sashimi-is-delicious.html">my blog</a>.Slides from the last meeting Sept 22ndtag:agilephilly.ning.com,2010-10-01:3783271:BlogPost:32472010-10-01T23:11:01.000ZJohn Voris, Lead Coordinatorhttp://agilephilly.ning.com/profile/JohnVoris
<p>Slides from the last joint meeting with SPIN on Sept 22nd are at<br/><a href="http://spin.asqphilly.org/PastMeetings.html">http://spin.asqphilly.org/PastMeetings.html</a><br/></p>
<p>Slides from the last joint meeting with SPIN on Sept 22nd are at<br/><a href="http://spin.asqphilly.org/PastMeetings.html">http://spin.asqphilly.org/PastMeetings.html</a><br/></p>Code Kata Augusttag:agilephilly.ning.com,2010-08-25:3783271:BlogPost:31682010-08-25T13:30:00.000ZAudrey R. Troutthttp://agilephilly.ning.com/profile/AudreyRTroutt
<p>Thank you to Andre, Bonnie, Adam, Aaron and Sebastian for coming out to Code Kata night at the Math Forum! This was an experimental kata night in that we were trying out architectural katas for the first time.</p>
<br></br>
<p>In the beginning we went through a summary of the basic elements of architecture: communication/distribution, presentation/interaction, state management, processing, resource management and tools. For this we followed the slides that Ted Neward provided especially for this…</p>
<p>Thank you to Andre, Bonnie, Adam, Aaron and Sebastian for coming out to Code Kata night at the Math Forum! This was an experimental kata night in that we were trying out architectural katas for the first time.</p>
<br/>
<p>In the beginning we went through a summary of the basic elements of architecture: communication/distribution, presentation/interaction, state management, processing, resource management and tools. For this we followed the slides that Ted Neward provided especially for this event and exercise. The idea is, roughly, that when you are designing the architecture of a system you have to consider each of these elements. I think we can all agree that one way or another requirements inform your technological choices. Asking questions about the system with regard to each of these elements can make it more likely that you don't miss support for a critical aspect of the system. Here are a few examples:</p>
<br/>
<ul>
<li>Communication/Distribution: In what format does data travel? JSON? XML? Over what medium? http? filesystem?</li>
<li>Presentation: What sort of perspectives in to the system do you need? do you need an admin console?</li>
<li>State Management: Does the state need to be persisted across different sessions?</li>
<li>Processing: Does processing need to be transactional?</li>
</ul>
<br/>
<p>Then we made two groups, each randomly selected a kata and spent 25 minutes trying to come up with a suitable architecture to meet the requirements. At the end of the time each group presented their proposal for 3 minutes and fielded 2 minutes of Q and A from me and the other group. I played the role of the customer/game master, answering clarifyng questions about the application.</p>
<br/>
<p>I think it is fair to say that these exercises were hard. One of the exercises was to build a MMORPG. None of us had any experience building similar systems, so there were a lot of open questions about what was possible and how it could be done. I was probably not the best customer for this project either, since I have hardly seen a MMORPG before, let alone thought about how I would want one to work. Even if you are familiar with the domain and know about some of the relevant technology, it is still hard to cover all of the architectural bases in 25 minutes.</p>
<br/>
<p>In the retrospective that followed the question came up, what are these exercises good for? Would this exercise really be valuable to the customer? Andre voiced his skepticism of architecture as a subject because that is not how he would ever work with a customer. As agile-minded folks, we prefer to see the architecture emerge as you are iterating and building the system with your customer. I don't think these exercises are really intended as practice for starting a project with a customer, although I may have set that up by calling myself the customer at the beginning of the exercise and saying that I would decide if I wanted to buy the system at the end. I like these exercises because it is an opportunity to wonder about how things work, and it piques my curiosity to go learn about technology that I haven't had a chance to use at work before (or yet?).</p>
<br/>
<p>One benefit that we saw of these exercises is that they could get the whole team involved in design. Sebastian told us that his team actually does something similar on a regular basis. Pairs will take a card off the wall, think about how they are going to do it and "pre-sell" the approach to at least on the other pair (more for major changes). When the story is done they can present the result and the rest of the team has a chance to say "hey--that's not what you sold me!" which can help to reveal what the pair learned while they were building it. We also discussed ways of displaying architecture or the state of the system in the team area. One idea was modular printouts on the wall, legos or knex. All of these could be kept up to date as things changed. Sebastian once used the printouts as a progress chart, checking off parts of the system as they were completed.</p>
<br/>
<p>All in all this was a fun kata night and I look forward to the next one. Many thanks to Ted Neward of Neward & Associates <a href="http://tedneward.com">http://tedneward.com</a> for letting us use his slides and architectural katas for our kata night.</p>QA Team Member as an Equaltag:agilephilly.ning.com,2010-08-24:3783271:BlogPost:31662010-08-24T22:30:44.000ZRavindar Gujralhttp://agilephilly.ning.com/profile/RavindarGujral
<div><span class="Apple-style-span" style="font-size: small;">Many organizations give a lot of weight to their developers but neglect their QA departments. There are many misconception about the role of QA. This happens more in bigger organizations where there is a greater emphasis on strict demarcation of responsibilities. This creates a culture of silos. It encourages developers to believe that they are not required to interact with QA. Most developers start thinking that they are better than…</span></div>
<div><span class="Apple-style-span" style="font-size: small;">Many organizations give a lot of weight to their developers but neglect their QA departments. There are many misconception about the role of QA. This happens more in bigger organizations where there is a greater emphasis on strict demarcation of responsibilities. This creates a culture of silos. It encourages developers to believe that they are not required to interact with QA. Most developers start thinking that they are better than QA and that all QA does is to nitpick at the beautiful software the developer has delivered.</span></div>
<div><span class="Apple-style-span" style="font-size: small;"><br/></span></div>
<div><span class="Apple-style-span" style="font-size: small;">Quality Assurance is more than defect recognition or Quality Control. A QA team member combines some unique skills, skills that embrace technical, process and, functional understanding of the system as well as a keen eye towards usability, especially critical for a UI-based system. Software QA (involving QC) is a craft, just like software development, and to think otherwise is to not understand software. Agile practices have helped reduce the misconceptions held regarding QA but there is a serious lack of understanding of the role of QA team members in most organizations, even the ones that adopt agile practices.</span></div>
<div><span class="Apple-style-span" style="font-size: small;"><br/></span></div>
<div><span class="Apple-style-span" style="font-size: small;">So let's review just some of what a QA team member brings to a team, especially an agile team:</span></div>
<div><ul>
<li><span class="Apple-style-span" style="font-size: small;">They interact with the customer and have an in-depth understanding of features being implemented. A good QA team member understands what the system does functionally. They illuminate dark areas of software.</span></li>
<li><span class="Apple-style-span" style="font-size: small;">They interact with the developers, understanding the technical implementation of a feature. They work with the developers to help write valid tests for features being implemented.</span></li>
<li><span class="Apple-style-span" style="font-size: small;">They help understand patterns of implementations and help improve process and consistency of software developed. They help with automation of tests, offering developers the rapid feedback that is necessary as they build software.</span></li>
<li><span class="Apple-style-span" style="font-size: small;">They help developers maintain the quality of the software features being delivered.</span></li>
</ul>
</div>
<div><span class="Apple-style-span" style="font-size: small;">Above points are but a few things that a QA team member provides to a team. If you find that your organization sidelines QA, remind them the importance of QA.</span></div>
<div><span class="Apple-style-span" style="font-size: small;"><br/></span></div>
<div><span class="Apple-style-span" style="font-size: small;">Every organization should put as much time into hiring a QA team member as they put in hiring a developer. QA is a craft that takes years of practice. Your brightest and the smartest team members should consider becoming QA. Also every developer should learn to respect QA team members and treat them as equals.</span></div>Local Motors- A story of integrated developmenttag:agilephilly.ning.com,2010-08-19:3783271:BlogPost:31602010-08-19T01:50:22.000ZRavindar Gujralhttp://agilephilly.ning.com/profile/RavindarGujral
This is a great story of a company that is trying to challenge the existing model of a mass producer building something that everyone consumes. Local Motors is an integrated and a more distributed mechanism to buying cars: <a href="http://www.local-motors.com/videos">http://www.local-motors.com/videos</a>. This company exemplifies the movement towards a more decentralized way of doing things, where you empower not just your employees but the client itself.<div><br></br></div>
<div>I have yet to see…</div>
This is a great story of a company that is trying to challenge the existing model of a mass producer building something that everyone consumes. Local Motors is an integrated and a more distributed mechanism to buying cars: <a href="http://www.local-motors.com/videos">http://www.local-motors.com/videos</a>. This company exemplifies the movement towards a more decentralized way of doing things, where you empower not just your employees but the client itself.<div><br/></div>
<div>I have yet to see a software company do it at this level. The concept is obviously that of ownership and decentralization. If you are part of the process from the start you feel ownership. Now if a manufacturing company can do this challenging an existing and well established industry, why are we in the software industry having such a hard time in letting the client get involved?</div>
<div><br/></div>
<div>I hope you all like this story. If this is a success, this would be a great example of a starfish organization. (Referencing the book: <a href="http://www.starfishandspider.com/">http://www.starfishandspider.com/</a>)</div>Follow-up from August's Roundtabletag:agilephilly.ning.com,2010-08-18:3783271:BlogPost:31422010-08-18T01:00:00.000ZSebastian Hermidahttp://agilephilly.ning.com/profile/SebastianHermida
<span class="Apple-style-span" style="font-size: medium;">First of all, thanks to Keith for hosting!</span><div><span class="Apple-style-span" style="font-size: medium;"><br></br></span></div>
<div><span class="Apple-style-span" style="font-size: medium;">It was a great discussion. We will definitely have more of this events in the future...</span><div><span class="Apple-style-span" style="font-size: medium;"><br></br></span></div>
<div><span class="Apple-style-span" style="font-size: medium;">Nobody…</span></div>
</div>
<span class="Apple-style-span" style="font-size: medium;">First of all, thanks to Keith for hosting!</span><div><span class="Apple-style-span" style="font-size: medium;"><br/></span></div>
<div><span class="Apple-style-span" style="font-size: medium;">It was a great discussion. We will definitely have more of this events in the future...</span><div><span class="Apple-style-span" style="font-size: medium;"><br/></span></div>
<div><span class="Apple-style-span" style="font-size: medium;">Nobody from our group took minutes (I know, I know,.. this is the first time).</span></div>
<div><span class="Apple-style-span" style="font-size: medium;">So these are the highlights I remember that we agreed on sharing (please add more in the comments):</span></div>
<div><span class="Apple-style-span" style="font-size: medium;"><br/></span></div>
</div>
<div><ul>
<li><span class="Apple-style-span" style="font-size: medium;">Refactoring videos from</span> <a href="http://anarchycreek.com"><span class="Apple-style-span" style="font-size: medium;">Mike Hill</span></a> <span class="Apple-style-span" style="font-size: medium;">showing how to refactor and write tests for an "ugly" open source project:</span> <a href="http://anarchycreek.com/doubledawgdare-series/"><span class="Apple-style-span" style="font-size: medium;">http://anarchycreek.com/doubledawgdare-series/</span></a> <span class="Apple-style-span" style="font-size: medium;">These videos are awesome to watch in your team room. Mike shows the tips and techniques of the pros.</span></li>
<li><span class="Apple-style-span" style="font-size: medium;">Leadership lessons from a dancing guy:</span> <a href="http://www.youtube.com/watch?v=fW8amMCVAJQ"><span class="Apple-style-span" style="font-size: medium;">http://www.youtube.com/watch?v=fW8amMCVAJQ</span></a></li>
<li><span class="Apple-style-span" style="font-size: medium;">The surprising truth about what motivate us:</span> <a href="http://www.youtube.com/watch?v=u6XAPnuFjJc"><span class="Apple-style-span" style="font-size: medium;">http://www.youtube.com/watch?v=u6XAPnuFjJc</span></a></li>
<li><span class="Apple-style-span" style="font-size: medium;">The new lean startup philly email list:</span> <a href="http://groups.google.com/group/leanstartupphilly"><span class="Apple-style-span" style="font-size: medium;">http://groups.google.com/group/leanstartupphilly</span></a></li>
<li><span class="Apple-style-span" style="font-size: medium;">The lean startup introduction video:</span> <a href="http://www.youtube.com/watch?v=1p3vcRhsYGo"><span class="Apple-style-span" style="font-size: medium;">http://www.youtube.com/watch?v=1p3vcRhsYGo</span></a></li>
<li><span class="Apple-style-span" style="font-size: medium;">Cory Foy getting lost on his way to the meeting:</span> <a href="http://twitter.com/cory_foy/status/21440151128"><span class="Apple-style-span" style="font-size: medium;">http://twitter.com/cory_foy/status/21440151128</span></a> <span class="Apple-style-span" style="font-size: medium;">:)</span></li>
</ul>
<div><span class="Apple-style-span" style="font-size: medium;">We talked about grass root efforts, starting book clubs, test cinema sessions, pairing without asking, practice sessions, teams acting like startups, pair exchanges, motivation, management, progress tracking, when we got into XP, conferences, ...</span></div>
<div><span class="Apple-style-span" style="font-size: medium;"><br/></span></div>
<div><span class="Apple-style-span" style="font-size: medium;">Next time, over beers?</span></div>
</div>
<div><br/></div>
<div><br/></div>
<div><br/></div>On Planningtag:agilephilly.ning.com,2010-05-18:3783271:BlogPost:28662010-05-18T16:33:50.000ZRavindar Gujralhttp://agilephilly.ning.com/profile/RavindarGujral
<p style="margin: 0.0px 0.0px 6.0px 0.0px; line-height: 18.0px; font: 12.5px Arial"></p>
<p style="margin: 0.0px 0.0px 6.0px 0.0px; text-align: justify; line-height: 18.0px; font: 12.0px Arial; color: #5e5e5e"><span style="letter-spacing: 0.0px">Let me start this article with a story I heard listening to a presentation by Ricardo Semler: Gary Kasparov, the chess grandmaster, played a computer nicknamed “Deep Thought” sometime in the 1980’s and he won. Deep Thought could think many moves ahead,…</span></p>
<p style="margin: 0.0px 0.0px 6.0px 0.0px; line-height: 18.0px; font: 12.5px Arial"></p>
<p style="margin: 0.0px 0.0px 6.0px 0.0px; text-align: justify; line-height: 18.0px; font: 12.0px Arial; color: #5e5e5e"><span style="letter-spacing: 0.0px">Let me start this article with a story I heard listening to a presentation by Ricardo Semler: Gary Kasparov, the chess grandmaster, played a computer nicknamed “Deep Thought” sometime in the 1980’s and he won. Deep Thought could think many moves ahead, whereas Kasparov could only think 4-5 moves ahead. So it was concluded that to beat Kasparov, a more powerful computer had to be built that could think many more moves ahead. That’s exactly what IBM did creating “Deep Blue”. Guess what happened: Deep Blue lost. This race went on and on until 1997 when Deep(er) Blue was built. This new enhanced computer could think millions of moves ahead and had all the Grand Master games in its memory. Deep(er) Blue finally defeated Kasparov in a six game match with a score of three draws, two wins and one loss.</span></p>
<p style="margin: 0.0px 0.0px 6.0px 0.0px; text-align: justify; line-height: 18.0px; font: 12.0px Arial; color: #5e5e5e"><span style="letter-spacing: 0.0px">The simple question to ask is “Why did something that could plan so far ahead in so much detail lose to someone that could only plan 4-5 moves ahead, even if it was 1 game (and 3 draws)?” Maybe it’s intuition that the machine lacked. This matters, but I think a better question is “If planning in that much detail and that far ahead did not make Deep Blue win resoundingly, what makes us think that planning ahead in detail will give us the winning formula with all the variability we have?” Thought provoking, isn’t it?</span></p>
<p style="margin: 0.0px 0.0px 6.0px 0.0px; text-align: justify; line-height: 18.0px; font: 12.0px Arial; color: #5e5e5e"><span style="letter-spacing: 0.0px">Shorter cycle is the solution: I will not go into details as to why short term planning and delivering on those plans is better. I am not saying you don’t need to know what you are trying to achieve (in case of Kasparov, winning a chess match), but the details? I am not sure. Briefly, what does shorter cycle do? A shorter delivery cycle:</span></p>
<p style="margin: 0.0px 0.0px 0.0px 36.0px; text-align: justify; text-indent: -36.0px; font: 12.0px Arial; color: #5e5e5e"><span style="letter-spacing: 0.0px">• teaches teams to focus on delivery of things that are really important to the customer</span></p>
<p style="margin: 0.0px 0.0px 0.0px 36.0px; text-align: justify; text-indent: -36.0px; font: 12.0px Arial; color: #5e5e5e"><span style="letter-spacing: 0.0px">• teaches removal of waste</span></p>
<p style="margin: 0.0px 0.0px 0.0px 36.0px; text-align: justify; text-indent: -36.0px; font: 12.0px Arial; color: #5e5e5e"><span style="letter-spacing: 0.0px">• teaches that one requires a team truly working together</span></p>
<p style="margin: 0.0px 0.0px 0.0px 36.0px; text-align: justify; text-indent: -36.0px; font: 12.0px Arial; color: #5e5e5e"><span style="letter-spacing: 0.0px">• requires teams of cathedral builders and not just stonecutters</span></p>
<p style="margin: 0.0px 0.0px 0.0px 36.0px; text-align: justify; text-indent: -36.0px; font: 12.0px Arial; color: #5e5e5e"><span style="letter-spacing: 0.0px">• gives you flexibility and agility</span></p>
<p style="margin: 0.0px 0.0px 0.0px 36.0px; text-align: justify; text-indent: -36.0px; font: 12.0px Arial; color: #5e5e5e"><span style="letter-spacing: 0.0px">• provides the ability to adapt/change as we learn more details</span></p>
<p style="margin: 0.0px 0.0px 0.0px 0.0px; text-align: justify; font: 12.0px Arial; color: #5e5e5e"><span style="letter-spacing: 0.0px">Another reason for shorter cycle is because, to be honest, you can only predict accurately for a short timeframe with the limited set of changing variables that a short timeframe has. The number of variables that affect delivery over a long term is more than anyone can possibly fathom. And more often than not, your plan will be wrong. We all know this. So why waste the time creating a long-term detailed plan? So here are some questions to ask to see if we are getting the benefits that shorter cycles are supposed to deliver:</span></p>
<p style="margin: 0.0px 0.0px 0.0px 36.0px; text-align: justify; text-indent: -36.0px; font: 12.0px Arial; color: #5e5e5e"><span style="letter-spacing: 0.0px">• Do teams feel that planning every detail on a long-term basis is essential?</span></p>
<p style="margin: 0.0px 0.0px 0.0px 36.0px; text-align: justify; text-indent: -36.0px; font: 12.0px Arial; color: #5e5e5e"><span style="letter-spacing: 0.0px">• Do teams really focus and ensure their delivered software is what the customer really wants?</span></p>
<p style="margin: 0.0px 0.0px 0.0px 36.0px; text-align: justify; text-indent: -36.0px; font: 12.0px Arial; color: #5e5e5e"><span style="letter-spacing: 0.0px">• Does the delivered software run in the customer’s environment every month?</span></p>
<p style="margin: 0.0px 0.0px 0.0px 36.0px; text-align: justify; text-indent: -36.0px; font: 12.0px Arial; color: #5e5e5e"><span style="letter-spacing: 0.0px">• Are teams building software that will be used immediately in the customer’s business? If not, has the team stopped to ask why?</span></p>
<p style="margin: 0.0px 0.0px 6.0px 0.0px; text-align: justify; line-height: 18.0px; font: 12.0px Arial; color: #5e5e5e; min-height: 14.0px"><br/></p>
<p style="margin: 0.0px 0.0px 6.0px 0.0px; text-align: justify; line-height: 18.0px; font: 12.0px Arial; color: #5e5e5e; min-height: 14.0px">I guess building software on shorter cycle is important, but to truly change and gain speed, more needs to be done. There must be a change in how we view and think of everything we do. Change so that we do everything in shorter cycle with a rough idea of where we would like to be at the end. Shorter cycles can be assessed and we can make adjustments. We might think we have a complex communication challenge and that detailed planning is required. But maybe the solution is to simplify the challenge.</p>
<p style="margin: 0.0px 0.0px 6.0px 0.0px; text-align: justify; line-height: 18.0px; font: 12.0px Arial; color: #5e5e5e"><span style="letter-spacing: 0.0px">Maybe we need to go beyond software to help us start thinking in shorter cycle. Maybe we should focus on shorter review cycles for everyone. We know market forces are always changing the financial markets. So should we plan in more details? Instead of budgets that plan for a year, maybe we need shorter budget cycle. We have proven that planning a year of budget in advance is not accurate; if they were, we wouldn’t have final month drives at the end of the fiscal year to manage costs and reach financial targets.</span></p>
<p style="margin: 0.0px 0.0px 6.0px 0.0px; text-align: justify; line-height: 18.0px; font: 12.0px Arial; color: #5e5e5e"><span style="letter-spacing: 0.0px">So maybe we need to bring a shorter plan and shorter cycles in everything we do with a view to the longer term goals we want to achieve</span></p>
<p></p>Creating a drawing is a lesson in software creation...tag:agilephilly.ning.com,2010-04-30:3783271:BlogPost:28132010-04-30T20:38:51.000ZJohn Fergusonhttp://agilephilly.ning.com/profile/JohnFerguson
I often struggle with my inability to say code verbally without writing it or drawing it. Sometimes I start out TDD and then my inner well of code overflows into the code and I find from myself or my pair I need to stop! I ask myself why do I do this? Why do I jump into code? I like tests, I love tests more than you can imagine because I hate lots of words for documentation. <br></br><br></br>I was beating myself up over this while driving to work recently and it dawned on me. How do I draw? My drawing…
I often struggle with my inability to say code verbally without writing it or drawing it. Sometimes I start out TDD and then my inner well of code overflows into the code and I find from myself or my pair I need to stop! I ask myself why do I do this? Why do I jump into code? I like tests, I love tests more than you can imagine because I hate lots of words for documentation. <br/><br/>I was beating myself up over this while driving to work recently and it dawned on me. How do I draw? My drawing has two phases usually:<br/><ul>
<li>A rough, complete, imprecise explosion on paper - a sketch and ghost of a final form.</li>
<li>Then if I like the idea I go back and set up the blocking of areas, balance space, add in lines to calculate vanishing point for perspective, measure element proportions (such as limbs), and chose a light source. An important outcome of this activity is that the guardrails in a drawing are removed when done (erased or colored over).<br/></li>
</ul>
So the first event has a parallel in coding - the spike. It is my non-verbal moment when the code overflows out of the silent inner well. No tests, no guide lines, no measure of proportions. Just get something to go end to end. That is my rough sketch for the idea.<br/><br/>The second event is generally marked by the explicit use of guardrails - for our current tools and languages we use Unit Tests with Mocks. We establish the measures from assert and verify checks. In this process though there are some "scaffolding" assertions or verifications that get deleted as we reach the end point. <br/><br/>One key difference from drawing is that the final guardrails (Unit Tests) are checked in with the code. To me these tests are the "meta" to speak to others on behalf of the code. <br/><br/>At this point, the take away I hope to convey here is that a "Sketch" == Spike and that is a holistic view of the end goal. "Properly Composed Drawing" == Test Driven Design Code and is more reductionist. Each test speaks to a facet of the solution. I find I can think a lot about good drawing habits I have read about and learned which can be applied to software. That is to me is a smell, a good smell that software is still an Art.<br/><br/>Fan-out Release Planningtag:agilephilly.ning.com,2010-04-15:3783271:BlogPost:27322010-04-15T16:50:40.000ZD. André Dhondthttp://agilephilly.ning.com/profile/DAndreDhondt
<div><span class="Apple-style-span" style="color: rgb(51, 51, 51); font-family: Georgia, serif; line-height: 20px;">(double-posted from <a href="http://dhondtsayitsagile.blogspot.com/2010/04/fan-out-release-planning.html">http://dhondtsayitsagile.blogspot.com</a>)…</span></div>
<div><span class="Apple-style-span" style="color: rgb(51, 51, 51); font-family: Georgia, serif; line-height: 20px;"><br></br></span></div>
<div><span class="Apple-style-span" style="color: rgb(51, 51, 51); font-family: Georgia, serif; line-height: 20px;">(double-posted from <a href="http://dhondtsayitsagile.blogspot.com/2010/04/fan-out-release-planning.html">http://dhondtsayitsagile.blogspot.com</a>)</span></div>
<div><span class="Apple-style-span" style="color: rgb(51, 51, 51); font-family: Georgia, serif; line-height: 20px;"><br/></span></div>
<div><span class="Apple-style-span" style="color: rgb(51, 51, 51); font-family: Georgia, serif; line-height: 20px;">Fan-out release planning integrates set-based design, weekly intermediate deliverables (and validated learning), sustainable pace, top-down budgeting, risk management, and deliberate prioritization to deliver a valuable product in sync with business, marketing, and sales plans. We do this from a Product Owner's perspective by selecting epics for the release, establishing a budget for each topic based on the business value, reality-checking the expectations with the development team (and trimming scope as necessary), and then scheduling the work strictly in order of priority, stoping development when we've run out of time.</span></div>
<div><span class="Apple-style-span" style="color: rgb(51, 51, 51); font-family: Georgia, serif; line-height: 20px;">The differences between fan-out planning and traditional XP planning are:</span></div>
<div><ul>
<li><span class="Apple-style-span" style="color: rgb(51, 51, 51); font-family: Georgia, serif; line-height: 20px;">an emphasis on exploration, especially during the beginning of an iteration/release</span></li>
<li><span class="Apple-style-span" style="color: rgb(51, 51, 51); font-family: Georgia, serif; line-height: 20px;">top-down scheduling</span></li>
<li><span class="Apple-style-span" style="color: rgb(51, 51, 51); font-family: Georgia, serif; line-height: 20px;">an explicit allowance for functional debt until the end of the release. (Functional debt, for example, is present in a new file editor that allows us to create and save documents, but not yet load them. We could address creating and saving first because the team identified these functions as the most risky, and identified a fail-safe plan of using a plain-text editor to display the files if we don't get a chance to work on loading/rendering issues. This gives us more time to focus on the core value provided by our editor, for example, auto-completion.)</span></li>
<li><span class="Apple-style-span" style="color: rgb(51, 51, 51); font-family: Georgia, serif; line-height: 20px;">an emphasis on slack time, both <a href="http://dhondtsayitsagile.blogspot.com/2010/04/slack-were-not-slacking-off.html" style="color: rgb(85, 136, 170); text-decoration: none;">creative and buffer slack</a></span></li>
</ul>
</div>
<div><span class="Apple-style-span" style="color: rgb(51, 51, 51); font-family: Georgia, serif; line-height: 20px;">We use fan-out planning at an iteration level for cards that we can't readily estimate (because the solution or need is vague). Instead of doing pre-work on a card in an iteration before a story has been slated, we'll schedule it without an estimate, and let the team say what is feasible during the week. What does this do to a week's commitment? It makes it more fluid--people do the work that they can. The goal is to find the essence--the core value of a card--and do something that will yield feedback (validated learning). Normally an un-estimated card only produces a spike or more cards with estimates, but if the developers who took it find the work easy and relatively small (less than a day), they'll often move it to Done-Done. In any case, we have something to show for the work, that can be validated with a client, and we've left the production code in a healthy state (often by using options that hide new features).</span></div>
<div><span class="Apple-style-span" style="color: rgb(51, 51, 51); font-family: Georgia, serif; line-height: 20px;"><br/></span></div>
<div><span class="Apple-style-span" style="color: rgb(51, 51, 51); font-family: Georgia, serif; line-height: 20px;"><b>Why Change the Planning Game?</b></span></div>
<div><span class="Apple-style-span" style="color: rgb(51, 51, 51); font-family: Georgia, serif; line-height: 20px;">Traditional XP release planning leaves little room for slack, and as a result, I think it doesn't get as creative. We also see cycle-time waste when we're doing analysis for story cards that aren't going to be picked for an iteration or more. So instead of nailing things down enough for estimation, we just 'take it offline' and talk when the card has been picked. This can be risky, because bottom-up scheduling and estimation protect a team's sustainable pace. We counter-balance this risk with adequate slack.</span></div>
<div><span class="Apple-style-span" style="color: rgb(51, 51, 51); font-family: Georgia, serif; line-height: 20px;">Another benefit of fan-out planning, counter-intuitive as it may be, is the increased predictability it gives us. It may be a bit premature to say it, but we've been doing fan-out planning for about 15 iterations, including one major release, and we find we are more capable of responding to changes in the market place, more capable of finishing strategic plans, and more predictable. By always focusing on the absolute minimal feature set, we gave ourselves enough slack to become predictable.</span></div>
<div><span class="Apple-style-span" style="color: rgb(51, 51, 51); font-family: Georgia, serif; line-height: 20px;">When we're beginning a new release, we need to provide some visibility to our marketing, sales, and support teams about what's coming with the next version of the product (we make internal releases each one-week iteration, and sometimes deploy those intermediate deliverables to a new client, but most existing clients only upgrade our product every 3-12 months). There's a lot of risk involved in promising a fixed scope with a fixed delivery date--so instead we commit to a delivery date and a vague set of release goals/epics/themes. By using fan-out planning, we attack several candidate solutions, show them to our stakeholders, and wait until later in the release plan to commit to a particular solution.</span></div>
<div><span class="Apple-style-span" style="color: rgb(51, 51, 51); font-family: Georgia, serif; line-height: 20px;"><br/></span></div>
<div><span class="Apple-style-span" style="color: rgb(51, 51, 51); font-family: Georgia, serif; line-height: 20px;"><b>Does this sound familiar?</b></span></div>
<span class="Apple-style-span" style="color: rgb(51, 51, 51); font-family: Georgia, serif; line-height: 20px;">Fan-out release planning is, as far as I know, unique to my team (but inspired by XP, Scrum, and Lean ideas)--and I'd be happy to hear about other teams that are doing something similar, or about any resources/books that describe it, or of any concerns you might have about the process!</span><div><span class="Apple-style-span" style="color: rgb(51, 51, 51); font-family: Georgia, serif; line-height: 20px;"><br/></span></div>How to meet other craftsmentag:agilephilly.ning.com,2010-01-19:3783271:BlogPost:23382010-01-19T02:19:28.000ZSebastian Hermidahttp://agilephilly.ning.com/profile/SebastianHermida
I had the luck to meet a craftsman during these holidays. He is not a software craftsman. He does not work with computers, but with construction and repairs of homes and apartments. He is a master mason.<br />
<br />
During my stay in Spain, I had to interview and evaluate the proposals of three local constructions shops to almost rebuild from scratch an old apartment there.<br />
<br />
I observed a bunch of similarities with the craftsmanship movement of our software industry. This actually helped me make a decision…
I had the luck to meet a craftsman during these holidays. He is not a software craftsman. He does not work with computers, but with construction and repairs of homes and apartments. He is a master mason.<br />
<br />
During my stay in Spain, I had to interview and evaluate the proposals of three local constructions shops to almost rebuild from scratch an old apartment there.<br />
<br />
I observed a bunch of similarities with the craftsmanship movement of our software industry. This actually helped me make a decision to pick the right person for the job. If I ever jump into freelancing, I would try to have all the attributes that made me pick this guy.<br />
<br />
The first thing before starting a project this big, is to get a proposal. You tell them what you want to do, leave them the keys of the apartment, meet again in a couple of days to review their proposals.<br />
<br />
All our proposals were a few pages long. They describe what needs to be done and the price for each of those items. Their language is sometimes technical. They describe the techniques and materials that they plan on using. So I had to learn a lot of new words and the whole process that goes into this “big refactoring” of the apartment.<br />
<br />
After getting all the proposals, compared prices, interviewed again with all of them, made revisions to their original proposals, we chose our shop. Here is what helped us made that decision:<br />
<br />
<b>Referrals</b><br />
<br />
A couple of friends and family had recent experience working with them. They were very happy with the results. They were even proud to show the work that they did for them and walked us through all the details.<br />
<br />
<b>Passion</b><br />
<br />
When interviewing with him, it was obvious that he is passionate about his work. He does not only do it for a living. He enjoys what he does. He took the time to explain the techniques that he would use and why he would apply them.<br />
<br />
<b>Professional</b><br />
<br />
He listened to us and provided advice, ideas and alternatives about what could be done. He was honest about what could be done within budget and what could increase the final price.<br />
<br />
<b>Portafolio</b><br />
<br />
Even though we did not ask for it, he was the only one that took the time to show his current work. We visited houses that his team is currently building and enhancing. We were also able to see his past work through the referrals.<br />
<br />
<b>Price</b><br />
<br />
He was not the cheapest or the more expensive option. He was also upfront that sometimes his team is slower than others. He takes the time to finish his job correctly.<br />
<br />
<b>Payments</b><br />
<br />
A very agile method of payment. Him and his team will work for you for a week. At the end of the week, review their work and decide if you want to continue working with them. You can then pay weekly, every 2 weeks, or monthly. You decide how long is the iteration (he did not call it that, of course). There is no contract, only a handshake to continue to the next iteration.<br />
<br />
The other 2 companies required a 30% up front followed by fixed payments on certain dates.<br />
<br />
He also agreed to send me weekly pictures of the progress through email and I am going to ask him to have regular phone calls to talk about the project. I guess I will secretly call it ‘a standup call’ or something like that ;)<br />
<br />
Of course, this made me wonder about ‘agile’. Why does it seems so easy for this 4 people construction shop to behave like the best ‘agile’ company I ever knew? They haven’t heard the term ‘agile’ and probably don’t care for it. They are craftsmen with a business model that makes sense and works for them.<br />
<br />
Something I admire and hope to copy someday.<br />
<br />
“<i>People don’t care how much you know until they know how much you care</i>” - Cavett RobertPair Exchange Programtag:agilephilly.ning.com,2009-11-19:3783271:BlogPost:20572009-11-19T22:00:00.000ZAudrey R. Troutthttp://agilephilly.ning.com/profile/AudreyRTroutt
<p>I just finished the first ever pair programming exchange program!</p>
<br />
<p>It all started when I was at <a href="http://sdtconf.com">SDTConf</a> back in October. I don't remember the exact conversation, but the question was generally if software development as a <a href="http://manifesto.softwarecraftsmanship.org/">craft</a> takes two programmers pairing together to pass on and practice the craft then how will it ever scale?</p>
<br />
<p>Someone jokingly suggested that…</p>
<p>I just finished the first ever pair programming exchange program!</p>
<br />
<p>It all started when I was at <a href="http://sdtconf.com">SDTConf</a> back in October. I don't remember the exact conversation, but the question was generally if software development as a <a href="http://manifesto.softwarecraftsmanship.org/">craft</a> takes two programmers pairing together to pass on and practice the craft then how will it ever scale?</p>
<br />
<p>Someone jokingly suggested that <a href="http://www.coreyhaines.com/">Corey Haines</a> should get a bigger car--Corey travels all over the place pairing with people and promoting the craft of software development. One idea that I think Corey actually proposed was the idea of a pair exchange.</p>
<br />
<p>The idea is simple: we can't all get Corey Haines or another big name in the XP, Agile, Craftsman, etc. communities to come and pair with us, but there are lots of smart people in every town. If you two are both passionate about practicing and improving your skills then why not use each other as a resource? Everyone has a vacation day to spare, take a day and go pair. If your boss will let you, bring your pair partner to work.</p>
<br />
<p>I know a lot of developers in Philadelphia and I had no trouble thinking of the perfect programmer to pilot my pair exchange program with. Woody Zenfell III is not only one of the smartest and most professional programmers I have ever worked with, but we make a killer pair. It is like our brains are wired almost exactly oppositely, but we get along really well. I like that he is fun to work with and we get a lot of good work done together. Plus, I know his company already and I know that he is on a team of 1 and is probably missing working with other developers.</p>
<br />
<p>When I first brought this idea up to my manager I had reason to be optimistic. My manager sees the value of pairing, even though my team doesn't really practice it much, and he is very supportive of learning and professional growth. I was thrilled when he agreed to the whole thing, both me going to Woody's office for a day and for Woody to come and pair with me and chat with my team. Woody's boss was also game and we were set!</p>
<br />
<p>We decided to do one day at each office, back to back. Since this was our first pair exchange we didn't really know what to expect other than that we would show up, work on some stuff and see what value we get out of it. For me, I knew Woody's code base pretty well, having actually worked on it with him back in our consultant days. For Woody, my team culture and our domain and the code base were all new, so a chunk of time in the morning went to talking about those things. Other than that we just paired; it was awesome. At Woody's place we had some tasks that needed to get done and so we did them. At my place we talked about design for a long time and wrote a test that I was having a hard time writing. Lots of great side-conversations happened with my teammate neighbors. It was fun and we got a lot done.</p>
<br />
<h2>What did we get out of it?</h2>
<br />
<p>For this first exchange it seemed like we were for the most part exchanging little tips, tricks and techniques that make us more efficient and effective. Woody, for example, showed me how he is creating dependency graphs (actual pictures) for all of the stored procedures and reports in his system, automatically, so that he can more confidently make changes to them. He is also getting those database elements into source control and refining a test and deployment process for them, which is something I hadn't thought of before, but is really smart given how important those reports are to his company. He also showed me <a href="http://easymock.org/api/easymock/2.5/org/easymock/Capture.html">captures</a> in EasyMock, which were exactly what I was always dreaming of but never had because we were still using EasyMock 2.3. In return I showed him ctrl+r in cygwin/linux for searching your history. Then he showed me <a href="http://linux.die.net/man/1/pushd">pushd</a> and popd--that's just so handy.</p>
<br />
<p>In addition to tips and tricks we had a lot of conversations about how we do things, like how we work with our users and what process we follow for organizing our work and testing and deployment.</p>
<br />
<p>At the end of the second day we took several laps and talked about the experience. We agreed that it was definitely valuable and something we want to do again. We imagined that after a while we will run out of tips and tricks to show each other and then we didn't know what would happen then, but maybe that we could use each other as reinforcements for when something really sticky comes up and we need a fresh perspective. We talked about doing it again quarterly or monthly or more randomly. We aren't sure how our bosses viewed the experiment, and of course they would have to feel like they are getting a good deal out of this for them to allow it to continue. A lot of factors went in to making this experience go smoothly: the fact that we have both paired a lot before and with each other before, that our bosses are agreeable, there are no super-high security requirements that would prevent guests from coming over and peering at the code, etc. I am curious how well it would go if I was pairing with someone I didn't know very well.</p>
<br />
<p>I would love to hear about more people who are trying this sort of exchange. If you don't have teammates who pair (or teammates at all) you don't have to miss out on the benefits or pair programming--the discipline and the sharing of new ideas.</p>
<br />
<p>Reposted from <a href="http://audittyindeed.blogspot.com/">auditty indeed</a>.</p>