Has leading-edge Software as a Service (SaaS) development moved beyond agile?
Has leading-edge Software as a Service (SaaS) development moved beyond agile?
As Software-as-a-Service products evolve, how teams approach development is moving beyond agile. What can enterprise IT learn from this?
One of the most exciting challenges of my career involved leading teams, building, and supporting products operating in many countries and used by millions of users daily. This was when big-name global competitors were entering our markets and taking market share at an alarming pace. The different scaling factors (multiple markets, millions of users, new competitors) led us to adjust our practices to remain competitive. More on what we did later.
Most software development teams do not work on a successful, highly competitive Software-as-a-Service product. They don’t need to scale what they have built globally, and they are not engaged in fierce competition with heavily funded and excellently competent competitors. Most are not fighting existential battles for market share for which their relevance is at stake. I.T. teams of today, nonetheless, are faced with many challenges, and each has its context. It just means the forces shaping their practices are different, and changing those aspects of development may be less urgent.
Many organisations are just now exploring ideas around focusing on customer value and working in an agile, adaptive planning way. And chances are they still aren’t sure. They are likely facing the challenges that lead most IT teams along the path of working on smaller increments, which they validate is achieving what they hypothesise.
For instance, they may be experiencing ever more frustrated users, whether internally or in the market, as the gulf between what they are delivering and what the users need or expect widens. They may be releasing significant amounts of change after very long periods in disruptive Big Bang releases that fail to address the things being cried out for.
Many I.T. teams have found themselves flat-footed. The rate of change of relevant technologies has continued to accelerate in the enterprise and even faster in the consumer space. Not only are companies losing relevance, being opened to strategic threats by smaller, nimbler organisations adapting faster, but they are also feeling the effects of their users’ expectations rising because of what they are becoming used to in their personal lives.
I explore this idea further in:
Compare and contrast the average I.T. team with leading-edge Software-as-a-Service organisations.
I find the comparison between where the late majority of I.T. teams are adjusting to external factors and leading-edge Software-as-a-Service organisations interesting. It is not a fair comparison, but SaaS organisations may offer a directional vector, indicating where highly effective I.T. teams might need to evolve should the pressures of change continue at the current rate.
Some organisations have attempted to undertake digital and agile transformations but failed to realise the benefits. Common failure patterns include:
copying agile ceremonies without understanding the purpose.
holding on to practices that contribute to the organisation being unlikely to adapt even as it learns new information.
applying agile practices in contexts that warrant different approaches.
applying cookie-cutter changes across the organisation that failed to consider the context for the different parts of the organisation being changed.
The rest observe these missteps and struggle to navigate a path that makes sense for their organisations. They are experiencing the challenges and know change is needed, but a mix of risk aversion, cautionary tales from others and a disconnect from the forces that shape the necessary form they require to succeed.
Let’s dive into that last point. I hypothesise that the likelihood of change is a function of the amount of direct feedback from market forces and the effects of how successfully the software meets user needs. In organisations where I.T. has become a cost centre, the exposure to these signals has significantly dampened. The I.T. team may receive the signal of unhappy users (especially internal users) but is often disconnected from immediate consequences.
Other parts of the organisation are likely more directly exposed to the consequences. For instance, sales teams are measuring their sales or lack of very closely. Customers are sharing their needs or their objections. Sales staff who underperform miss out on a bonus or are let go. The consequences are tightly connected with what is working and what is not.
I.T. teams are often shielded from these signals. They exist in organisational siloes. Information may not be available. They have established their priorities based on a more narrow understanding of what they are responsible for. They have adopted project-centric practices for managing software changes. Many barriers can come between I.T. and a more immediate sense of what they are and are not having success with.
In a SaaS organisation, the development team often works directly on the product. It has immediate access to the usage data and can, with a small effort, have some understanding of what effects what they are building is having on users. Many take this further and work with product, design and research teams to directly engage with users and purchasers of their services.
Whether startups or incumbents, SaaS organisations tend to be intimately involved in the metrics that drive their organisation’s performance and their competitive position. Or they don’t survive too long.
This suggests that exposure to or establishing feedback loops is critical in supporting appropriate adaption. Agility is an element of this, but more is needed regarding how popular agile approaches are currently conceived. Most agile methods use a combination of completed work, delivery metrics and feedback from users (or proxy users) to guide the work.
In SaaS businesses, it’s common to see just about every aspect of how users experience software instrumented to simultaneously provide feedback on many dimensions. At scale, minor improvements can have significant impacts in terms of the financial machinations of the business. As SaaS products mature, the nature of this work can start to look much more like the reduction of variation, which is the focus of methodologies such as Six Sigma.
In a more typical enterprise I.T. environment, there is a presumption that delivery and user needs are predictable, repeatable, and the work deterministic - we can predict the consequence of each action. There are, of course, scenarios where each of these aspects is true, but there are also increasing scenarios where it is not, which is the source of the rising friction these teams experience. In agile team environments, there’s the assumption that nothing is predictable or known, and the iterative approach supports the opportunity to validate at short intervals the value is being realised.
In this post-agile scenario, the underlying need to iterate and validate remains, but the dimensions and expectations of attributes for the qualitative elements of the experience software provides users are knowable. This is a similar phenomenon to commodity electronic components or any commodity. For instance, we may know that to compete in our field, our services must be available to ‘four 9s’, i.e. 99.99% of the time. We may also know that for users to use the service pleasant, we need sub-second page renders and the first bit to be delivered almost instantaneously because all competing services also provide this experience. Familiar user interface paradigms must be leveraged. The system must have a certain level of reliability and resilience and few defects.
I observed this trend in my experience leading a suite of successful SaaS services engaged in heavy competition for market share dominance where we were the defending incumbent. We were constantly improving our understanding of our place in the marketplace in relation to our competition. Our understanding of what our customers and users value about our offerings. We had almost every aspect of the experience instrumented such that we could see the effects of any change we made and understand the intended and unintended effects.
Lean and agile software development principles led us there and helped us be competitive. We had to experiment with and adopt additional practices that are not always synonymous with agile development. We had to integrate design, research, goal-setting, KPI measurement, observability and alerting capabilities, which could give us the visibility we needed to survive heavy competition.
I find it such an interesting contrast where many I.T. teams are just now exploring the onramp to more agile ways of working that elsewhere, technology teams are engaged in practices that could be considered ‘post agile’. In an I.T. environment where the nature of services delivered is also more commodified, there may be more to apply from this experience to these contexts.
Simon Wardley, a former executive who leads technology companies, is the creator of Wardley Mapping. This Technology Strategy tool can help groups of people align on their understanding of the technology landscape for their organisation and their competitors. Mapping establishes situational awareness by capturing what is known about technology components used by the organisation and its competitors, suppliers and other actors. It supports strategic decision-making, such as when to buy or build, what practices may be appropriate and many other critical decisions.
Wardley also established a doctrine of universally helpful principles as part of his approach. One of the principles is ‘Use appropriate methods’. As I highlighted earlier, a common failure of organisations adopting more adaptive strategies to delivering valuable software services was to apply agile practices even in contexts where it was inappropriate.
Wardley predicts such evolution of practices with his Wardley mapping approach. Wardley’s mapping theory suggests that all technology is a function of components at varying stages of development combining to address a user need. As pieces evolve and commodify, they take on different properties, and the associated practices for managing these components also change.
And so, it predicts the evolution of software development practices. In a SaaS environment where the proximity and access to feedback are plentiful, the focus is necessarily on outcomes because to do otherwise risks survival. The feedback connections are reduced in traditional I.T. organisations, which exist as a silo.
But need it be this way? After all, I.T. organisations are this way because of essentially path-dependent factors. Cost-centre accounting practices have helped contribute to the siloing of organisational functions, as have activity-oriented project management practices that examined benefits and value as a trailing activity rather than a primary signal of progress to guide what to prioritise along the way.
The practices I describe in this publication are natural evolutions of what has come before. The rise in complexity confronting Technical teams from the progress of Technological innovation, rising expectations from users, and the proliferation of Technology in all aspects of business is driving the need for more value-oriented practices. These practices emerge in high-pressure environments such as SaaS but are relevant for today’s enterprise I.T. teams struggling with their organisation’s and users’ demands.
Over the last century, key trends in how organisations approach work have created conditions where value and outcome-oriented practices have taken a back seat to activity-oriented approaches. In simpler times, where I.T. had a narrower focus, and users had lower expectations of what was possible, this proved an adequate approach for many organisations.
Do you agree with my hypothesis that competitive SaaS product companies are evolving to practices beyond what agile software development was conceived for? Do you agree with my second hypothesis that there are valuable lessons for today’s enterprise I.T. teams can draw from observing the practices that emerged from SaaS? Share your views in the comments.