JUGAAD

I attended a seminar on Kanban ( A Japanese concept related to lean and just-in-time (JIT) production ) this week and was pretty much impressed by the Japanese way of Management. This made me think, if there are any business theorems that have originated in India . That is when LD told me about the "JUGAAD" theory that is currently brewing in business circles.
Wow !!! Interesting !!! That was my reaction when I first heard of it. I instantly mined the internet and I found an article published on Harvard Business Review

Below are the excerpts from the blog:
Frugal innovation is a hot topic today as post-downturn corporate America looks for ways to do more for less, while serving broader markets. This will require practicing the gutsy art of Jugaad. The Hindi term roughly translates as "overcoming harsh constraints by improvising an effective solution using limited resources". We call it the art of creative improvisation - within a framework of deep knowledge and experience.

Over the last five years, we have studied and interacted with scores of entrepreneurs in India and beyond who practice Jugaad to understand their mindset and innovation principles. We find that Jugaad-minded entrepreneurs turn adversity - such as widespread scarcity of natural and financial resources in India - into an opportunity to innovate and create more valuable products and services at less cost for more people.

Through our research, we have identified four operating principles or innovation rules:
Thrift not waste. This first rule - which promotes frugality - helps tackle scarcity of all forms of resources.
Inclusion, not exclusion. This second rule helps entrepreneurial organizations to put inclusiveness into practice - by tightly connecting with, and harnessing, the growing diversity that permeates their communities of customers, employees, and partners.
Bottom-up participation, not top-down command and control. This third rule drives collaboration. CEOs who tend to act as conductors must learn to facilitate collaborative improvisation just as players in jazz bands do.
Flexible thinking and action, not linear planning. This fourth rule facilitates flexibility in thinking and action. Jugaad-practicing firms are highly adaptable as they aren't wedded to any single business model and pursue multiple options at any time.

I kind of agree to all of the above but would give more weights to the last 3 principles. Here are my 2 cents on this theorem.
When I think of Jugaad the first thing that comes to my mind is "Socializing".When they use the term Jugaad in India, it refers to how better you use your Social contacts to get things moving at the time of a crisis situation. This refers to the second and third principles that if we can get all stake holders in a FIRM to collaborate, with a sense of ownership, given a situation, then there could be better ways you could think off to make the best of the situation. But in order to get this implemented, you need to identify a benefit for every participating stakeholder. This is what we say a "Win Win Situation" for all. and this can be achieved by "Flexible thinking and action". Getting all of this in place is very essential to get this model moving. And again "Jugaad" is an art that a person develops while handling adverse situations. It is the ability of an individual or a team or a company to come out smiling overcoming harsh constraints.

I am sure all of you will have more to add when they hear this term. Your thoughts / feedbacks / suggestions are welcome

MODENA

Method for Open Dynamic ENgineering of Applications

Characteristics

MODENA differs from SCRUM primarily in the following ways:

no Storypoints, estimations and plannings are done in PDs
no Sprints, the items are permanently prioritized in queues
There are still estimation meetings, retrospectives, reviews and a product backlog. And there are queues.
There might be several competing queues. It's the TeamMasters job to merge the results of the queues into one MODENA queue. The development team will start with a bunch of items (transferring them from the product backlog to the MightBoard=MODENA white board[2]) and implement them.
If an item is finished (that means specified, implemented, tested and documented), the next item will be started. If a bunch of items is finished, a new bunch of items is transferred to the white board. Items which are not approved will stay on the board.
If at any time (in any test stage) a bug occurs, the current work is stopped and the bug must be fixed before continuing.

Consequences
Implementing the method should have the following consequences:

Instead of starting and stopping the development process and energy for every sprint, the queue mechanism allows a continuous and flexible prioritization of items.
The implementation of items can be requested without the need to wait for one sprint-cycle to end. 3 weeks before a new release, the process is stopped to allow the final testing and documentation.
Items must be approved by the item owners as soon as they are finished by the development team. MODENA is supposed to lead to an easier synchronisation between the teams. The queue mechanism allows a continuous and flexible prioritization of items.

This method seems to be better suited for the ongoing development of applications, that are delivered as releases. For smaller projects or projects with a definite end-date, Scrum still seems to be the method of choice. In any case, Scrum is an established development method, Modena is younger and has to prove itself within the field.

In our environment I suggest the Support team can try adopting this approach for CI activities.