Dilemma of an Agile Coach

As an Agile Coach, we often interact with our customer predominantly in two modes – as paternalistically or as an information provider. While working in paternalistically mode we treat customers as kids who need to be told what is good for them and what to do to achieve success. Consider a scenario where you are trying to convince your customer to embrace Agile and explaining the benefits they will get from it.

On the other hand, when we are acting as an information provider, we just hand out the information to the customer (yes, sometimes we overwhelm customers with information) and ask them to make a decision about something about which they have little or almost none understanding. Explain the difference between Scrum and Kanban to the CTO without encouraging him to experiment with a small set of teams. Now CTO has commended – All development teams will follow Scrum while Support Teams will move to Kanban.

In both of these cases either we as an Agile coach playing the role of Know All or of a consultant - I gave you information, you decide. Both of these approaches may lead to not so optimum results.

There is also a third approach, which I learned from Being Mortal by Dr. Atul Gawande. Dr. Atul talks about patients which are terminally ill. There are few medicines and procedures are available which may extend the life of the patient but it has consequences in terms of financials, longevity gained, and quality of life.  In these situations instead to being paternalistic or being a consultant, he has to lay bare all the facts and consequences of each decision patient and family can make. Though the final decision to be made by patient and family, he plays a dual role of facilitator and information provider. Sometimes patient and family make a decision of not administering the medicine or accepting the medical procedure which is very much against his Hippocratic Oath – save lives at any cost. Though as an Agile Coach, I hope none of us has to be in midst of such a difficult situation but we may have to suggest Agile is not the desired approach in some cases. I admit in this approach, I as an Agile coach has pay dual role of facilitator and information provider while agreeing with a decision which goes against my very belief – Agile is for all in all situations.

What do you think?

Is Backlog Refinement a linear continuous activity?

Whenever we hear about Backlog Refinement, a picture emerges - team is meeting regularly and refining the stories and feature. This event may happen once or twice during a Sprint. Is this picture depicting the whole reality? No! I think in reality is little more complicated and not so smooth.

Refinement is a continuous activity with a context-specific combination of once-off big events and regular events. Think about your home. You invest in the daily efforts to keep it clean. Also, on weekends, you look into kids’ room to make sure it is clean. And then you have garage cleaning sale in the summer. On similar lines, during a sprint, you focus on stories and maybe some features. Once in a month (duration depends upon context), it’s the turn of Features and maybe some super important Epics. Once in two months or in a quarter (again duration is context dependent), the Epic time arrives. 

In summary, Backlog Refinement is a continuous activity with some combination of once off as well as regular events.

What do you think?

DevOps and Agile with Prefixes and Suffixes

What is the latest buzz word you have encountered which has Agile or DevOps in it? Is it devSecOps? Is it Agile Project Manager? Is it Agile Developer? is it Agile Design? is it Agile Methodology? is it DesignOps? ...

It seems every marketer is pouncing over the success of Agile and DevOps. 

Let's try to decipher these terms.

Agile certainly kick starts and sustains incremental improvements. DevOps is in its all simplicity an idea where Dev and Ops collaborate (level of collaboration may vary widely) and focus on fast delivery of increments with the highest possible quality. To maintain a small delivery cycle, automation plays a mega size role. 

The meaning of design varies as per the context. For a product designer in social media space, a design may imply how a customer is interacting with the product while for software architect design may refer to - how the code is organized & written and usage of components & libraries.  It seems to me DesignDevOps or most of XXXDevOps, DevXXXOps, and DevOpsXXX are very similar to XXXAgile and AgileXXX - marketing attempt.

For convenience purpose, I visualize Agile is something which focuses on people, governance, and processes with a sprinkle of contemporary engineering practices while DevOps' focus area is a collaboration between Dev and Ops with heavy doses of contemporary engineering practices and automation. Maybe the term of my preference is AgileDevOps (yes I am guilty of AgileXXX and XXXDevOps).

What do you think?

Leadership and Change

While surveying literature in organizational excellence, I notice a significant emphasis on reliance on leadership (a few persons as a noun not as an act or thought process) to bring a change in an organization. The whole organization looks toward select few who are in the position of authority due to appointment to bring in the change.  Everybody looking toward a few for the solution.

Does this culture smell a broken and rotten thought process? Do we have outsourced our thinking process to select few and become intellectually lazy? We need a ready-made solution. Someone else should do the thinking and analysis, we will just enjoy the fruit of success and/or become arm-chair critic during the change. Does excessive reliance on leadership is one of the manifestations of this phenomenon?

Or due to the complex nature and size of the organizations, few of the motivated people (generally in the position of authority) take charge of directing the course and even determining what the success is.

I think the truth lies in the combination of both arguments. What do you think? Are there any other arguments?