Sriram Narayan’s book – Agile IT Organization Design: For Digital Transformation and Continuous Delivery, provides a basis for reviewing and reshaping the IT organization to equip it better for the digital age. The book covers how structural, political, operational, and cultural facets of the organization design influence overall IT agility and how to promote better collaboration across diverse functions, from sales and marketing to product development, and engineering to IT operations.
This book shows how organization design helps deliver organizational agility and in turn help IT and business Agility. Organizational Agility is also an important ingredient for digital transformation.
The book explains the applicability of Agile principles in designing an Agile IT organization followed by the explanation of macro level view of the structure of organizations. Author explains the centralized and decentralized structures with their pros and cons. He then goes on to provide a thorough coverage of team design, accountability, alignment, project finance, tooling, metrics, organizational norms, communication, and culture.
The author provides very useful and relevant real world examples which help to evaluate and improve organization designs that enhance autonomy, mastery, and purpose. Diagrams clearly represent the structures, layouts and flows.
InfoQ interviewed Sriram about the book and discussed his viewpoints.
InfoQ: Your book is about designing an Agile IT Organization. Could you please explain this for InfoQ readers? What aspects of the organization do you think are the most important to be considered to achieve overall IT Agility?
Sriram: The digital wave has made IT strategic for everyone, not only for so-called tech companies. Strategic IT has to make a difference to business outcomes, not just achieve sustainable velocity or even deliver to plan. In Enterprise IT, this calls for overall responsiveness—agility that goes beyond development and IT operations team agility. There is engineering and process agility and then there is organizational agility. Things like:
- Structuring departments and teams for responsiveness
- Changing the IT funding model so as to enable a change in the execution model from being project-centric to product or capability centric.
- Redesigning the metrics, targets and incentives regime so as to discourage local optimization
- Paving the way for speedy decision making by clarifying ownership and accountability for outcomes and for decisions along the way.
Thus we need to reconsider the structural, operational, cultural and political facets of the organization in order to move towards overall IT agility.
InfoQ: How can an organization design help deliver organizational agility and why is it important to consider?
Sriram: It is not completely up to individuals to achieve agility. Organizational barriers may come in the way. Overcoming these barriers may require authority that is beyond the pay grade of most employees. And systems influence behavior. Unless we put some deliberate thought into setting up our IT organizations for agility, it is likely to lead to unhelpful behaviors. Just like how software accumulates technical debt unless we pay regular attention to it, organizations accumulate organizational debt that threaten to undermine business outcomes.
InfoQ: You emphasize having teams, based on outcomes as opposed to activity oriented. Would you like to elaborate?
Sriram: Activity oriented teams are single-specialty teams like teams of developers, testers, UXers, IT governors, etc. We commonly encounter them in IT matrix organizations. Outcome oriented teams consist of whoever is needed to realize a business outcome. Thus, they are cross- functional by nature. Product development teams are a good example of outcome oriented teams. However, the existence of a market-facing product isn’t a prerequisite to organizing this way. Enterprise IT can very well reorganize itself into a product or capability centric configuration.
Agility depends on individuals and interactions. Motivated individuals and unconstrained interactions. In turn, this requires that organizations be set up to allow for autonomy, mastery and purpose. However, the risk of autonomy is a loss of alignment with larger business goals, silo-like behavior and local optimization. Then again, it is less risky to grant autonomy to outcome-oriented teams than to activity-oriented teams assuming the outcome in question is valuable to the business.
Cross-functional, outcome-oriented teams also tend to be more responsive because most handoffs occur within the team rather than between teams as in the case of activity-oriented teams.
InfoQ: How do you see an outsourcing model impacting organizational Agility? How do organizations achieve Agility in this scenario?
Sriram: Since organizing by outcome works better than organizing by activity, outsourcing needs to follow the same pattern. Outsource by outcome rather than by activity. Say you have three projects X, Y and Z. Don’t outsource all development to appdev vendor P, all UX to design vendor Q, all testing to testing services vendor R and so on. Instead outsource all aspects of projects X, Y, and Z to full-stack vendors A, B and C respectively. Also make sure that the full-stack vendors don’t foil your plans for organizational agility by:
- Organizing by activity internally (a common anti-pattern with big IT services companies).
- Using metrics, targets and incentives that encourage local optimization.
- Adopting spurious Agile implementations based on recommendations by some CMM-inspired central process quality group.
Finally, make sure that a “client vs. service-provider” dynamic does not infiltrate day-to-day collaboration between in-house and vendor’s team members. Agility needs a single team with no second-class members.
InfoQ: How do you see shared services in any organization? And what do you suggest to the shared services to remain focused for their goals?
Sriram: A shared service team is one whose services are used by teams responsible for widely different outcomes. All shared services are activity-oriented teams, but not vice versa. From the point of view of encouraging autonomy, mastery and purpose, shared services are worse than activity-oriented teams.
For example, a development project may be run using separate activity oriented teams of developers, testers, UXers etc. This is bad enough in terms of increasing the cost of handoffs and restricting collaboration. However, the same project could be set up to use a shared testing service whose members test scenarios from different projects on different days. This configuration erodes a sense of purpose which devolves to that of providing efficient testing services. There isn’t enough passion toward the functionality being developed.
Besides, shared service teams tend to gradually “standardize” their services and start asking service consumers to fill out boilerplate forms, restrict unscripted communications and measure themselves against local metrics such as cost per request, member utilization etc. Even when they report more useful metrics such as responsiveness, the overworked team members tend to game it by offering a canned and not-so-useful but immediate response to hit the metric.
InfoQ: Aligning IT with Business has been always a problem in many organizations. How can we reduce the gap between business and technology and what type of organizational structure is good for this.
Sriram: The best structure is one in which business and IT are part of the same outcome- oriented team. Many new generation independent software vendors (ISVs) and internet businesses operate like this or close to this. If a separate IT organization is unavoidable, at least avoid setting it up as a global pool of resources or even an IT matrix. Instead, identify coarse-grained business capabilities that are enabled by IT and form long-lived, stable teams around them.
To reduce the alignment gap:
- Articulate, document and disseminate business strategy to all stakeholders (if not everyone)
- Do the same with IT strategy based on #1. Use MIT’s enterprise architecture operating models, Gartner’s pace layering approach or something else to define high-level alignment.
- Use simple mind-map style information radiators to capture alignment of ongoing work with business outcomes.
- Introduce the role of IT business partners as described by Topinka in his book IT Business Partnerships. They help translate business objectives, context and concerns to IT and IT’s ideas and achievements to business.
InfoQ: Do you see any difference between Agile and Lean approaches to org transformation?
Sriram: Agile provides a great foundation of people-orientation upon which Lean techniques of process optimization such as limiting work-in-progress, reducing waste, and continuous improvement may be exploited. I have explained this in greater detail here.
InfoQ: Who are the target readers of the book and how it’s beneficial for them?
Sriram: The target audience are IT and digital leadership and governance people. Using realistic example scenarios, the book offers solutions for organizational agility that span structural, cultural, operational and political domains. It effectively provides them with a target operating model for agility at scale. Speaking of scale, this book is based on the notion that Agile scales out better than scaling up. This is explained in the following illustration:
Agile scales out (Image Copyright Sriram Narayan. Used with permission)
About the Book Author
Sriram Narayan is an IT management consultant at ThoughtWorks. He helps clients improve their IT performance through better organization design. He has also served as a leadership development coach, director of innovation, product owner & advocate and as a member of the ThoughtWorks Technology Advisory Board. For more details about his book, please visit www.agileorgdesign.com