Agile Manifesto Revisited

In the current wake of COVID 19 while we all are confined to our homes, it is is not a punishment rather if we look at it with a positive aspect, we now have more time to dedicate to our families our hobbies and our growth. This pandemic has shown us the path to some great opportunities ahead.

Likewise, the agile manifesto that was drafted way back in 2001 did consider all this. It said that – While the items on the right are important, we value the items on the left.

Now, it should be…”While the items on the right are important, the valued items on the left will not reach it’s effectiveness without the items on the right“.

Individuals and interactions over processes and tools

• 

We have to rely on processes and tools to have more interactions with our teams

Many employees across the world found themselves using videoconferencing for work for the first time. They assumed it would be like using FaceTime but encountered several issues, including a lack of device interoperability, poor desktop-sharing experiences, and difficulties adjusting audio devices. But, some tools can help us function just like the way we operated from office. The difference being now we are more connected to our families while our peers are on screen. 

Working software over comprehensive documentation

• 

Overwhelmed customer service teams on the vendor side couldn’t respond to the questions of so many new users. Multiple vendors claimed that their inquiry volumes increased by an order of magnitude during that period. They don’t want to rely on documentation alone. They want to see it, experience it. And, that’s where we will need more effective tools to do so.

Customer collaboration over contract negotiation

• 

We do need a contract in place before we start executing the project and the customer collaboration relies extensively on the collaboration tools like Skype, GoToMeeting, Slack, Zoom, etc. 

Research shows that active users, who rely heavily on sending documents for collaboration, are concerned about the risks inherent to sharing documents online. Although SaaS providers have demonstrated the security of their cloud storage offerings with encrypted networks and permission control systems, customers are still unsure of how safe their documents and personal information are when using tools. And, that’s what is the need of the hour.

Responding to change over following a plan

• 

Times have changed and so has the focus. The world wasn’t prepared for the pandemic and hence had to enforce new laws and introduce changes in the way we used to function earlier. Responding to change was mostly limited to the changes in the client requirements, we never thought that we will have to change the way we operate, commute, and communicate. 

Once all this is over and as enterprises resume normal business activity, they will notice that an effective collaboration strategy needs to align the business and technology objectives and coordinate work streams across cross-functional teams. Current pilots are only part of the holistic adoption assessments needed. 

To succeed, tech and business leaders will have to advocate for management support, cultural change, and adoption strategies for Employee Collaboration instead of simply defining a SaaS roadmap.

• 

Advertisement

Retrospective using the 4L theme combined with Tuckman’s Model

In the previous article we learned how to use the 4L technique for a retrospective and how effective it proved to encourage the team to talk and discuss points that in a normal day wouldn’t be possible. It is one of the effective ways to resolve conflicts in a group.

In this article we will learn more on how we included Tuckman’s model in the 4L Retrospective technique.

• 

Purpose

Being true to the Spotify model wherein the focus is on autonomy we saw value in merging 4L (Liked, Loved, Lacked, Longed) + Tuckman (Forming, Storming, Norming, Performing). This helped in identifying where we need to focus on keeping in mind the organizational goal towards Growth. We will call it Tavision. Tuckman’s model helped us to identify the correct state we were in and identify ways to improve on those and move to the next level.

• 

There are other models too that could give similar results like the Cynafin framework which is more aided towards decision making. However, we choose the Tuckman model because you also need to know the maturity of your teams in adapting to new ideas and ways of doing things. Cynafin at this point was for an advanced stage of doing our retrospectives.

The Agenda (10 Minutes)

Before starting with the retrospective, the IM took 10 minutes to explain the agenda.

• 

For that IM used the Five levels of conflict:

1. Intra-Person– Personal challenges – this has to be solved at a personal level, not with the squad.
2. Inter-Person – Conflicts between two or more individuals in the squad. This has to be sorted between the individuals or with their manager.
3. Intra-Squad – Challenges within squad w.r.t to the sprint work and achieving the sprint goal.
4. Inter-Squad – Challenges with other squads in achieving the sprint goal.
5. Intra-Organization – Challenges at the organization level that needs to be addressed by the leadership.

The agenda was set – the squad was to discuss only on the conflict level 3 and 4.

The Execution

(Total 1 hour, can extend to 2 hours depending on the size of your team and experience with retrospectives)

Explain the Tuckman Model (5 minutes)

Once the agenda was set all squad members were explained the Tuckman model.

Tuckman’s model is significant because it recognizes the fact that groups do not start off fully-formed and functioning. He suggests that these phases are all necessary and inevitable in order for the team to grow, face up to challenges, tackle problems, find solutions, plan work, and deliver results.

• 

1. Forming – Made aware of things. Learning.
2. Storming – Chaos. Need maximum focus.
3. Norming – Started working on the solution but still need more focus.
4. Performing – Doing it as expected.

The List

Once the squad understood what was expected from the retrospective. They were asked to come up with points that they thought was in the Inter-Squad and Intra-Squad level of conflict. This was a group activity wherein IM wrote all points from the team on the white board.(15 minutes)

• 

Next Steps

• Each member was asked to place the items on the board into the four quadrants.

• 

Note: There will be instances that many items on the list will be repeated in different quadrants. And, that’s what will initiate the discussion.

• Once all the items from the list were added to the quadrants we formed four groups and asked each group to pick up all items from one quadrant and further distribute those into the four quadrants as per the groups understanding.

• 

• 

• 

• 

Note: Do this for two rounds or till the group comes up with the top items for each quadrant. Let the squads decide the top items that they want in each quadrant. Further, if needed you can initiate the dot voting to identify the top 3,4 or 5 action items in each quadrant.

In this case the items in the Storming phase will be the top most action item.

• Once the squads identify the top action items everybody in the squad would know the correct state of their squad. And, then identify ways to improve on those items.
• As mentioned earlier the execution was based on the 4Ls Technique, you will need: Post-it notes, flip chart paper, white board, pens etc.

THEN IT WAS TIME FOR APPRECIATION WITHIN THE SQUAD AND CELEBRATE THE PAST SPRINT, WITH PIZZA… 🙂

• 

What’s in the Metrics?

Agile contains a multitude of methodologies, but using a cumulative flow design might be the great unifier you’ve been looking for.

Everyone’s supervisor wants to know the metrics behind their Agile journey.

Some of the most frequently-asked questions during Agile Scrum training are:

• “There are a lot of metrics to measure. Which one I should pick up to track the progress of my team?”
• “I use both the methodologies Scrum & Kanban within our iterations and I don’t want to confuse my team members with different metrics from time to ntime.”
• “I thought my daily stand-ups are effective, but many times the last-minute spill-over surprises me.”
• “My manager keeps telling me constantly to “raise the bar” to build a high-performing team. I am not even sure where we are today to consider the next level”

Scrum espouses principles of “transparency, inspection, adaption,” Kanban’s philosophy involves “visualization, limiting WIP & enhancing flow,” and Extreme Programming values “communication, simplicity & feedback.” But the common theme revolves around visibility of work inclusive of blockers for the team, not only to understand where we are but also to do course correction.

Throughput and cycle time of the deliverables are two vital parameters to understand the progress as well as the projection of completion based on the current timeline.

While there are different charts and measurements that help in understanding throughput and cycle time – burn-up or burn-down in Scrum, visual flow in Kanban, velocity in extreme programming – cumulative flow diagram is one powerful chart that works effectively irrespective of the Agile methodologies the team operates in.

“The greatest value of a picture is when it forces us to notice what we never expected to see.” – John W. Tukey

Let me explain the power of a cumulative flow diagram as compared to other charts in understanding the flow better for actionable outcomes.

Below is the summary of the work planned and achieved by the team over 10 days:

Let us explore a simple burn-down chart that depicts the ideal work remaining vs. actual work remaining:

Burn-down helps in understanding if we are on target or behind in comparison with ideal work remaining. It doesn’t directly reflect the change though.

Now, let us the same through burn-up chart:

While this also helps in understanding work remaining, we can see the change in scope after Day-5.

Both the burn-up and burn-down charts focus on work completed and work remaining from customer perspective. While these are great measures, we also need to understand the intermediate flow (movement from one state to another) to be able to understand blockers and impediments.

Let us represent the above with a simple stacked bar chart:

Much better, isn’t it? This depicts the progress through various stages as well as the scope change (the spike on Day 6).

It’s time to covert the stacked bar chart into stacked area chart.

Bingo! Here comes our superhero cumulative flow diagram to our rescue to be able to deep dive further. Each colored area represents the flow (in the above, it is “Yet to Start”, “In Progress”, “Done,” and “Shipped”) and shift from one to another depicts throughput.

There are several important key takeaways from this chart which helps in further inspection & adaption:

• Scope Change: Change in overall horizontal line. In the above chart, the change occurred on Day 6 and is stable after that.
• Thin Flow: Thin flow represents a quicker process. “Done” flow is faster compared to “In Progress”. If we need to lean overall throughput, then our focus should be on the “In Progress” flow.
• Average Lead Time: The horizontal shift from “Yet to Start” to “Shipped”
• Cycle Time: The horizontal shift from one state to another. For example, “In Progress” to “Done” will provide the cycle time.
• WIP: It’s important to measure the work-in-progress since limiting WIP expedites the progress. The vertical line within one state provides the number of items that are being processed (a.k.a) WIP.

It’s a myth that the cumulative flow diagram is only for Kanban methodology. It provides immense value across the board. Cumulative flow diagram can be plotted for stories/tasks within an iteration. Hence is a great value addition in Scrum as well. It can also be expanded for features at program level and epics at the portfolio level. Thus, it provides benefits at various persona levels: Scrum master, program manager, product manager and business stakeholders. This is applicable not just in information technology; this visual representation helps in understanding and taking action in any day-to-day activity that we would like to optimize the overall experience/flow of.

It’s a great tool, not just to track and troubleshoot development projects, but also for maintenance and operation projects. You gain better insights using a cumulative flow design, and it helps in driving meaningful retrospection.

Let’s Lean on Lean (What’s in the Metrics: Part 2)

Look at your Lean process, then look at this article to determine if you are paying enough attention to how much waste your pipeline has.

“Hey Ramesh, we understand cumulative flow now and we also know which flow has longer cycle time. What should we do next to optimize the flow?” This a question I’ve received from folks who read the article on cumulative flow diagram.

Let’s revisit our flow diagram:

It’s evident that the cycle time is higher for work items in the flow “In Progress->Done” compared to the “Done->Shipped” flow. Let us see how we can optimize the flow.

Value stream mapping is a powerful method for identifying the waste in the entire process flow and helps to achieve the desired state. It is one of key Lean concept in manufacturing systems, but is also applicable almost in every domain. Though it has several symbols, flows, and guidelines to follow, the approach is quite simple with identification of value added, and non-value added steps in the entire flow.

Let me explain this with some examples from the development flow (“In Progress-Done” as above):

• Building code with built-in quality: Value-added step.
• Code review: This may be a bit confusing as this sounds important. But if we ensure the built-in quality during coding, we may not require this additional step. However, we also need to see the cost of quality if the defect is detected late in the cycle. Hence, this may be an example of a non-value added but necessary step.
• Build time: Waiting for the latest build is a classic example of a non-value added step and falls into the standard type of “Delay/wait time” waste.

Lead time is what the customer feels, and value-add is what they are willing to pay for. For an ideal Lean flow, the value-add should be the highest with optimal value enablers and minimal to none non-value add.

While value stream mapping seems to be simple and straight-forward, listing below five critical points to be considered for effective outcomes:

• Classification is critical: For each process step, it’s important to classify (value add, non-value add but necessary, non-value add) from customer perspective than how we perceive it to be. It is possible that value-add for one process may be non-value add for another process. Also, it need not be always the cost customer willing to pay, it’s equally important to understand the cost we need to avoid (in the above example, the code review will limit the cost of quality) to arrive at the proper classification.
• Every process step counts:
  • What’s the big deal about ignoring non-value added steps that take only few seconds? Well, think of this process step not being followed 100 times, 1000 times and so on.
  • What about the process steps we don’t own? Most of the time these steps are put in a black box and we tend to leave this as is. It is immaterial if these are internal or external, we need to work with everyone involved to identify the waste at every stage. System thinking is critical in striving towards perfection. As John Shook states, “Lean isn’t lean if it doesn’t involve everyone”.
• The process must tell the real story: The value stream should depict what’s happening in the proces, not what we think it could be. It’s important to understand the domain or have someone with domain expertise help us putting value stream together.
• Scenarios: Lead time of any process may vary time to time, which leads to the question of what to represent for value-added and& non-value added steps, best case, worst case, or regular scenario? It depends on the frequency of each scenario. Value stream mapping gives the visualization of as-is process and what represents the current process should be captured – it could be average, minimum, maximum or any other statistical measures.
• Automation is the cure for everything: Manual effort reduction through automation is great. But if we are automating the process without Leaning it, we are just converting manual waste to digital waste. Let us not forget about the resources required to perform operations even if the process steps are automated.

Value stream mapping is extremely resourceful in identifying and eliminating the waste in the flow when it is leveraged in the right spirit. Over a period, the value-added steps might turn into something customer don’t want. It’s important to revisit the value stream mapping and optimize it frequently. After all, Lean is not a one-time activity.