tag:blogger.com,1999:blog-47386395857372600762021-01-29T19:31:25.970+05:30Unblock your TransformationAcross Business, Product, Digital, IT, and other functionsSriramhttp://www.blogger.com/profile/01857432142954216568noreply@blogger.comBlogger27125tag:blogger.com,1999:blog-4738639585737260076.post-32455500399992478042020-02-18T16:30:00.000+05:302020-04-18T11:58:43.000+05:30Fifth anniversary<div class="separator" style="clear: both; text-align: center;"><a href="http://www.amazon.com/dp/0133903354?tag=aitod-20" target="_blank"><img border="0" data-original-height="865" data-original-width="443" height="320" src="https://1.bp.blogspot.com/-URFjXy08tH0/XpqdSWNWxII/AAAAAAAABXs/SozlbSOTvso-Ore0gGNYUoeyyijibF-RwCLcBGAsYHQ/s320/fifth-vertical.png" width="163" /></a></div><div class="separator" style="clear: both; text-align: center;"></div><span style="background-color: #f3f3f3;"><span style="font-family: , , "blinkmacsystemfont" , "segoe ui" , "roboto" , "helvetica neue" , "fira sans" , "ubuntu" , "oxygen" , "oxygen sans" , "cantarell" , "droid sans" , "apple color emoji" , "segoe ui emoji" , "segoe ui symbol" , "lucida grande" , "helvetica" , "arial" , sans-serif; white-space: pre-wrap;"><span style="font-size: x-large;">I</span></span><span style="font-family: , , "blinkmacsystemfont" , "segoe ui" , "roboto" , "helvetica neue" , "fira sans" , "ubuntu" , "oxygen" , "oxygen sans" , "cantarell" , "droid sans" , "apple color emoji" , "segoe ui emoji" , "segoe ui symbol" , "lucida grande" , "helvetica" , "arial" , sans-serif; font-size: 14px; white-space: pre-wrap;">n a world of rapid change, it is quite gratifying to note the continuing relevance of Agile IT Org Design published in 2015. As a buildup to its fifth anniversary in June 2020, I'll post <a href="https://www.linkedin.com/in/mrsriramnarayan/detail/recent-activity/shares/" target="_blank">snippets</a> from the book couple of times a week on <a href="https://www.linkedin.com/posts/mrsriramnarayan_agileorganization-activity-6634785063563288576-J-ll">LinkedIn</a>.</span></span><br /><ol></ol><div class="blogger-post-footer">This content is obtained from a feed at:
http://feeds.feedburner.com/agileorgdesign/qcgV
Get the book: www.agileorgdesign.com
© Sriram Narayan</div>Sriramhttp://www.blogger.com/profile/01857432142954216568noreply@blogger.comtag:blogger.com,1999:blog-4738639585737260076.post-54168878079414625452018-06-12T11:55:00.000+05:302018-06-12T11:55:41.221+05:30Kindle edition usage statistics<div class="separator" style="clear: both; text-align: center;"><a href="https://2.bp.blogspot.com/-GYhrVy2Iwp0/Wx9m8fHdCQI/AAAAAAAAAp0/OFwVaDwHvSUWe6b-3hp7KJFhrjvdZAyBgCLcBGAs/s1600/kindle-highlights.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" data-original-height="906" data-original-width="946" height="306" src="https://2.bp.blogspot.com/-GYhrVy2Iwp0/Wx9m8fHdCQI/AAAAAAAAAp0/OFwVaDwHvSUWe6b-3hp7KJFhrjvdZAyBgCLcBGAs/s320/kindle-highlights.png" width="320" /></a></div><br /><div class="blogger-post-footer">This content is obtained from a feed at:
http://feeds.feedburner.com/agileorgdesign/qcgV
Get the book: www.agileorgdesign.com
© Sriram Narayan</div>Sriramhttp://www.blogger.com/profile/01857432142954216568noreply@blogger.comtag:blogger.com,1999:blog-4738639585737260076.post-15970140929568736292018-02-05T16:09:00.000+05:302018-03-17T14:28:46.272+05:30The challenges of synchronous communicationI have been advocating for and helping clients with the use of written <a href="http://www.cleararchy.com/2016/06/decision-records-in-cleararchy.html" target="_blank">decision records</a> in contentious areas of decision making. However, it is a big change for people who prefer to discuss things verbally over a meeting (face to face or over a call). They claim that it is easy to misunderstand intent over a written medium and that doing it in writing would slow things down.<br /><br />The book weighed in on this topic in the chapter on communications. An excerpt:<br /><blockquote class="tr_bq">"However, the discussions leading to these decisions are often flawed when conducted verbally. This is due to various factors:<br />• Glib tongues talking others down.<br />• Relative seniors intimidating others by tone, impatience, patronizing comments, and nonverbal cues.<br />• The inability of non-native speakers of English to match the articulation of native speakers. They may lack fluency, vocabulary, or panache in English. Fumbling or pausing mid-sentence for a word or a phrase makes for a weak impression.<br />• Lack of time to reflect and counter an argument that sounds good superficially but feels flawed intuitively.<br />• Lack of time to collect one’s thoughts and answer a question effectively.<br />• Spur-of-the-moment emotional reactions to perceived slights."</blockquote>Here's a great example of someone challenging your position in a meeting (an interview, in this case). The interviewee here does a great job of keeping his cool and responding precisely and logically to various strawman arguments from the interviewer. However, it is a tough act to follow and most contentious business meetings would end-up with a sub-optimal decision because of a failure to see through flawed arguments.<br /><br /><iframe allowfullscreen="" frameborder="0" height="270" src="https://www.youtube.com/embed/nS9W-wlJHPA" width="480"></iframe><br /><br />Spoken arguments require us to get it right the first time in real time. It’s like directly deploying software to production with minimal testing. It may be heroic, and those who pull it off regularly may be really sharp (like the interviewee in the video), but it doesn’t make business sense as a practice. On the other hand, written arguments by their very nature force a modicum of scrutiny and reflection (i.e., testing), even when they say “Sent from my smartphone” at the end.<div class="blogger-post-footer">This content is obtained from a feed at:
http://feeds.feedburner.com/agileorgdesign/qcgV
Get the book: www.agileorgdesign.com
© Sriram Narayan</div>Sriramhttp://www.blogger.com/profile/01857432142954216568noreply@blogger.comtag:blogger.com,1999:blog-4738639585737260076.post-13259318306470204132017-11-03T18:31:00.001+05:302017-11-03T18:33:37.839+05:30Taking DevOps to the Org Chart<iframe src="//www.slideshare.net/slideshow/embed_code/key/djEC1pwu16NM8o" width="595" height="485" frameborder="0" marginwidth="0" marginheight="0" scrolling="no" style="border:1px solid #CCC; border-width:1px; margin-bottom:5px; max-width: 100%;" allowfullscreen> </iframe> <div style="margin-bottom:5px"> <strong> <a href="//www.slideshare.net/SriramNarayan2/taking-devops-to-the-org-chart" title="Taking DevOps to the Org Chart" target="_blank">Taking DevOps to the Org Chart</a> </strong> from <strong><a href="https://www.slideshare.net/SriramNarayan2" target="_blank">Sriram Narayan</a></strong> </div>In order to realize the full potential of DevOps, it is insufficient to only aim for better engineering techniques and greater automation, hard as that may be in itself. One of the implications of DevOps is a merger of development and corresponding operations teams into several build-it-and-run-it teams. This calls for a re-org at the typical tech organization that supports an old-guard business. The re-org is a challenge for large tech organizations that are often split down the middle in the form of a change organization and a run organization. <br /><br />This talk (closing keynote at DevOpsDays Singapore 2017) explores the challenge and describes how it being addressed at some companies.<div class="blogger-post-footer">This content is obtained from a feed at:
http://feeds.feedburner.com/agileorgdesign/qcgV
Get the book: www.agileorgdesign.com
© Sriram Narayan</div>Sriramhttp://www.blogger.com/profile/01857432142954216568noreply@blogger.comtag:blogger.com,1999:blog-4738639585737260076.post-70995091442782219452016-09-29T10:09:00.002+05:302016-09-29T10:09:35.281+05:30KPI gamingCame across <a href="http://www.canadianbusiness.com/the-last-days-of-target-canada/" target="_blank">this</a> excellent, in-depth article on the failure of Target Canada. One of the issues was that products were routinely out-of-stock in the stores (leading to upset customers) while registering as in-stock in the company's SAP system:<div><blockquote class="tr_bq">At one point, Target Canada had printed a weekly flyer in which nearly every single item featured on the front cover was out of stock.</blockquote><div>Eventually, they find one of the causes of the problem:<br /><blockquote class="tr_bq">A small group of employees also made an alarming discovery that helped explain why certain items appeared to be in stock at headquarters but were actually missing from stores. Within the chain’s replenishment system was a feature that notified the distribution centres to ship more product when a store runs out. Some of the business analysts responsible for this function, however, were turning it off—purposely. Business analysts (who were young and fresh out of school, remember) <span style="background-color: #fff2cc;">were judged based on the percentage of their products that were in stock at any given time</span>, and a low percentage would result in a phone call from a vice-president demanding an explanation. But by flipping the auto-replenishment switch off, the system wouldn’t report an item as out of stock, so the analyst’s numbers would look good on paper.</blockquote>Chapter 12 of Agile IT Org Design is on metrics. It argues that we have to be very careful of elevating measurements to targets and KPIs. Case in point. </div></div><div class="blogger-post-footer">This content is obtained from a feed at:
http://feeds.feedburner.com/agileorgdesign/qcgV
Get the book: www.agileorgdesign.com
© Sriram Narayan</div>Sriramhttp://www.blogger.com/profile/01857432142954216568noreply@blogger.comtag:blogger.com,1999:blog-4738639585737260076.post-36926988369106429002016-07-12T23:00:00.000+05:302016-07-12T23:00:03.460+05:30Bimodal IT and two-speed IT miss the pointWe can't trade-off reliability for speed in the medium term. Models that make this assumption are inherently flawed. If you really want to think in terms of a two-pronged approach, think strategic and utility as I describe in my post on <a href="http://martinfowler.com//bliki/BusinessCapabilityCentric.html" target="_blank">business-capability centric</a> orgs. Martin Fowler <a href="http://martinfowler.com//bliki/BimodalIT.html" target="_blank">seconds</a> it.<div class="blogger-post-footer">This content is obtained from a feed at:
http://feeds.feedburner.com/agileorgdesign/qcgV
Get the book: www.agileorgdesign.com
© Sriram Narayan</div>Sriramhttp://www.blogger.com/profile/01857432142954216568noreply@blogger.comtag:blogger.com,1999:blog-4738639585737260076.post-43202786011948884802016-04-05T22:35:00.000+05:302016-09-21T05:06:53.215+05:30How Product-Centric IT Disrupts Portfolio Management<em>One of the key functions of Project Portfolio Management (PPM) in IT is that of allocating finite funds to a subset of projects that vie for funding. When it works well, PPM becomes an effective agent of capital allocation within enterprise IT by funding promising projects and terminating underperforming ones. In principle, this is not very different to how a venture capitalist might manage their portfolio by investing in promising ventures and freezing funding or writing off investments in ventures that don’t show promise. But in practice, PPM tends to work very differently in a typical setup. <a href="https://www.linkedin.com/pulse/how-product-centric-disrupts-portfolio-mgmt-sriram-narayan" target="_blank">Read more</a></em><div class="blogger-post-footer">This content is obtained from a feed at:
http://feeds.feedburner.com/agileorgdesign/qcgV
Get the book: www.agileorgdesign.com
© Sriram Narayan</div>Sriramhttp://www.blogger.com/profile/01857432142954216568noreply@blogger.comtag:blogger.com,1999:blog-4738639585737260076.post-82658646308965458332016-03-16T17:19:00.001+05:302016-09-21T05:04:35.729+05:30Decision Records For AccountabilityAlthough we need to arrive at an operating model that allows for autonomy, mastery, and purpose, we need to balance it with mechanisms for accountability and alignment. This has to be done for each dimension of the operating model.<br /><div class="separator" style="clear: both; text-align: center;"><a href="https://3.bp.blogspot.com/-6UIf6m_Ee88/VulHgJKDiQI/AAAAAAAAAOg/jLypjkCEu9k_vgpx2rTEV63LFJ_KrLrgA/s1600/balance.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="206" src="https://3.bp.blogspot.com/-6UIf6m_Ee88/VulHgJKDiQI/AAAAAAAAAOg/jLypjkCEu9k_vgpx2rTEV63LFJ_KrLrgA/s320/balance.png" width="320" /></a></div>In the area of decision making, we allow for autonomy by letting outcome owners have decision rights while others who support the outcome have input rights. That said, we have to ensure that people with decision rights do not disregard the opinions of those with input rights. Decision records are the balancing act. They provide a transparent audit trail for important decisions.<br /><br />Recently, Michael Nygard of <i>Release It</i> fame argued for <a href="http://thinkrelevance.com/blog/2011/11/15/documenting-architecture-decisions" target="_blank">architecture decision records</a>. That's one more reason to consider them.<div class="blogger-post-footer">This content is obtained from a feed at:
http://feeds.feedburner.com/agileorgdesign/qcgV
Get the book: www.agileorgdesign.com
© Sriram Narayan</div>Sriramhttp://www.blogger.com/profile/01857432142954216568noreply@blogger.comtag:blogger.com,1999:blog-4738639585737260076.post-41982798184396446972016-03-10T10:48:00.001+05:302016-09-15T06:38:22.727+05:30Metrics, Targets and IncentivesChapter 12 of Agile IT Org Design is on metrics. It argues that we have to be very careful of elevating measurements to targets and elevating targets to incentives. In this post, I'll continue to add relevant articles around the internet as and when I find them.<br /><br /><a href="https://hbr.org/2016/03/powerful-people-react-more-unethically-to-incentives" target="_blank">Powerful People React More Unethically to Incentives</a> (HBR, March 2016)<br /><br />Martin Fowler's <a href="http://martinfowler.com/articles/eliminatingSalesCommissions/" target="_blank">infodeck</a> on sales commissions at Thoughtworks<br /><br /><a href="http://www.bloomberg.com/news/articles/2016-09-14/how-sales-targets-encourage-wrongdoing-inside-america-s-companies" target="_blank">Telling stories of incentive malfunction</a> across the spectrum of business.<div class="blogger-post-footer">This content is obtained from a feed at:
http://feeds.feedburner.com/agileorgdesign/qcgV
Get the book: www.agileorgdesign.com
© Sriram Narayan</div>Sriramhttp://www.blogger.com/profile/01857432142954216568noreply@blogger.comtag:blogger.com,1999:blog-4738639585737260076.post-61934473579365222402015-12-23T15:22:00.000+05:302016-09-21T05:06:09.666+05:30Does Product-Centric IT Need Projects and Programs?Product-centric IT differs from conventional, project-centric IT in significant ways.<br /><br /><table border="1" cellpadding="0" cellspacing="0" class="MsoTableGrid" style="border-collapse: collapse; border: none; mso-border-alt: solid windowtext .5pt; mso-padding-alt: 0in 5.4pt 0in 5.4pt; mso-yfti-tbllook: 1184;"> <tbody><tr> <td style="border: solid windowtext 1.0pt; mso-border-alt: solid windowtext .5pt; padding: 0in 5.4pt 0in 5.4pt; width: 233.75pt;" valign="top" width="312"><div class="MsoNormal" style="margin-bottom: 0.0001pt;"><b>Product-Centric</b></div></td> <td style="border-left: none; border: solid windowtext 1.0pt; mso-border-alt: solid windowtext .5pt; mso-border-left-alt: solid windowtext .5pt; padding: 0in 5.4pt 0in 5.4pt; width: 233.75pt;" valign="top" width="312"><div class="MsoNormal" style="margin-bottom: 0.0001pt;"><b>Project-Centric</b></div></td> </tr><tr> <td style="border-top: none; border: solid windowtext 1.0pt; mso-border-alt: solid windowtext .5pt; mso-border-top-alt: solid windowtext .5pt; padding: 0in 5.4pt 0in 5.4pt; width: 233.75pt;" valign="top" width="312"><div class="MsoNormal" style="margin-bottom: 0.0001pt;">Stable long-lived teams</div></td> <td style="border-bottom: solid windowtext 1.0pt; border-left: none; border-right: solid windowtext 1.0pt; border-top: none; mso-border-alt: solid windowtext .5pt; mso-border-left-alt: solid windowtext .5pt; mso-border-top-alt: solid windowtext .5pt; padding: 0in 5.4pt 0in 5.4pt; width: 233.75pt;" valign="top" width="312"><div class="MsoNormal" style="margin-bottom: 0.0001pt;">Temporary teams </div></td> </tr><tr> <td style="border-top: none; border: solid windowtext 1.0pt; mso-border-alt: solid windowtext .5pt; mso-border-top-alt: solid windowtext .5pt; padding: 0in 5.4pt 0in 5.4pt; width: 233.75pt;" valign="top" width="312"><div class="MsoNormal" style="margin-bottom: 0.0001pt;">Teams aligned to long-term business capabilities</div></td> <td style="border-bottom: solid windowtext 1.0pt; border-left: none; border-right: solid windowtext 1.0pt; border-top: none; mso-border-alt: solid windowtext .5pt; mso-border-left-alt: solid windowtext .5pt; mso-border-top-alt: solid windowtext .5pt; padding: 0in 5.4pt 0in 5.4pt; width: 233.75pt;" valign="top" width="312"><div class="MsoNormal" style="margin-bottom: 0.0001pt;">Teams aligned to scope of project</div></td> </tr><tr> <td style="border-top: none; border: solid windowtext 1.0pt; mso-border-alt: solid windowtext .5pt; mso-border-top-alt: solid windowtext .5pt; padding: 0in 5.4pt 0in 5.4pt; width: 233.75pt;" valign="top" width="312"><div class="MsoNormal" style="margin-bottom: 0.0001pt;">Cross-functional teams are the norm</div></td> <td style="border-bottom: solid windowtext 1.0pt; border-left: none; border-right: solid windowtext 1.0pt; border-top: none; mso-border-alt: solid windowtext .5pt; mso-border-left-alt: solid windowtext .5pt; mso-border-top-alt: solid windowtext .5pt; padding: 0in 5.4pt 0in 5.4pt; width: 233.75pt;" valign="top" width="312"><div class="MsoNormal" style="margin-bottom: 0.0001pt;">Functional specialty teams are common</div></td> </tr><tr> <td style="border-top: none; border: solid windowtext 1.0pt; mso-border-alt: solid windowtext .5pt; mso-border-top-alt: solid windowtext .5pt; padding: 0in 5.4pt 0in 5.4pt; width: 233.75pt;" valign="top" width="312"><div class="MsoNormal" style="margin-bottom: 0.0001pt;">Focus is value (actual benefits realization)</div></td> <td style="border-bottom: solid windowtext 1.0pt; border-left: none; border-right: solid windowtext 1.0pt; border-top: none; mso-border-alt: solid windowtext .5pt; mso-border-left-alt: solid windowtext .5pt; mso-border-top-alt: solid windowtext .5pt; padding: 0in 5.4pt 0in 5.4pt; width: 233.75pt;" valign="top" width="312"><div class="MsoNormal" style="margin-bottom: 0.0001pt;">Focus is plan compliance</div></td> </tr></tbody></table><div><br /></div><div>But projects and programs are a staple of enterprise IT. Doesn't Product-Centric IT need projects and programs? And what does it mean for the roles of project and program managers? Read it <a href="https://www.thoughtworks.com/insights/blog/podcast-does-product-centric-it-need-projects-and-programs">here</a>.</div><div class="blogger-post-footer">This content is obtained from a feed at:
http://feeds.feedburner.com/agileorgdesign/qcgV
Get the book: www.agileorgdesign.com
© Sriram Narayan</div>Sriramhttp://www.blogger.com/profile/01857432142954216568noreply@blogger.comtag:blogger.com,1999:blog-4738639585737260076.post-21714478036878642272015-12-22T18:00:00.000+05:302016-09-29T10:16:38.088+05:30Scrum is not enough<div class="separator" style="clear: both; text-align: center;"><a href="http://4.bp.blogspot.com/-Mgf7aYHiNWc/Vnjm6TpZwYI/AAAAAAAAAMw/Erh7JJGYNS0/s1600/operating-model.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="280" src="https://4.bp.blogspot.com/-Mgf7aYHiNWc/Vnjm6TpZwYI/AAAAAAAAAMw/Erh7JJGYNS0/s320/operating-model.png" width="320" /></a></div><table align="center" cellpadding="0" cellspacing="0" class="tr-caption-container" style="margin-left: auto; margin-right: auto; text-align: center;"><tbody><tr><td style="text-align: center;"><a href="http://4.bp.blogspot.com/-dRymX_NAjQA/VoTOSTtl-1I/AAAAAAAAANI/T3Dxeawt-Vk/s1600/operating-model-legend.png" imageanchor="1" style="margin-left: auto; margin-right: auto;"><img border="0" height="207" src="https://4.bp.blogspot.com/-dRymX_NAjQA/VoTOSTtl-1I/AAAAAAAAANI/T3Dxeawt-Vk/s320/operating-model-legend.png" width="320" /></a></td></tr><tr><td class="tr-caption" style="text-align: center;">What it takes to achieve business-IT agility</td></tr></tbody></table><div class="separator" style="clear: both; text-align: center;"><br /></div><div class="separator" style="clear: both; text-align: center;"></div>I wrote a <a href="https://www.thoughtworks.com/insights/blog/podcast-designing-outcome-oriented-teams-part-1">post</a> at ThoughtWorks Insights in which I use this picture to illustrate why Scrum alone is not enough to make Agile deliver business impact. I then go deeper into one particular thing that's needed (among others) over and above Scrum—reorganizing teams to be outcome-oriented. Read it <a href="https://www.thoughtworks.com/insights/blog/podcast-designing-outcome-oriented-teams-part-1">here</a>.<div class="blogger-post-footer">This content is obtained from a feed at:
http://feeds.feedburner.com/agileorgdesign/qcgV
Get the book: www.agileorgdesign.com
© Sriram Narayan</div>Sriramhttp://www.blogger.com/profile/01857432142954216568noreply@blogger.comtag:blogger.com,1999:blog-4738639585737260076.post-64839264127165785692015-08-28T11:31:00.000+05:302016-09-28T08:26:08.017+05:30Designing teams for outcome-orientation<span style="background-color: white;"><span style="font-family: inherit;">Here's a podcast that <span style="color: #333333; line-height: 19.6000003814697px;">explores IT reorganization from a structural angle. We discuss how to design teams for outcome (rather than activity) orientation, how to execute streams of work that cut across different product-centric teams and the role of project and program managers in product-centric IT.</span></span></span><br /><br /><iframe frameborder="no" height="90" scrolling="no" src="https://w.soundcloud.com/player/?url=https%3A//api.soundcloud.com/tracks/221166320&auto_play=false&hide_related=false&show_comments=true&show_user=true&show_reposts=false&visual=true" width="100%"></iframe><div class="blogger-post-footer">This content is obtained from a feed at:
http://feeds.feedburner.com/agileorgdesign/qcgV
Get the book: www.agileorgdesign.com
© Sriram Narayan</div>Sriramhttp://www.blogger.com/profile/01857432142954216568noreply@blogger.comtag:blogger.com,1999:blog-4738639585737260076.post-69541388170276597972015-08-27T17:03:00.002+05:302016-09-21T05:07:26.438+05:30A tool for business-IT alignment<div class="separator" style="clear: both; text-align: center;"><a href="http://3.bp.blogspot.com/-TdHCF6R6JQU/Vd71ZOf8_5I/AAAAAAAAAJ4/4RUS-wfXP30/s1600/global.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="306" src="https://3.bp.blogspot.com/-TdHCF6R6JQU/Vd71ZOf8_5I/AAAAAAAAAJ4/4RUS-wfXP30/s400/global.png" width="400" /></a></div>Information radiators such as story card walls, burn-up charts, build pipelines etc. help with team level agility. What are the corresponding information radiators for overall organizational agility? For example, some places use portfolio Kanban walls. In my book, I describe several organizational information radiators. One of them is what I call as an Alignment Map. They help visualize the alignment of ongoing work with business outcomes. Martin Fowler has kindly published my description of Alignment Maps on <a href="http://martinfowler.com/bliki/AlignmentMap.html" target="_blank">his web site</a>.<br /><br />Lars Barkman has since written up a <a href="http://larsbarkman.com/2015/08/26/alignmentmaps-with-graphviz/" target="_blank">how-to</a> on collaborating on alignment maps using dot files + Graphviz + version control. You can get the source from <a href="https://github.com/LarsBarkman/Graphviz_Models/blob/master/AlignmentMap.dot" target="_blank">github</a>.<div class="blogger-post-footer">This content is obtained from a feed at:
http://feeds.feedburner.com/agileorgdesign/qcgV
Get the book: www.agileorgdesign.com
© Sriram Narayan</div>Sriramhttp://www.blogger.com/profile/01857432142954216568noreply@blogger.comtag:blogger.com,1999:blog-4738639585737260076.post-24775181301996820832015-08-19T10:01:00.002+05:302015-08-19T10:01:48.934+05:30Three principles of Agile IT Org DesignI wrote an article for <a href="http://www.informit.com/articles/article.aspx?p=2426891" target="_blank">InformIT</a> where I describe three principles of Agile IT Org Design that the book recommends and elaborates:<div><ul><li>Govern for value over predictability</li><li>Organize for responsiveness over cost-efficiency</li><li>Design for intrinsic motivation and unscripted collaboration</li></ul></div><div class="blogger-post-footer">This content is obtained from a feed at:
http://feeds.feedburner.com/agileorgdesign/qcgV
Get the book: www.agileorgdesign.com
© Sriram Narayan</div>Sriramhttp://www.blogger.com/profile/01857432142954216568noreply@blogger.comtag:blogger.com,1999:blog-4738639585737260076.post-89371077963598938712015-08-10T23:06:00.001+05:302015-08-19T09:52:41.709+05:30Essentials of scale-out managementI have previously stated that Agile scales by <a href="http://www.agileorgdesign.com/2015/06/scale-agile-vertical-horizontal.html" target="_blank">scaling-out</a> rather than scaling-up. I expand on this in a presentation at an event in London. (<a href="https://dl.dropboxusercontent.com/u/6691653/slides/essentials-of-scale-out-mgmt.pdf" target="_blank">slides</a>)<br /><br /><div class="separator" style="clear: both; text-align: center;"><iframe allowfullscreen="" class="YOUTUBE-iframe-video" data-thumbnail-src="https://i.ytimg.com/vi/bfE-TdknOJ8/0.jpg" frameborder="0" height="266" src="https://www.youtube.com/embed/bfE-TdknOJ8?feature=player_embedded" width="320"></iframe></div><br /><div class="blogger-post-footer">This content is obtained from a feed at:
http://feeds.feedburner.com/agileorgdesign/qcgV
Get the book: www.agileorgdesign.com
© Sriram Narayan</div>Sriramhttp://www.blogger.com/profile/01857432142954216568noreply@blogger.comtag:blogger.com,1999:blog-4738639585737260076.post-20613745251515589172015-07-18T11:36:00.000+05:302015-07-18T11:36:21.967+05:30Interview on InfoQ<a href="http://www.infoq.com/articles/organization-design">http://www.infoq.com/articles/organization-design</a><br /><br />"Sriram Narayan’s book provides a basis for reviewing and reshaping the IT organization to equip it better for the digital age."<div class="blogger-post-footer">This content is obtained from a feed at:
http://feeds.feedburner.com/agileorgdesign/qcgV
Get the book: www.agileorgdesign.com
© Sriram Narayan</div>Sriramhttp://www.blogger.com/profile/01857432142954216568noreply@blogger.comtag:blogger.com,1999:blog-4738639585737260076.post-44126921485883994552015-07-12T20:13:00.000+05:302015-07-12T20:13:49.043+05:30Org Chart Debt - A Risky, Off-Balance Sheet Liability<div class="separator" style="clear: both; text-align: center;"><a href="http://3.bp.blogspot.com/-pbxlRpXyHL4/VaJ8fswZF1I/AAAAAAAAAHw/x2RIn5pa8Wo/s1600/org-chart-debt.jpg" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="160" src="http://3.bp.blogspot.com/-pbxlRpXyHL4/VaJ8fswZF1I/AAAAAAAAAHw/x2RIn5pa8Wo/s320/org-chart-debt.jpg" width="320" /></a></div><br />Recently, <a href="http://steveblank.com/2015/05/19/organizational-debt-is-like-technical-debt-but-worse/" target="_blank">Steve Blank</a>, a luminary who developed the Customer Development methodology, a precursor to the Lean Startup movement, said that organizational debt is like technical debt in software but worse: “Organizational debt is all the people/culture compromises made to <span style="font-style: oblique;">'just get it done' </span>in the early stages of a start-up.”<br /><div style="font-style: oblique; margin-left: 3em; margin-right: 3em;">“Just when things should be going great, organizational debt can turn a growing company into a chaotic nightmare. Growing companies need to understand how to recognize and “refactor” organizational debt.”</div>He was talking about organizational debt incurred by startups at the time of hiring lots of people as it prepares to grow. On the other hand, Enterprise IT incurs organizational debt throughout the course of its existence.<br /><div style="font-style: oblique; margin-left: 3em; margin-right: 3em;">“IT organization design is rarely thought out from a baseline of principles. The prevailing design is mostly a product of happenstance, mergers or acquisitions, people-retention compulsions, and the ideas of whoever is in charge at various levels in the organization. It resembles how software accumulates technical debt over time unless we periodically step back and reassess the design.” <a href="http://www.amazon.com/dp/0133903354" target="_blank">Agile IT Organization Design</a></div><div class="rteindent1" style="font-style: oblique; margin-left: 3em; margin-right: 3em;"></div>And as with all debt that isn’t repaid on time, unaddressed organizational debt creates more problems. It results in silos, politics, unclear accountability, slow decision making and poor responsiveness to the market in general. <a href="http://www.thoughtworks.com/insights/blog/org-chart-debt-risky-balance-sheet-liability" target="_blank">Read further</a>.<div class="blogger-post-footer">This content is obtained from a feed at:
http://feeds.feedburner.com/agileorgdesign/qcgV
Get the book: www.agileorgdesign.com
© Sriram Narayan</div>Sriramhttp://www.blogger.com/profile/01857432142954216568noreply@blogger.comtag:blogger.com,1999:blog-4738639585737260076.post-50424297844880127952015-06-27T22:51:00.000+05:302015-06-27T23:20:35.421+05:30Agile Organization Structure<div class="MsoNormal"><span style="font-family: Georgia, Times New Roman, serif;">Some people mistake my book, "Agile IT Org Design" to be only about org structure. A couple of them even wondered if the book was a 250 page elaboration of Conway’s law. As if Conway’s law sums up everything there is to IT org structure.<o:p></o:p></span></div><span style="line-height: 107%;"><span style="font-family: Georgia, Times New Roman, serif;"><br /></span></span><span style="line-height: 107%;"><span style="font-family: Georgia, Times New Roman, serif;">Although I address it quite comprehensively, structure is but one aspect of organization design. Eight out of sixteen chapters in the book have almost nothing to do with structure. Only two (Ch 4. Superstructure and Ch 5. Team Design) are 100% about structure. The other chapters cover operational, cultural and political aspects of IT organization design. A re-org that only pays attention to structure is likely to be ineffective.</span></span><div class="blogger-post-footer">This content is obtained from a feed at:
http://feeds.feedburner.com/agileorgdesign/qcgV
Get the book: www.agileorgdesign.com
© Sriram Narayan</div>Sriramhttp://www.blogger.com/profile/01857432142954216568noreply@blogger.comtag:blogger.com,1999:blog-4738639585737260076.post-14794860887431720352015-06-13T22:53:00.002+05:302016-08-19T04:16:18.755+05:30Do you scale Agile vertically or horizontally?<div dir="ltr" style="text-align: left;" trbidi="on"><div class="separator" style="clear: both; text-align: center;"><a href="http://1.bp.blogspot.com/-7L5MBj7nhDk/VXxme9aQ9QI/AAAAAAAAAFM/gAZlqJYoSc8/s1600/agile-scale-out-not-up.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="388" src="https://1.bp.blogspot.com/-7L5MBj7nhDk/VXxme9aQ9QI/AAAAAAAAAFM/gAZlqJYoSc8/s400/agile-scale-out-not-up.png" width="400" /></a></div><div class="MsoNormal"><b><span style="font-size: large;">M</span></b>ost attempts to scale Agile struggle because the IT leadership attempts to scale up (vertical) rather than scale out (horizontal). Scale-up is old school management. It involves context-free management by numbers, standardized metrics, reports and dashboards and workforce motivation by targets and incentives. Inside IT, this approach usually ends up scaling supervision (not management) without improving IT performance. This is why we find managers functioning as supervisors and Scrum masters functioning as taskmasters in self-proclaimed Agile enterprise IT.<o:p></o:p></div><div class="MsoNormal"><br /></div><br /><div class="MsoNormal">“Individuals and interactions” is not a marketing buzz phrase. It has to be taken seriously in the pursuit of agility. The organization has to be designed for intrinsic motivation and unscripted collaboration. Chapter three of Agile IT Org Design elaborates on this. Individuals <a href="http://www.ted.com/talks/dan_pink_on_motivation">respond</a> to an environment of autonomy, mastery and purpose. Leadership balks at autonomy because it worries about loss of alignment with strategy and weakening of accountability. Chapters six and seven of the book explain how to allow autonomy and yet preserve alignment and accountability (using <a href="http://www.agileorgdesign.com/2016/03/decision-records-for-accountability.html">decision records</a>, for example). This is the basis of scale-out management.<o:p></o:p></div></div><div class="blogger-post-footer">This content is obtained from a feed at:
http://feeds.feedburner.com/agileorgdesign/qcgV
Get the book: www.agileorgdesign.com
© Sriram Narayan</div>Sriramhttp://www.blogger.com/profile/01857432142954216568noreply@blogger.comtag:blogger.com,1999:blog-4738639585737260076.post-1759960374044692632015-06-06T06:57:00.000+05:302015-06-17T06:55:09.046+05:30Team Design<div dir="ltr" style="text-align: left;" trbidi="on">Here's a free sample <a href="http://thght.works/1JwoVSO">chapter</a> on "Team Design" from my book. This chapter explores the following:<br /><br />"Before asking how I can make my current set of teams work better together, ask whether they are the right configuration of teams."<br /><br />However, middle managers usually shy away from asking the latter question because they feel it is beyond their pay grade. Nevertheless, it is necessary to address this question if we are to scale agility and make IT more responsive as a whole.</div><div class="blogger-post-footer">This content is obtained from a feed at:
http://feeds.feedburner.com/agileorgdesign/qcgV
Get the book: www.agileorgdesign.com
© Sriram Narayan</div>Sriramhttp://www.blogger.com/profile/01857432142954216568noreply@blogger.comtag:blogger.com,1999:blog-4738639585737260076.post-85540521883102274222015-05-30T02:00:00.000+05:302015-06-13T23:54:11.675+05:30Rework IT for digital success<div dir="ltr" style="text-align: left;" trbidi="on">In an earlier post, I had argued <a href="http://www.thoughtworks.com/insights/blog/digital-brings-it-home" target="_blank">how IT has become strategic</a> owing to the demands of a digital business. Strategic IT cannot justify itself with IT metrics such as velocity or even with delivering to plan. It has to make a difference to business outcomes. IT agility takes on a new meaning in this light. It is not enough to claim that our development teams are agile. Engineering agility and delivery process agility are necessary but not sufficient for digital success. <a href="http://thght.works/1HQJszI">Read further</a></div><div class="blogger-post-footer">This content is obtained from a feed at:
http://feeds.feedburner.com/agileorgdesign/qcgV
Get the book: www.agileorgdesign.com
© Sriram Narayan</div>Sriramhttp://www.blogger.com/profile/01857432142954216568noreply@blogger.comtag:blogger.com,1999:blog-4738639585737260076.post-73182958601556084042015-05-23T19:00:00.000+05:302016-12-22T06:48:41.277+05:30Agile over Lean<div dir="ltr" style="text-align: left;" trbidi="on"><h2 style="text-align: left;"><span style="font-weight: normal;"><span style="font-family: "helvetica" , sans-serif; font-size: x-small; line-height: 107%;">“That is, while there is value in the items on the right, we value the items on the left </span><a href="http://agilemanifesto.org/" style="font-family: Helvetica, sans-serif; font-size: small; line-height: 107%;">more</a><span style="font-family: "helvetica" , sans-serif; font-size: x-small; line-height: 107%;">.”</span></span></h2><div class="MsoNormal"><span style="text-align: justify;"><br /></span><br /><div style="text-align: justify;"><span style="text-align: justify;">A number of reviewers suggested (in good faith) that I use “Lean” instead of “Agile” in the title of my book (Agile IT Organization Design) in order to improve its marketability. Apparently, Lean is in whereas Agile is jaded. However, the strong people-orientation credentials of Agile are core to the solutions I propose. I’d like to expand on this and some other reasons in this post which is also meant as a defense of Agile over Lean when it comes to organizational transformation in digital and tech organizations.</span></div><br /><div style="text-align: justify;"><o:p></o:p></div></div><div class="MsoNormal"><div style="text-align: justify;"> Lean is great. Lean techniques emphasize waste avoidance, limiting work-in-progress, continuous improvement and caring about whole value stream optimization. I advocate these things in various chapters in my book. However, organizational agility needs more than process optimization.<o:p></o:p><br /><br /></div></div><h3 style="text-align: left;">People Orientation</h3><h2><o:p></o:p></h2><div class="MsoNormal"><div style="text-align: justify;"><br />When taken beyond development teams to organizational levels, the Agile principle of “individuals and interactions over processes and tools” actually has a bearing on the org chart, and the metrics and tooling regime. This may not be evident at first but I go to great lengths in the book to bring it out. For example, a matrixed IT organization demands more process in order to co-ordinate between the arms of the matrix than a product or <a href="http://www.martinfowler.com/bliki/BusinessCapabilityCentric.html" target="_blank">capability centric</a> org structure. Similarly, the Agile principle of “adapting to change over following a plan” has a bearing on how governance teams function, not just Scrum masters. Agile thus provides a sound base of attitudes upon which Lean techniques can be exploited.</div></div><div class="MsoNormal"><div style="text-align: justify;"> People orientation is an aspect of an organization’s culture. In his excellent Agile Survival <a href="http://www.infoq.com/minibooks/agile-adoption-transformation">Guide</a>, Sahota examines Lean and Agile through the lens of Schneider’s culture <a href="http://www.parshift.com/Speakers/Speak016.htm">model</a>. This model classifies an organization’s culture on two axes—content (what-is vs. what-might-be) and process (people-first vs. company/policy-first), and names the four possible combinations as competence, control, collaboration and cultivation. Sahota argues that collaboration and cultivation cultures are Agile-friendly whereas control and competence cultures are Lean/Kanban-friendly. I find Sahota’s argument convincing and from this perspective, the overall approach is my book is clearly Agile.<o:p></o:p><br /><br /></div></div><h3 style="text-align: left;">Software Development isn’t Production</h3><h2><o:p></o:p></h2><div class="MsoNormal"><div style="text-align: justify;"><br />This is another reason why I think Agile has to be the foundation rather than Lean. Software development is a design process rather than a production process whereas Lean has its roots in the Toyota <i>production</i> system. If we are to draw parallels to manufactured goods, software development resembles the product development phase more than the manufacturing or production phase. Chapter three of <a href="http://www.amazon.com/dp/0133903354?tag=aitod-20" target="_blank">Agile IT Org Design</a> explains further.</div></div><div class="MsoNormal"><div style="text-align: justify;"> Applying Lean manufacturing principles wholesale to software development runs the risk of planting false metaphors of production in the minds of IT managers. In the book, I argue that the average IT manager’s fixation over predictability and relative disregard for actual benefits (value) partly stems from this false metaphor. Metaphors are powerful because they can be <a href="http://xp123.com/articles/the-system-metaphor/">generative</a> and therefore it is important to get them right.<o:p></o:p><br /><br /></div></div><h3 style="text-align: left;">Data-Driven Illusions</h3><h2><o:p></o:p></h2><div class="MsoNormal"><div style="text-align: justify;"><br />Advocacy for data-driven decision making is at an all-time high following the success of the Lean Startup book and its numerous offspring. However, it is somewhat naïve to believe that a culture of HiPPO (Highest Paid Person’s Opinion) decision making can be overcome by prescribing new formulae like cost-of-delay, for example. Prioritization is a <a href="http://www.thoughtworks.com/insights/blog/priorities-and-politics">political</a>exercise in any organization of more than say, ten people. Students of history, geopolitics and current affairs will agree that politics trumps data.</div><div style="text-align: justify;"> Formulaic, data-driven solutions for better decisions operate on the wrong side of “individuals and interactions over processes and tools”. In the chapters on accountability and metrics in Agile IT Org Design, I describe <a href="https://cleararchy.com/" target="_blank">solutions</a> that acknowledge politics, that continue to stand by “individuals and interactions”, and that are data-informed rather than data-driven.<o:p></o:p><br /><br /></div></div><h3 style="text-align: left;">Label Abuse</h3><h2><o:p></o:p></h2><div class="MsoNormal"><div style="text-align: justify;"><br />Some claim that “Agile” is a much maligned label and therefore it makes sense to move on to less discredited labels like “Lean”. But Lean has its own share of misinterpretations and misapplications. <a href="https://www.linkedin.com/pulse/damage-lean-management-geoff-schaadt">This post</a>, for example, argues well that <span class="s1">“Lean” has become synonymous with efficiency and layoffs.</span> People tend to think of Lean as being the opposite of fat. It isn’t widely understood that capital-A Agile and capital-L Lean have only a <a href="https://www.linkedin.com/pulse/accused-being-agile-purist-dennise-openshaw" target="_blank">limited semantic overlap</a> with their common English counterparts “agile” and “lean”. Otherwise interesting debates have been framed poorly as <a href="http://techcrunch.com/2010/05/25/lean-vs-fat-startups-the-disrupt-debate/">“Lean vs. Fat”</a>.</div></div><div class="MsoNormal"><div style="text-align: justify;"> There will always be cases where people blame their wrong extrapolations on the book. The Lean Startup devotes less than three pages to describe product/market fit. However, this doesn’t stop people from claiming that they <a href="http://www.infoq.com/articles/lean-startup-killed">failed</a> to achieve product/market fit despite following the book’s advice. Label abuse is no reason to jump ship.</div></div></div><div class="blogger-post-footer">This content is obtained from a feed at:
http://feeds.feedburner.com/agileorgdesign/qcgV
Get the book: www.agileorgdesign.com
© Sriram Narayan</div>Sriramhttp://www.blogger.com/profile/01857432142954216568noreply@blogger.comtag:blogger.com,1999:blog-4738639585737260076.post-12816596983392777942015-04-25T18:18:00.000+05:302015-06-13T23:53:50.572+05:30Why is IT getting in-sourced?<div dir="ltr" style="text-align: left;" trbidi="on"><div class="separator" style="clear: both; text-align: center;"><a href="http://1.bp.blogspot.com/-S4y4K2VUrPc/VTuM4P5yNrI/AAAAAAAAAEU/aQOqItk7_7o/s1600/shore-small.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="237" src="http://1.bp.blogspot.com/-S4y4K2VUrPc/VTuM4P5yNrI/AAAAAAAAAEU/aQOqItk7_7o/s1600/shore-small.png" width="400" /></a></div><br />Key thoughts: (<a href="http://thght.works/1K8AL4r" rel="nofollow" target="_blank">full post</a>)<br /><ul><li>Ten years ago, many businesses did not consider IT to be a core competency. But it's strategic now. Like it or not, businesses are now forced to pay greater attention to IT. The attention economy is largely digital, and IT systems mediate the relationship between attention-hungry sellers and spoilt-for-choice buyers.</li><li>When IT becomes strategic, we can no longer evaluate the success of IT efforts using IT metrics (e.g. did we deliver to plan?). Strategic IT has to make a difference to business outcomes. This needs much closer collaboration between IT and business than is typically afforded by outsourcing. It also needs cross-functional teams that span IT and business. Again, this is very difficult to achieve under the terms of a tightly worded outsourcing contract. Businesses that understand this new dynamic are bringing IT back in-house. They are outsourcing IT more selectively.</li></ul><a href="http://thght.works/1K8AL4r" rel="nofollow" target="_blank">full post</a></div><div class="blogger-post-footer">This content is obtained from a feed at:
http://feeds.feedburner.com/agileorgdesign/qcgV
Get the book: www.agileorgdesign.com
© Sriram Narayan</div>Sriramhttp://www.blogger.com/profile/01857432142954216568noreply@blogger.comtag:blogger.com,1999:blog-4738639585737260076.post-39375921650705651992015-04-04T20:34:00.000+05:302015-06-17T06:57:36.645+05:30A “definition of done” for Agile at scale<div dir="ltr" style="text-align: left;" trbidi="on"><div class="MsoNormal"><span style="font-family: inherit;">It seems everyone wants to scale Agile. Many say they have done so already. But there are different views on what the end state looks like. What does it mean to have scaled Agile? For many, it simply means replicating certain practices across all development teams. Although this may improve the <a href="http://www.infoq.com/articles/gaudin-sonar-jacoco">internal quality</a> of software, it won’t help improve overall IT performance as perceived by the business.<o:p></o:p></span></div><div class="MsoNormal"><span style="font-family: inherit;"><br /></span><span style="font-family: inherit;">Agilists advocate that every story must have acceptance criteria. What are the acceptance criteria for having scaled Agile? More broadly, what is the “definition of done”? Here’s one:</span></div><div class="MsoListParagraphCxSpFirst" style="mso-list: l0 level1 lfo1; text-indent: -.25in;"></div><ul style="text-align: left;"><li><b style="font-family: inherit; text-indent: -0.25in;"><i>Responsive IT</i></b><span style="font-family: inherit; text-indent: -0.25in;">: Achievement of continuous delivery for the entire value stream (not just development team) from feature concept to cash or user adoption.</span></li><li><b style="font-family: inherit; text-indent: -0.25in;"><i>Valuable IT</i></b><span style="font-family: inherit; text-indent: -0.25in;">: Innovation occurs relatively unimpeded by artificial organizational constraints.</span></li><li><b style="font-family: inherit; text-indent: -0.25in;"><i>One team</i></b><span style="font-family: inherit; text-indent: -0.25in;">: Business and IT are able to work as one team even if they are separate on the org chart.</span></li><li><b style="font-family: inherit; text-indent: -0.25in;"><i><span style="line-height: 107%;">Scaled performance, not just supervision</span></i></b><span style="font-family: inherit; line-height: 107%; text-indent: -0.25in;">: Don’t say you have scaled Agile when all you have managed is to scale supervision of Agile. Has it made a difference to business outcomes? That’s the litmus test.</span></li></ul><div style="text-align: left;"><span style="line-height: 17.1200008392334px;">In my <a href="http://www.amazon.com/dp/0133903354">upcoming book</a>, I explain that this target state cannot be attained without improvements to the design of the IT organization.</span></div><!--[if !supportLists]--></div><div class="blogger-post-footer">This content is obtained from a feed at:
http://feeds.feedburner.com/agileorgdesign/qcgV
Get the book: www.agileorgdesign.com
© Sriram Narayan</div>Sriramhttp://www.blogger.com/profile/01857432142954216568noreply@blogger.comtag:blogger.com,1999:blog-4738639585737260076.post-23898923352749483772015-03-24T16:19:00.000+05:302015-06-17T06:57:49.379+05:30What really hinders Agile at scale<div dir="ltr" style="text-align: left;" trbidi="on"><div class="MsoNormal"><b>Update: 10-June-2015</b><br /><a href="http://thght.works/1JF8bsB">Article in ThoughtWorks Insights</a><br /><br /><b>Update: 27-May-2015</b><br />Here's the full video of my talk:<br /><div class="separator" style="clear: both; text-align: center;"><iframe allowfullscreen="" class="YOUTUBE-iframe-video" data-thumbnail-src="https://i.ytimg.com/vi/CIB4JAMZF2I/0.jpg" frameborder="0" height="266" src="https://www.youtube.com/embed/CIB4JAMZF2I?feature=player_embedded" width="320"></iframe></div><b>Older post:</b><br />Organizational agility is required in order to scale Agile. It requires changes to IT structure, operations and governance. This is different from engineering and process agility that development teams focus on. I’ll cover this using real examples in my talk at <a href="http://confengine.com/agile-india-2015/schedule#session-4241-info">Agile India 2015</a> tomorrow (25<sup>th</sup> March) at 3:30pm.</div><div class="MsoNormal"><o:p></o:p></div><div class="MsoNormal"><br /></div><div class="separator" style="clear: both; text-align: center;"><a href="http://1.bp.blogspot.com/-bnWpkouc1v4/VRE_0jZIVmI/AAAAAAAAADw/rmrxh07XSPo/s1600/conf.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" src="http://1.bp.blogspot.com/-bnWpkouc1v4/VRE_0jZIVmI/AAAAAAAAADw/rmrxh07XSPo/s1600/conf.png" /></a></div><br /><div class="separator" style="clear: both; text-align: center;"><a href="http://1.bp.blogspot.com/-UqJ3FN7mxdw/VRE_3MgYQTI/AAAAAAAAAD4/pVLyCOIQm1s/s1600/talk.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="143" src="http://1.bp.blogspot.com/-UqJ3FN7mxdw/VRE_3MgYQTI/AAAAAAAAAD4/pVLyCOIQm1s/s1600/talk.png" width="320" /></a></div><div class="MsoNormal"><br /></div><br /><div class="MsoNormal"><!--[if gte vml 1]><v:shapetype id="_x0000_t75" coordsize="21600,21600" o:spt="75" o:preferrelative="t" path="m@4@5l@4@11@9@11@9@5xe" filled="f" stroked="f"> <v:stroke joinstyle="miter"/> <v:formulas> <v:f eqn="if lineDrawn pixelLineWidth 0"/> <v:f eqn="sum @0 1 0"/> <v:f eqn="sum 0 0 @1"/> <v:f eqn="prod @2 1 2"/> <v:f eqn="prod @3 21600 pixelWidth"/> <v:f eqn="prod @3 21600 pixelHeight"/> <v:f eqn="sum @0 0 1"/> <v:f eqn="prod @6 1 2"/> <v:f eqn="prod @7 21600 pixelWidth"/> <v:f eqn="sum @8 21600 0"/> <v:f eqn="prod @7 21600 pixelHeight"/> <v:f eqn="sum @10 21600 0"/> </v:formulas> <v:path o:extrusionok="f" gradientshapeok="t" o:connecttype="rect"/> <o:lock v:ext="edit" aspectratio="t"/></v:shapetype><v:shape id="Picture_x0020_3" o:spid="_x0000_i1026" type="#_x0000_t75" style='width:187.5pt;height:111.75pt;visibility:visible;mso-wrap-style:square'> <v:imagedata src="file:///C:\Users\srinaray\AppData\Local\Temp\msohtmlclip1\01\clip_image001.png" o:title=""/></v:shape><![endif]--><!--[if !vml]--><!--[endif]--><!--[if gte vml 1]><v:shape id="Picture_x0020_2" o:spid="_x0000_i1025" type="#_x0000_t75" style='width:244.5pt;height:111.75pt; visibility:visible;mso-wrap-style:square'> <v:imagedata src="file:///C:\Users\srinaray\AppData\Local\Temp\msohtmlclip1\01\clip_image003.png" o:title="" cropbottom="11413f" cropright="11838f"/></v:shape><![endif]--><!--[if !vml]--><!--[endif]--><o:p></o:p></div></div><div class="blogger-post-footer">This content is obtained from a feed at:
http://feeds.feedburner.com/agileorgdesign/qcgV
Get the book: www.agileorgdesign.com
© Sriram Narayan</div>Sriramhttp://www.blogger.com/profile/01857432142954216568noreply@blogger.com