Introduction
Jugaad is an attitude towards delivery which originated in India and consists of three simple tenets:
- Humility: use whatever works without prejudice
- Openness: keep your options open
- Frugality: small expenses keep regrets small
Jugaad is agility taken to the extreme and most suitable for projects with a high degree of change, risk and uncertainty. Nothing demonstrates the essence of jugaad better than the homonymous improvised vehicles built in India. All essential mechanical parts lay open and are easily accessible instead of being enclosed in casings. The vehicle can be assembled from commonly available, repurposed parts. It can be customised and extended to fit a variety of personal and professional needs, workloads and environments. The choice of parts can adapt the jugaad vehicle to different types of terrain, usage, fuel and availability of parts.
Disclaimer
This post is not the result of studying literature, most of which seems to have been written around the peek of the jugaad hype in 2010. It rather distils the experience of a decade working with delivery teams in India, what I learned from their approach to delivery and from being immersed in Indian corporate culture. Through large parts of this post it may seem that I advocate the adoption of jugaad and the abolition of other agile methods; the opposite is true – I will try to make the point that the wholistic approach of jugaad to solution design should be paired with the tactical discipline of a framework like agile or XP.
The tenets work together
The three tenets (Humility, Openness, Frugality) complement and contradict each other in a beautiful way: Humility generates options for a solution, openness guides and combines them and frugality eliminates them. Only solutions adhering to all three tenets are built in the jugaad spirit.
Humility: use whatever works without prejudice
Delivery methods like Waterfall, Scrum and XP wage religious wars over definitions (eg. what is the right sprint length?), processes (eg. degree of upfront planning), skills (eg. which framework should we use) and tools (eg. Maven or Gradle) all of which are more or less derivatives of adherence to a method. Jugaad replaces those definitions, processes, skills and tools with a central guidance: be conscious about the shortcuts taken with respect to the two other tenets. Jugaad frequently comes with a high degree of “out of the box” thinking and requires, for it to work, the humility to let go of technical and methodological preconceptions about what is the “appropriate” way and focus solely on the result.
Humility is the starting point in jugaad in that using “whatever works” generates a plethora of options. So how do we choose amongst these options? That is where Openness takes over.
Openness: keep your options open
The ostensible carelessness with which jugaad approaches delivery is built on the solid foundation of Openness. Whatever we build should be easy to extend, change or reverse. Openness often lacks elegance and conciseness, the inner workings of things are exposed, there is not much polish and one can see the parts a solution is made of – not to mention the security concerns arising from such solution. Just think of the jugaad vehicle we talked about earlier if you need a mental picture. But those trade-offs enable easily modifiable solutions and are exactly that: conscious trade-offs, not shortcomings. A solution which is open to change is a solid project or product foundation as it can adapt to unforeseen changes and doesn’t require much up-front design. Openness takes Humility’s options and guides them into coherent patterns. Not all options will form a good solution and not all combinations of options will work; Openness tells us which of them might work without losing an arm and a leg in the process of finding out.
Frugality: small expenses keep regrets small
Frugality is about risk management: reducing upfront costs now allows exploring more value propositions and solution approaches now while spending resources later on improving the solution. A low cost incurred early jeopardises a project less than a large cost incurred at the same time, especially if whatever that cost bought us turned out to be the wrong thing. Frugality is a holistic view on the patterns guided by Openness – it takes into consideration synergies between options and maximises value, both in terms of business value created for the solution (how many of the requirements were implemented at what effort) as well as value added to the project delivery (how much delivery and quality was improved, what was learned etc).
Comparison by example
Jugaad is illustrated best with a couple of examples which contrast traditional, “proper” design with improvised jugaad design.
Example: receipt system
Design a system that generates, stores and sends receipts via email to customers. Customer support should be able to retrieve receipts.
The traditional, “proper” solution: we program a system that stores receipts in a relational database, generates receipt PDFs, stores those PDFs in the database, sends the PDFs to customers. We program a web interface for use by customer service which can query the database for receipts.
The jugaad-engineered solution: we program a system that generates HTML receipts, emails them to customers and BCCs a customer support email account with the same receipt. Customer support can use their email client to retrieve receipts. These components are either packaged and require no development effort (Customer support E-Mail client, E-Mail server), there a only few components and they are easy to implement.
Let’s evaluate the jugaad-engineered solution against jugaad’s tenets and compare it with the “traditional” solution.
Humility: the design relies on packaged components which probably already exist and it only minimally invades the existing IT landscape. It reuses high quality packaged solutions (e-mail server, e-mail client) which may already exist in the organisation and reduces implementation tasks to e-mail server and e-mail client configurations. The traditional delivery method places several requirements on how the solution is built: it mandates formal APIs, probably a particular technology platform, a pre-defined method according to which components are structured (eg. SOLID), technical documentation and thorough test automation long before it is clear that the project will make it into production, but nevertheless increasing conceptional and real complexity of the solution and the delivery process and requiring an increased skill set for project participants.
Openness: the e-mail protocols between the application, e-mail servers and e-mail clients are well understood and extensible. Using E-Mail clients requires low to no training and the IT department probably maintains them already. The components themselves can be substituted without affecting much the rest of the solution; eg. a new field can be added to future receipts without modifying already issued receipts. Because many components can be operated by human agents (the e-mail server and e-mail clients), many new features and workarounds can be implemented as manual processes before coding and automating them into software. Since not much effort has been put at the initial stage into upfront design there isn’t much effort wasted when requirements change and implementations follow.
Frugality: the use of packaged components, especially when they are already familiar, reduces implementation effort and speeds up delivery at the cost of the finished product showing incongruities where different components interface. New requirements needing larger changes can be implemented by exchanging existing components for components better fitting the requirements or even rewriting them from scratch, if needed. In many cases the early progress made thanks to the low initial effort should more than make up for the higher, later cost. The traditional solution contrasts badly with jugaad in terms of effort. For example, it will mandate a particular API design such as a REST API for the receipt generator and receipt retrieval or even a REST API between the receipt generator and the email server, because… principles. Technical documentation will be written for the components long before it is clear that the project will ever go live, not considering that any effort spent on non-value adding features jeopardises a go-live. And last not least unit tests will be written to achieve an arbitrarily agreed upon test coverage before it is clear that they generate business value eg. by catching regressions. The jugaad-engineered solution will produce formal APIs, documentation and test automation when their added value outweighs the implementation effort.
Contrast with agile
Jugaad has no processes like Scrum or XP. It talks about the values worth striving for. It doesn’t talk about velocity or quality; even the focus on low cost introduces the discipline to achieving openness, thus being able to revisit a previously built solution. Agile highlights reactiveness, it’s main point being the ability to react to unforeseen changes, but it uses a predefined process such as Scrum or Kanban. The process must adapt to organisational changes or changing skill sets. Jugaad does not dictate any delivery process, so in a way it is orthogonal to existing agile practices. By adding formalised steps to it, a mature jugaad practice may evolve into Scrum or Kanban if that seems useful.
But jugaad is not about agile without processes – it’s central theme is the combination of Humility-Openness-Frugality which is in great contrast to the often purely iterative approach of agile practices. The famous [citation needed] quote “the light bulb didn’t come from iterative improvements of the candle” hints that product development requires the guidance of a vision and a master plan. Without that, incremental feature improvements will necessarily diverge and produce a product nobody needs.
Scrum, for example, builds on the idea that increments should be small. This idea has lead in practice to several consequences such as user stories (to keep track of small increments) and test automation (to reduce testing effort for regressions as small increments mean frequent deployments). An often voiced critique of Scrum is that it doesn’t offer guidance on the vision – keeping increments small is good tactics but bad strategy. Jugaad replaces the small increment doctrine with Openness – an increment can be vast (eg. by replacing a custom component with a packaged application), as long as it is easily extensible or reversible.
Extreme programming (XP) focusses on delivery tools and methods; the underlying idea is that by improving delivery skills the product quality will improve automatically, thus technically skilled teams will magically deliver good business value. The same critique as for Scrum applies here, too: XP doesn’t guide the vision. A jugaadian criticism of XP would be that XP’s focus on discipline and quality, rather than the result, spends too much effort too early on everything related to delivery but the product itself.
I’d like to give an example of a very useful technique that jugaad applies which is considered heretic in agile: mocks. A functionality consists often of UI and backend logic. Agile demands that the implementation of a user story requires UI, backend and test automation to have been implemented; and then users reject the UI or find a flaw in the requirements and much of the implementation effort went to wast. Modern techniques like user journeys and design workshops catch this error potential early by first delivering mocks of the UI or stubbing backend logic in order to verify acceptance with users before investing time in a proper implementation.
Consequences for project organisation
A project which applies jugaad doesn’t look different from any agile project from the outside, but it feels much differently for those involved. My own experience working in teams that (unconsciously) practised jugaad was often unsettling as I mistook it for a badly applied Scrum or XP or even the absence of any concrete delivery method.
The first difference one notices is the absence of opinionated debates about definitions, processes, tools and frameworks which elevates Humility from a delivery tenet to a way of life. Team members rarely insist of doing things in a particular way, there is a notable absence of not invented here syndrome and an absence of competition and aggression at the work place.
The second difference is that decisions aim at being easy to implement, easy to understand, easy to reverse if necessary and bring synergies – Openness at play. The team considers the consequences of implementing an option, always thinking a step ahead, which (at least for me) addresses my long-standing concern with Scrum that it turns teams into conveyor belt workers. Decisions never claim to be guided by the most wise and rigid principles; quite the opposite, actually! Teams practising jugaad are aware of the risks and shortcomings, that is why they pick easily extensible or reversible designs.
A third difference is that effort, not size, guides decisions. Where Scrum requires that increments are small in terms of functionality, jugaad requires that increments are small in terms of effort. A small increment in Scrum always requires a small increment in functionality, otherwise it would not fit into a user story. A small increment in jugaad means that the effort spent was low, even if it means that an entire packaged application suite was just added to our product, increasing functionality by a ten-fold.
The fourth difference is that, often, teams practising only jugaad will often have initially bad delivery skills. With all criticism of agile methods a negative effect of jugaad should be mentioned, though: Scrum, Kanban, XP etc. train technical skills, organise delivery and have opinionated answers to how something should be done. Jugaad’s wholistic approach to solution design and absence of tactical guidance doesn’t help build those skills and discipline necessary for delivery in technical projects.
Conclusion
Jugaad’s tenets guide projects into making choices which maximise flexibility and minimise future regret, not by making wise up-front choices, but by minimising the cost of such choices. Jugaad leads to good and cheap choices, but requires a delivery methodology such as Scrum or XP to implement said choices.
Update 14 September 2020: discussion on HN about this post.
George's Techblog 