Why Go Agile?
Agile Transformation is a hot topic at the C-suite today. There isn’t a financial services company not investing in scaling up their Agile capabilities; however, clarity in reasoning for going Agile is often lagging the urge of acting.
The conventional wisdom suggests that going Agile is a way to achieve faster time-to-market, higher quality, enhanced customer experience, and most recently, better economics in the Digital era. Unfortunately, these broad brush convictions may lead enterprises to scale up their Agile capabilities for the wrong reasons, and cause major disappointments. There are already examples of enterprises invested hundreds of millions of dollars into a wholesale Agile transformation initiative with very little to show after a year or two.
What lies in the heart of troubled attempts of scaling up Agile is the misconception that Agile IT Organizations are generally faster, better and cheaper than their traditional, Waterfall based, cousins. I will argue that the Agile and Waterfall methodologies have no-overlapping applicability. Like a screwdriver and a wrench, the job at hand determines which one to use. When used for the right purpose, they can both deliver excellent results.
- The Waterfall methodology is best executed by the traditional Project Organizations. Organizing work in terms of discrete projects is the most efficient and proven way of delivering business change when the target is fixed, i.e., the speed of change is low, the desired outcome can be defined at the onset of the work, and its value has longevity upon completion of the project.
- The Agile approach requires a Product Mindset to flourish. The emerging breed of Product Organizations are most effective when working on a moving target, i.e., the speed of change is high, the desired business outcome is constantly evolving, and an effective feedback loop from the customers, the market, and the IT ecosystem is guiding these organizations to continuously deliver valuable business change (see Is Your IT Ready for the Digital Revolution for details).
Figure 1 - Productive Efficiency of IT
The new Digital Enterprise IT is based on an artful combination of both of these approaches. By selecting an appropriate approach and organizational construct for discreet components of an overall solutions, the Digital Enterprise IT organizations maximize their impact. For example, a project construct would be more successful in implementing an Omni-channel regional core banking platform framework, while product teams develop the market specific, customer facing modules and third-party interface extensions.
To clarify the above assertion, I will use the productive efficiency concept from the Economic Theory, which describes a situation where the economy could not produce any more of one good without sacrificing production of another good (Source: Wikipedia). In the context of the Enterprise IT, productive efficiency means the situation where an IT organization cannot deliver any more of one business change without sacrificing the delivery of another. By employing different methodologies like Agile, Waterfall, Iterative, etc., IT organizations can dial up or down the frequency of their change releases, but they cannot improve the aggregate volume of changes they delivery. For example, an annual release of an ERP like enterprise software delivers a large volume of business change at once, while frequently upgraded websites or mobile applications achieve a similar result in multiple small steps (see the productive efficiency line A in Figure 1).
On the other hand, different productive efficiency lines indicate variations in performance. Line C in Figure 1, for example, indicates a higher performing IT Organization level than line A. These performance differences primarily relate to the effectiveness of the underlying IT operating model, e.g., product portfolio, organization, governance, process, tools, etc., and not to the methodologies in use.
In summary, the Agile and Waterfall methodologies are two complimentary tools that every IT organization needs to master with. A wholesale adoption of one methodology over the other is inherently sub-optimal, and no methodology can compensate for deficiencies of the underlying IT operating model.
Program and Project Manager, FinTech and Financial Regulations Expert, Agile Coach and Scrum Master.
6 年Hakan, you make an interesting point however having many years of experience both as a "traditional PM" and Agile coach, I think you are over simplifying and missing some key points. Happy to discuss! The most important point here is that "Agile" is a collection of cultural changes and practice patterns which need to be implemented to suit the organisation, culture and specific problem - in fact its more like having an entire toolbox with many different tools and fittings. Agile is NOT a "methodology" and probably any experienced PM will tell you that "waterfall" is an over-simplification which never happens in real-life, instead we use various techniques to maximise delivery and minimise risk.
conceptual art and experience design practitioner & teacher, participatory design, cooperative learning, non-conventional facilitation, systems, agile communities, Sanskrit & Pali studies
6 年An interesting thesis, Hakan, were it not that your analysis strikes me as utterly mechanistic and based on the assumption that change occurs either in quick iterations OR in big steps. In reality, it seems to me that big leaps might as well occur at high frequency, it which case your model collapses. More alarming in your theory is the absence of the human factor. Agile is not merely what you say it is. Much more, it is a mindset, an approach to customer focus and servant leadership and organising a community of people in such a way that enough agility of mind is present for its members to find value in persistent change - whether this change occurs in quick iterations or in big leaps, or both.
Performance Coach in Business | Strategy & Flow Agility | Professional & Team Coach (ICF) | Director of Thought Leadership in ICF UK
6 年Though your observation is quite correct and well put, I am not sure that I would conclude that both approaches are good and especially that they could coexist. Even for an ERP, a product mindset can help. I worked with a company in the past where the HR System was unworkable for usability perspective. How much time was wasted at review time. The issues with those transformation is shifting the Leadership mindset to a product one. To do so you have to remove a lot of waste in the system (generally resulting from project mindset). Most fail because the focus is on getting the teams to operate in Scrum, whereas the real deal is getting the leadership to think Lean-Agile-System.
co-Founder / co-CEO ekoIntelligence | vegan
6 年Paremus has had manner years experience in this area. Typically we've seen the following. 1. Companies fail to realise the benefits of Agile because their codebases area Monolithic. A tangled knot of unsupported Open Source libraries. Hence even small code changes are complex, an so potentially high risk - as the effect of a change can bleed through the monolithic structure. 2. To try and address Organisations are now told to look to Microservice. BUT this results in significant increases in Operational Complexity - as Microservices need Orchestration. Also the constraints imposed by HTTP/REST may be unacceptable. 3. To address the Orchestration Complexity issue -- Organisations now turn to DevOps: but this results in tightly coupling the Development teams to runtime Business Service. This is BAD for Governance and exposes the Organisation to the `Wet Ware Crisis`a.k.a `Dead Sea Effect`. 4. To make things worse - Container Orchestration solution are Operational Extremely Complex and so Operational Fragile. Kubernetes will go the same way as OpenStack - an Operational liability for real Enterprises with multiple sophisticated Business Systems. So what to do? You really want to be Agile? 1.Then start by adopting an Industry Standard for Application Modularity, and enforce this discipline on your development teams. 2. Use a runtime platform capable of supporting highly modular business applications - WHILE AT THE SAME TIME - shielding Operations from complexities involved in dynamic service Orchestration / Service Assembly. You have succeeded when you have Business Agility, Operational Simplicity and a high level of Governance and Service Robustness.
Yes, and since hardly any organization can keep itself from not going digital...its gives them a good opportunity to revisit and see the effectiveness of their current operating model before rushing and adopting new methodologies such as agile.