Agile Roles and Responsibilities - My Key Note from AGILE NYC Conf held on 11/17

I attended the NYC Agile Conf yesterday where Dan Mezick was talking about BART (Boundary, Authority, Role, Task)


This Topic in iteslf is very obvious given the fact that every book on agile (or any process) would say that you need to follow all rules to the T to make it work.
And of course, why not, the great minds behind the Agile Manifesto must have put loads of thought to write these responsibilites for different roles in an Agile world.

So now coming to the big question "what were the key take aways if the topic of disucssion was known".
I would say the the one thing I would like to write about after this session is to take a pause and "RETROSPECT".Let me explain.
When we kick off a project in SCRUM and put a team in place, we jot down a certain set of rules for the team to follow. The team then agrees to follow many of these rules and

takes up the responsibilities at will. They also start adhering to it religiously in the beginning. All good so far.

However down the line, there will be several instances when somebody in the team would drop the ball in doing what it takes for the team, given the responsibility he / she has.

And given our human nature there is this somebody who will back fill for this person and take up those responsibilities.
To give you an example there was this team where a senior team member, who was the tech Lead had taken up the task of facilitating all team meetings as the SCRUM Master (being

from the senior leadership) was not able to do that due to lack of bandwidth. Now such kind of instances are very common with every team, as we evolve and adapt to situations

and that is what we call team rythm in scrum.

So is such a kind of Rythm good or bad. Ofcourse like I earlier said, to make a process work, you need to follow every rule to the T.
The Verdict - We need need to avoid this as much as possible and if it is already happening to a great extent then we must plan to take corrective actions. But many a times we

just let it go because the team is delivering expected results and we are hesitant to make any changes fearing that it will reduce velocity. But if we just give this phenomenon

a deeper thought then it would make sense to put things in place even at the cost of a reduced velocity for a few sprints as it is bound to give better results later.

Well apart from this there was in teresting quote that came up during discussion in this Session.
" SCRUM Master is the Team's Mother". This topic in itself is so interesting and vast that I will be writing a separate BLOG to express my thoughts.
Till then Adios

- Nikhil

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.