From Project to Product Teams: Implementing the Inverse Conway Move for better Software

<div class="cs-rating pd-rating" id="pd_rating_holder_1819065_post_1437"></div> <p>Modern software engineering techniques within organisations deliver “distributed features” using agile techniques. These features are distributed across different systems and integrated to provide an end-to-end experience. Traditional project delivery brings in  members from different <em>system</em> <em>oriented</em> <em>teams</em> to deliver these features in a loose and ad-hoc fashion and dis-bands the team after a project is closed</p> <p>Oriented to <strong>long-standing</strong> teams with a <strong>product</strong> focus has been shown to be more successful in delivering features which stand the test of time as software is able to evolve, maintained and optimised for new customer needs to differentiate the business from others</p> <p>In this post we talk about Conway’s law as it applies to software engineering and how bringing teams together into cross-functional long standing product teams provides long term value. This act of realising product vs project orientation and building multi-system team to build software is called an inverse (reverse) Conway manoeuvre</p> <p><strong>Conway’s Law </strong></p> <p>Melvin Conway described a law where he states that the parts of a software system are directly proportional to the organisational structure</p> <blockquote> <ul> <li><em>“Organizations which design systems are constrained to produce designs which are copies of the communication structures of these organizations.” – Melvin Conway <a href="http://www.melconway.com/Home/Conways_Law.html">%5B1%5D</a></em></li&gt; <li><em>“If you have four groups working on a compiler, you’ll get a 4-pass compiler” – Eric S Raymond <a href="http://catb.org/~esr/jargon/html/C/Conways-Law.html">%5B2%5D</a></em></li&gt; </ul> </blockquote> <p><strong>Layered Architecture Style</strong></p> <p>We can think of the modern teams oriented around the customer and end-systems to deliver integrated products in the following manner (circa 2020)</p> <p>Thus, broadly speaking, teams orient around technical layers due to the cohesiveness of the “technical domain” expertise & customer’s (software client) needs.</p> <p><img class="aligncenter wp-image-1423" src="https://alok-mishra.com/wp-content/uploads/2016/07/screen-shot-2020-08-17-at-1.29.17-pm.png&quot; alt="Screen Shot 2020-08-17 at 1.29.17 pm" width="331" height="448" /></p> <p>If you have been part of  similar teams in the past you must be familiar with the “layered architectural style” that gives rise to this team</p> <p><img class="aligncenter size-full wp-image-833" src="https://alok-mishra.com/wp-content/uploads/2016/07/soalayers.png&quot; alt="SOALayers" width="1023" height="380" /></p> <p><strong>Technical Teams = Technical Product</strong></p> <p>While the layered teams do a great job of grouping the teams by technical expertise, business needs for new end-to-end features are contextual, especially in a large enterprise. Things are more contextual in the real-world</p> <p><img class="aligncenter wp-image-1427" src="https://alok-mishra.com/wp-content/uploads/2016/07/screen-shot-2020-08-17-at-2.52.24-pm.png&quot; alt="Screen Shot 2020-08-17 at 2.52.24 pm" width="326" height="484" /></p> <p>While the layered team structure may work initially for one context, we find adding new features and domain contexts makes it harder to maintain software components across a layer. This leads to slower software delivery due to various reasons</p> <p>It is becomes increasing difficult for a single team to know and own aspects of a technical layer used in various contexts</p> <p><img class="aligncenter wp-image-1428" src="https://alok-mishra.com/wp-content/uploads/2016/07/screen-shot-2020-08-17-at-2.59.30-pm.png&quot; alt="Screen Shot 2020-08-17 at 2.59.30 pm" width="446" height="469" /></p> <p>Conway’s law: With layered teams, we build layered software components focussed on the technical correctness vs end-to-end functionality</p> <p><strong>Techno-functional Teams = Functional Products</strong></p> <p>Applying the “<em>reverse Conway manoeuvre</em>” – fixing our team organisation to shape our software we break the technical teams into smaller <em>functional</em> teams. This process naturally builds a more “Domain Centric Product team” which can focus on functional needs and stay true to the end-to-end feature</p> <p>This organisation allows for a closer relationship across technology layers as we group experts in different technical domains to deliver a common outcome and if done well, allows a small<em>ish </em>technical team to own a contextual solution</p> <p><img class="alignnone size-full wp-image-1429" src="https://alok-mishra.com/wp-content/uploads/2016/07/screen-shot-2020-08-17-at-3.10.07-pm.png&quot; alt="Screen Shot 2020-08-17 at 3.10.07 pm" width="1986" height="1056" /></p> <p><strong>Pitfalls of Functional Teams</strong></p> <p>Functional teams are not the <em>perfect</em> solution. Functional teams are highly agile and can own a specific end-to-end solutions through the entire software lifecycle but they operate in their own<strong><em> bubble</em></strong></p> <p>When organisations have different “technical practices” within their IT with different software engineering standards (one for the Portal team, one for the Integration team, one for the CRM team etc) it becomes harder to <em>enforce technical standards</em> within a technical context when a member is “outsourced” to another team</p> <p><strong>Conclusion</strong></p> <p>Modern software engineering is oriented towards building networked distributed features for a highly connected and web savvy customer base in varying contexts. Traditional team structures within the enterprise have evolved from technical SME cliques as engineers who “Ate lunch together wrote Software together”</p> <p>Good product strategy requires thinking about breaking up the technical groups into highly effective functional teams and keeping the “band together”  through  the  lifecycle  of the software  (the end-to-end product)</p>