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?

Story Mapping in SAFe

A backlog is essentially a one-dimensional list of requirements. This list does not convey a lot of information. There is no notion of workflow which makes it extremely difficult to recognize gaps in requirements. Story mapping visualizes requirements in two-dimensional space which helps in the discovery of gaps in requirements, grasping the progress of value delivery, prioritization of requirements for a hierarchy of requirements. 

In a small engagement where only one team is working, Story Map is quite simple to construct and evolve. 

In a single team scenario Story Map may look like:

 Figure: Functionality View of a Story Map

In case of big engagements few complexities arises:

1. Hierarchy of the requirements: It should also be noted down that in any enterprise-class engagement, requirements form a hierarchy (Epics --> Features --> Stories). 

Figure: Hierarchy of Requirements

2. Multiple teams working in parallel to deliver value: In any enterprise-class engagement multiple teams work in alignment with time limitations and business & technological constraints to deliver value.

Figure: Multiple teams in a collaborative environment to deliver value

3. Scaling Framework constraints: Almost all scaling frameworks impose some constraints (and/or suggestions) which affect Story Map. For example SAFe framework, there are few recommendations and suggestions which affect the structure of Story Map: 

• Size of a Story --> To be delivered by a single team in a single Iteration
• Size of a Feature --> To be delivered by a single ART in a single PI duration
• Size of an Epic --> To be delivered by a single Value Stream in couple of PI duration
• Lean Startup style development using MVP and MMF
• Release may follow a predetermined Release Cycle or Release on Demand

Keeping above in view, lets’ construct a Story Map for an engagement which is following SAFe framework with a periodic release.

Construction of a workable Story Map

Our engagement is about to start.  You have some ideas around the “WHAT” part of the product though these ideas may be in a fluidic state.

Stage 1: In starting, few big initiatives and epics are known. Write each Epic on a big sticky note and paste them in a horizontal line on the wall.

Figure: Epics on the wall

Stage 2: It is time to add some details. Assemble Product Managers, Architects, Systems folks, Product Owners, DevTeam members, SMEs, and anyone who can contribute in the requirement discovery (Business as well as technical) in front of a big wall. One of the SME steps-up and starts narrating a story of activities they would perform to solve the problem for which you have decided to create a product. As SME is telling the story, armed with Sticky notes and markers few of the assembled persons start writing those activities on the wall. The arrangement of sticky notes should be left to right depicting actions to be performed by a user (as SME is narrating) to accomplish some job.

Figure: Epics and the Actions

Stage 3: As momentum builds up more than one person starts narrating stories from various perspectives as well as technical folks start pitching for NFRs and other technical requirements. Instead of one group, the room will witness various small fluidic groups all working on different aspects of the requirements. 

Once a substantial number of requirements are collected, it is time to bring in some order. A couple of persons can volunteer to remove duplicates and group the sticky notes into groups which will be represented as Feature.

 

Figure: Requirement hierarchy

Stage 4: It is time to group the requirements into the Features and Stories under the identified Epics. Certainly, you will find some holes in the requirements; plug them if possible.

Figure: Story map – First Cut

Stage 5: It is time to figure out a MVP. Pause!!! Can you figure out a MVP out of nowhere? NO, we need to categorize the Features (yes, Stories as well) using Kano or Moscow model.

Figure: MVP and MVA

It is time to mark MVP on the Story Map.

Figure: Story Map and MVP

Hurry! You have a pretty good Story Map to start with.

To facilitate such a fluidic workshop, you will need an experienced facilitator.

Now we have a workable Story Map as well as identified MVP, we are good to start our PI Planning meeting.

Continual evolution of Story Map

Now you have a workable Story Map, what’s next?

The purpose of Story Map is a two-dimensional visualization of backlog, so planning for maximum value delivery can be performed in a collaborative environment.  Story Map is never static, it is a living artifact. It keeps on evolving

.

Story Map and PI Planning meeting

During Pre PI Planning meeting and/or refinement sessions in current PI for upcoming PI, Agile Teams, Architects, PMs, Shared Services, and System Teams update the Story Map. 

At the end of PI Planning meeting, Story Map should represent the commitments made by Agile, System, and Shared Services Teams.

Figure: Story Map with PI commitments

Each Agile, Systems, and Shared Services team will maintain a part of Story Map also every team in an ART is responsible to maintain the whole of Story Map.  Each Agile, Systems, and Shared services team should mark its iteration commitments by drawing a box around stories committed in iteration planning.

Figure: Story Map with Teams’ commitments

Release planning

As Story Map very clearly depicts work done and in progress, it becomes comparatively easy to plan a release using it. The Features to be released in a particular release are boxed in a Release Box.

Figure: Story Map with Release Plan

More value addition in Story Mapping

With a little imagination, you can contextualize a Story Map.

 

a. Put wireframe next to the relevant areas of a Story Map
b. Use small stickies’ over story stickies’ to mark NFRs, Personas, refactoring target stories, etc.
c. Use threads to depict dependencies (actually you can combine dependency board in a Story Map).
d. Mark features as part of MVP or Minimal Viable Addition (MVA) to an existing product