This talk (video) was co-presented by Sree B, who had hired me as a consultant/advisor at Travelopia in 2021. Travelopia is an experiential travel company. Their travel brands provide customers with options as varied as polar expeditions, yachts, and adventure travel. Customer experience is supported by digital platforms that enable discovery, bookings, tailoring itineraries, and completing travel paperwork. The technology delivery pipeline is always full and it is easy to get buried in the details of execution and lose sight of business outcomes.

To avoid this trap, we came with mechanisms to keep the business outcomes front and center. These mechanisms are built around a central artifact - a KPI tree. In this talk Sree and Sriram will share how they made use of KPI trees to tighten the business case analysis process, demilitarize prioritization of initiatives, improve demand management, speedup onboarding of new colleagues, and enhance shared understanding and alignment.

A product-centric style of operating provides greater opportunities for all members to participate on the value side of the equation. They can truly aim to deliver benefits, not just functionality. This presentation aims to share ways of capitalizing on the opportunity through the practice of benefits retrospectives. Otherwise, the payoff of the transition from projects to product-mode is limited to the delivery side of the equation.

Business inertia (old ways of working on the business side) poses a challenge for digital transformation. At the level of business leaders, it limits the ability to plan and execute market iterations of products and hurts business results in the process. At the board level, it limits the ability of board members to appreciate complexity when assessing digital transformation plans. This talk (video) describes the problem and suggests ways to overcome it.

Delivery organizations fall into the trap of simply delivering scope (functionality) without worrying about benefits. They keep taking orders to build bridges and maintain them even though the bridges attract little traffic. Product/Business and delivery organizations need to work closer together in order to avoid becoming a mindless feature factory. This presentation will share ways of gradually progressing towards a culture of benefits orientation.

Digital success demands market-responsive teams that can truly solve problems and not just build some software. The projects way of funding and organizing software delivery is unsuited for these new demands. In this talk, Sriram presents an alternative to projects that is popular among digital natives and gaining ground with old-guard businesses.

One of the implications of DevOps is a merger of development and corresponding operations teams into several build-it-and-run-it teams. This means the typical tech organization that supports an old-guard business must reorganize 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. The reorg 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. This talk explores the challenge and describes how it being addressed at some companies.

See slides.

Business agility demands a lot more than development team agility. Even when Scrum is done right, it only takes us to signed-off stories. DevOps and Continuous Delivery then take us reliably and frequently to production. But this is only part of the picture and even getting to this stage is not free of organizational barriers. On the other hand, excellence in building (and running) the thing right does not ensure that the right thing that yields business benefits is built. That calls for a culture of outcome-orientation and product-centricity. Aiming for business agility thus requires us to reconsider how we operate along different dimensions such as funding of development work, team structure, procurement, governance and decision making. Sriram’s book, Agile IT Org Design, describes an approach for reshaping these dimensions for business agility. Using real-world examples, this presentation will provide an overview of the approach.

See video

DevOps addresses the last mile of continuous delivery. It advocates the tearing down of silos between development and operations. It kind of assumes that silos don't exist elsewhere. This is often not true in enterprise IT where the number of silos correlates well with the number of vice presidents. This anti-pattern of org design takes two forms. One is when you have a VP sw-dev, VP Data, VP configuration management, VP Testing, VP UX, VP Deployment. The other is when you have a product manager along with a VP Sales, VP Marketing, VP Support and VP Training. On the other hand, an org design based on true cross-functional teams has teams accountable for business outcomes and puts one person in clear charge of each team. This part of getting things right can be classified as CD for execs and basically involves applying the DevOps pattern to general org design. There is also a part two.

Tooling can also hinder cross functional behaviour. Especially when access to tools are granted on a strict need-to-use basis. So for example, only sales guys get salesforce access. Or when marketing disallows self-service publishing from the product teams. Or when the devs use one tool for continuous integration and the deployment teams uses a completely different disconnected tool for release automation. Sometimes commercial considerations (licensing costs) encourage this behaviour but it doesn't serve the cause of tearing down silos. We need a new culture that restricts access to tools only where unavoidable but is open otherwise.

The API economy needs good relationships between API providers and consumers. Making it work in this context is in some ways, similar to making it work in romantic relationships. The presentation suggests what each of the following "good practices" in the realm of romantic relationships might translate to in the world of APIs:

• Serve your partner the way they’d like to be served.

• Tolerate minor shortcomings of your partner.

• Don’t take their kindness for granted.

• Always be there for each other.

• Give each other some space.

• Only ask for what you’ll use.

• Open marriages work, until they don’t.

A talk of the pros and cons of code ownership vs. an internal open source model in enterprise IT organized as product teams.

Explores pros and cons of reuse of software solutions across market regions. For any large, multinational enterprise, there’s a dilemma at the heart of their software architecture. Centralization promises to save costs, providing a standardized template for how to do things and not waste effort reinventing the wheel. But local markets have unique characteristics, whether that’s customer behavior, regulations or the competitive landscape. Given this, what's the price of reuse?

Large-scale software development generates a lot of data when teams use tools like Jira or Azure Devops. We could analyze the data with statistical tools and techniques in order to understand how to improve delivery performance. Naresh Jain and Sriram Nararyan have been attempting this at one of their clients. In this talk (video), they’ll share the techniques they used and the lessons they have learnt so far.

KPIs for software delivery leaders used to be mainly with regards to meeting delivery dates without compromising on quality. There was lots of emphasis on predictable delivery. Nowadays there is increasing recognition of the value of improving speed-to-market and therefore, metrics like “Change Lead Time” (CLT) have also become important. To reduce CLT, we need to improve flow which is not the same as improving predictability. (recording - courtesy of Digité)

How the shape of the engineering organization might influence the number of late-stage defects in software: a case study in claiming to follow Scrum or XP practices versus really knowing what you are doing.

Agile was born in the house of software development. As it grew and matured, it was welcomed everywhere. Adopting Agile outside IT goes much deeper than imitating rituals like stand-up meetings and retrospectives. For example, as the world keeps changing ever faster, the agile principle of adapting to change over following a plan becomes essential to success. Similarly, the original agile principle of aiming for working software over comprehensive documentation can be understood more broadly as aiming for outcomes and impact over activities and output. This talk describes a domain-neutral set of agile approaches for obtaining better and faster outcomes in any context that is subject to greater volatility, uncertainty, complexity, or ambiguity.

An experience report of consulting for the social development sector. Extrapolates a bit to describe how you can make use of agile approaches outside the world of technology. Please note "Agile outside Technology" isn't the same as "Business Agility". That's mainly about speed to market and customer-centricity. (video recording)

All big organizations, even so-called "flat" or "networked" ones, are usually quite hierarchical in decision making. Any talk of Holacracy, Teal etc. is unrealistic in these places. In this presentation, Sriram argues that the underlying problem is not hierarchy itself but the opaqueness of decision making which is known to persist even in the absence of a formal hierarchy. He presents Cleararchy as a way to bring transparency, and thereby accountability and learnability, to decision making. This is necessary for decentralized decision making and true empowerment at lower levels of a big organization.

Organizations that flourish in the digital economy will be the ones that learn to operate differently. They will be able to exploit short-lived opportunities by adopting an operating model geared for responsiveness over cost-efficiency. Although all organizations will face the pressure to make the transition, only some will succeed. Among other things, it will require a blurring of organizational boundaries between business, digital, product, and IT. It will also require a change in management and governance culture. New and native digital businesses will lead the way in demonstrating new operating models and the incumbents in the market would do well to adapt them to their larger scale operations.

Lots of funds are being made available for digital transformation and there is no lack of effort to transform. However, there is a lot of misguided effort. This session will describe common anti-patterns of digital transformation and suggest ways to remedy them.

Key Takeaways

• Understand the drivers, size, and scope of digital transformation efforts in the industry as a whole.

• Glean insights on non-intuitive anti-patterns of digital transformation and their remedies.

• Avoid expensive mistakes by learning from the mistakes of others.