Blog

Reach Us

17 May 2018

Agile Metrics: Velocity

Agile Metrics are meant to serve a certain purpose(s) and can be very useful if leveraged appropriately. In this series, I want to share my experiences of how metrics may be used, abused and effectively become focal point of failure of Agile adoption in an organization.

Velocity is an indication of the average amount of Product Backlog turned into an Increment of product during a Sprint by a Scrum Team, tracked by the Development Team for use within the Scrum Team.

There is no such thing as a Good Velocity or a Bad Velocity. Remember, it is based on relative estimations.

Let’s understand with some examples on how a powerful Velocity metric can turn from Good, to Bad, to Ugly.

The Good: Along with other inputs like team capacity, prior commitments, Velocity helps Development Team decide how many Product Backlog Items they may forecast for current Sprint. Velocity also helps Product Owner to gauge how quickly a team may work through the backlog, because the report tracks the forecasted and completed work over several iterations. The Product Owner may revise the forecasted delivery timelines based on the variations in velocity of the Development Team.

Velocity is absolutely awesome and GOOD metric when it is used by the Scrum team themselves to understand their progress, their strengths and how they can improve Sprint over Sprint to become better. Leveraging Velocity for any other purpose by people outside the Scrum Team may quickly result in this metric being abused and making it BAD.

The Bad: I have had instances where leaders have asked me questions like, “If two teams have similar skillset, shouldn’t their velocities be similar?”, “Team A’s Velocity is 2 times that of Team B’s – shouldn’t Team A work on the remaining Product Backlog Items for faster delivery?” This prompts me to explain to them that each team would use their internal consensus to estimate the size of tasks at hand. Such sizing of efforts may differ from team-to-team due to differences in the reference points for these two teams. Size of task ‘X’ for Team A may be larger than its size for Team B, because former may be used to slicing efforts to smaller sizes and thus resulting in ‘larger’ estimates. This may make Team A’s velocity appear higher than Team B’s velocity.

Leveraging velocities for such comparisons will not yield any benefits. In fact, such comparisons make teams very uncomfortable, as they quickly understand that leaders are using this metric to measure the collective team and possibly their individual productivity.

The Ugly: When Leadership decides to use improvement in Velocity as a measure to gauge Development Teams’ performance and teams become aware about it, things become ugly. Now Development Teams will start fudging the sizes of their PBI’s / tasks to ‘bloat’ their velocity, just to ensure they appear to meet (may be even beat) their target velocity. At this point transparency will cease to exist in the team ensuring mechanical Scrum implementation resulting in sub-optimal metrics and delivery.

To sum up, Velocity is a result, not a desire. Velocity is a good metric for Scrum Teams to leverage for its internal purpose with the idea of continuous improvement. At the same time if the Scrum Team optimizes their velocity to be able to deliver value faster, but other teams within the system are unable to consume their outcomes, it will result in waste per Lean principles. Optimization is best done at system level rather than locally.

The moment this metric is used for any other purpose, the teams and organization will lose the benefits that Scrum has to offer. This will result in Zero-sum game for the entire organization and they will lose focus on their Agility goals.

References –

Scrum Insights for Practitioners – Hiren Doshi

Source: https://www.scrum.org/Resources/Scrum-Glossary

27 Apr 2018

Agile Coach Toolkit #8: Limiting Work-In-Progress

Do your team members have a tendency to pick up the next task to work on in case they get stuck with current task because they are measured for ‘utilization’? Such multitasking isn’t just bad, but also has harmful effects and causes stress on the person as proven by a study at Stanford University. Here’s a sample of Scrum board with no limit on WIP items –

Few issues with above view –

  • None of the Product Backlog Items are done as there are lot of tasks in progress. In case of any outage or downtime towards the end of the Sprint, most likelyno value will be delivered by the end of the Sprint.
  • This may also reflect a dysfunction that team members are working in silos, as everyone is busy working on something, but just not focused on delivering the most valuable story together as a team.
  • The flow of value delivery is constrained as the cycle time to complete anything valuable is impeded due to multitasking.
  • There is a high probability that the motivation and the morale of the team members might be low and in addition there might be a psychological pressure on the team to finish all the Product Backlog Items selected for the Sprint.

Recommended steps for Limiting Work-In-Progress:

  • You will need to have a buy-in from the team regarding issues with no limiting WIP items. Discussing above issues would be a good starting point to educate them.
  • Have them focus on the outcomes rather than ‘being occupied’. If any of the team members is stuck because the task he/ she is working on is blocked due to external dependency, instead of picking up a new task, review other WIP items of the team and assist the team members to get it done. This may mean learning new skills along the way and also help break down silos among the team.
  • When picking up work from the Scrum Board, always work backwards to ensure that tasks closest to Done is tackled first before moving backwards towards selecting next item to be worked upon. Such approach will also assist in reducing the Cycle Time.

Above steps will eventually lead to a Scrum Board that will look like the one below where value is continuously delivered to stakeholders during the Sprint –

Have you used this technique? If yes, please share your story.

References –

Kanban and Scrum – Making the Most of Both – Henrik Kniberg and Mattias Skarin

http://brodzinski.com/2015/10/dont-limit-wip.html

18 Apr 2018

Agile Coach Toolkit #7: Straight Feedback

One of the reasons Scrum allows opportunistic discovery is due to its short and fast feedback loops. With the aim to build a high-performing Team and to get the best potential out of each individual and to help them be successful, Agile Coach needs to provide straight feedback to them. But giving straight feedback is a daunting task especially since we are dealing with human emotions. In general, just the utterance of the statement, “I would like to give you feedback” sends the heart racing for a lot of people.

Recommended Steps for giving Straight Feedback:

  • Do not delay too long in giving feedback to the person. Best to give it while the incident/ event is fresh in the mind. My suggestion is to give it within the same day at the latest, if possible.
  • Take the person away from team and work environment, even for a coffee or for a walk to maintain it a bit casual. It helps to have such discussion in isolation to avoid other distractions.
  • Start by saying something on the lines of –

“I would like to give you feedback on … <topic>”

  • Be very specific and do not generalize the feedback as it will lose the essence. It will help maintain focus on the issue.
  • Get the person’s opinion on the matter you want to discuss by Asking Powerful Question –

“How do you think you did in this … <topic>?”

  • Let the person share his/ her perspective on how he/ she believes the issue was handled. This will also serve as a checkpoint for them to introspect.
  • You may choose to then ask the person, “Why do you think you did it that way?” This will help the person to provide their reason for handling things that way.
  • Then provide your feedback on the specific topic. Avoid personalized criticism (“you are useless”) or judgmental comments (“your code is useless”) to the person. Give feedback with great humility, love and respect in mind when having such critical conversations. Remember your goal is to get the best of the person and make the individual excel in his / her role.
  • Then ask below question to the person to see if she/ he is in agreement –

“What do you think about that?”

  • Most likely they will agree with you. You can ask below question to get the person to think about next steps –

“What would you do next time?”

  • If the person disagrees, let him/ her vent a bit. Let the person reflect back on it and ask again, “What do you think about that?” If the person agrees, help chalk out the next steps in above point.
  • If the person does not take the responsibility, acknowledge it (that he/ she will not take the accountability) and say “I’ll take it from here.” May be a good idea to escalate in case the matter needs intervention from HR.

Have you used this technique? If yes, please share your story.

References –

Coaching for Performance – John Whitmore

https://www.youtube.com/watch?v=cKTR0hpc_as

11 Apr 2018

Agile Coach Toolkit #6: Building Consensus

Being a Scrum Master of a team with strong personalities can be challenging at times especially when two or more people believe that their approach is right. Such situations may call for Effective Facilitation to build consensus. This will help get the best out of the productive dissent at the same time ensuring that they do not fortify into sub-groups.

There are multiple benefits of building consensus –

  • Better decision-making as discussions would help uncover flaws/ situations which individuals may not have thought of.
  • Assist in better implementation of solution since everyone cooperates as it is a team decision.
  • Maintains team’s working relationship healthy by making everyone feel included.

Before going for a team discussion, it would help if you know the personalities you are engaging with and using Root Cause Analysis in one-to-one conversation to uncover any personality conflicts between the participants.

Steps for Building Consensus:

  • Have everyone understand the meaning of giving consent by encouraging them to think about what’s best for the entire team rather than individuals.
  • Clearly articulate what needs to be decided. It may be a good idea to also layout why the issue is being raised.
  • Before pitching for lengthy discussion, do a quick poll to check if there is consensus. If majority of the team agrees to a solution, listen to the concerns of dissenters. Adapt the popular solution to get their points addressed so we have a win-win solution.
  • If there is a disagreement amongst team members, allow everyone to voice their concerns during the discussion so their ideas can be included. It would be a good idea to list them to ensure these get addressed.
  • List Scrum Values and ask people the follow them throughout the discussion.
  • Leverage Timeboxing to ensure that you curtail lengthy discussions.
  • For final decision, do another poll to see if majority of the team agrees. Dissenter (if any), can serve as critical evaluator of the implementation of team decision. This may help spot issues before rest of the team can see it.
  • Ensure that the team decision is communicated at the end of the meeting.

Have you used this technique? If yes, please share your story.

References –

Agile Coaching – Rachel Davies, Liz Sedley

https://www.wikihow.com/Reach-a-Consensus

Culture Change

20 Mar 2015

Culture Change – An important ingredient for organizational Agility

To imbibe Agility in an organization which is a state of high responsiveness, speed, and adaptiveness organizations should promote a new organizational culture of openness, transparency, respect for people, constant learning, improving, and constant adaptation. Even with so much of awareness, cultural change seems to be one of the major hurdles impeding organization’s success.

Culture is more about “The ideas, customs, and social behavior of a particular people or society.” When an individual behaves in a particular way, we associate that to be his nature, but when a team or an organization responds, we relate to its culture. As this is associated with people and their entrenched culture it is very difficult to change!! While it is also a very common observation that the culture within the same organization varies across various geographies. It’s not uncommon to hear statements like that’s the UK Culture, or the US Culture, or the Indian Culture, etc.

When a team/group of cross-functional individuals work together (co-exist and collaborate) for a long period of time in the same organization by respecting and following certain organizational values; they display a unique identity of that group forming their culture. And when we address the culture exhibited by all the teams in an organization it is referred to as the organization culture. If you observe carefully, culture is not the characteristic of one individual but of the team/organization as a whole.

I recollect one of my consulting experiences where I was hired as a coach in one of the organizations that had been practicing Agile for a while, but their adoption was stalled. Although from the outset they seemed to follow all the Agile best practices, they were still struggling with the deliveries and their team motivation was at a all time low. One of the first things I did was to probe the teams by facilitating Anonymous Retrospectives to generate insights. It was quite revealing to find that the organization had a “Culture of Fear”; fear of getting penalized for a decision going wrong, fear failure to meet the commitments, fear of poor quality deliverable, fear to be completely honest and transparent, fear to challenge the status-quo, fear of lack of trust and respect among people, etc. This culture of fear in the organization did not allow Agile to penetrate beyond the surface. Once these insights were shared with the organization, they embraced and acknowledged the shortcomings and worked towards corrective practices to remove the fear thereby imbibing the “Culture of Agility” in the organization.

Organization culture contributes significantly towards successful Agile adoption and therefore understanding it is the key. Management, executives, and team members should support and embrace this change. Invest in a few prominent agility attributes like the healthy team dynamics of self-organization teams, continuous improvement, frequent delivery, effective communication, adapting to the changing environment, etc. that benefits an organization and its customers. To bring culture shift, organizations must examine its existing practices with a critical eye, try new way of doing things, create new opportunities, coupled with commitment and nurturing at all levels within an organization.

Organizations which have traversed through the Agile adoption culture change journey exhibit some of these characters:

  • Team members demonstrate values like Trust, Respect, Courage, Openness, Confidence, Synergy, Unity, Affiliation,and Commitment.
  • Creativity, Collaboration, Emergence, Rhythm, Empiricism, and Discovery are encouraged organization-wide.
  • Embracing Transparency, Inspection, and Adaptation as part of everyday routine.

Embedding cultural shift involves a lot of patience, a full top-down support, constant learning, and a bottom-up intelligence. While an organization may follow all the bookish guidelines and yet fail in this journey if they cannot identify this subtle/invisible ingredient of “culture” which plays a substantial role. Focusing on the correct culture, eventually leads an organization towards success in this transformation path!!

Agility fueling organizations towards profitability

09 Dec 2014

Is agility fueling organizations towards profitability?

Let me begin this blog by relating one of my travelogue experiences. A known taxi driver drives me in his car to the Mumbai airport every week from the last 4 years. The car is about 8 years old, poorly maintained, and has tugged a good more than 300000+ kilometers; has by all means attained end of life, good enough to be dumped, and reap benefits from its scrap. As an enduring passenger, I have been containing the noisy tractor-like ride in his car due to my acquaintance with him and also believing his long false promise of a new car on its way to replace this one!

Week-on-week he comes with the same car and asks me if I noticed any evident difference in terms of travel experience. He would spend good amount of money replacing the old parts (like the tires, cars’ engine, AC, etc.) with better ones, beautifying it by a coat of varnish, etc.; the expenditure now almost exceeding the price of purchasing a 3-year-old second hand car. I honestly said a big NO each time he asked me and also wondered why he was investing on this old car when a new car according to him was arriving in the next 3 months!! This fetish behavior of patching the old car in anticipation of some miracle resulted in the loss of many good loyal customers (as they were fed up of the continued bad bumpy ride with no respite in sight in the form of a new car).

During one of my recent rough ride in the taxi, I realized how well this experience was analogous to what many organizations undergo during their agile journey. They have every agile practice in place; right mindset, best practices, roles/ceremonies/artifacts well defined coupled with communication, motivation, and empowerment. Even with such a robust agile framework, the teams/organizations lack agility to adapt to the changing customer requirements and deliver in a fast paced manner. Although in reality, organizations want to go fast (like any new car) by adopting agile but unfortunately are stuck with poorly maintained legacy codebase (like the old taxi). Any amount of replacement, beautification, superficial modification, or adopting new methodology/technique without addressing the deep-rooted problems might temporarily mask the real problem thereby breaking ‘transparency’, one of the 3 legs of empiricism (for scrum to be effective, each of these 3 pillars – transparency, inspection, and adaptation must stand and be supported).

When such projects are assessed, in all probability the hidden truth is that the organizations carry a herculean technical debt in terms of complicated and poorly maintained legacy codebase (just like the old car) with little or no attention to the engineering best practices, poor feedback cycles, no automation of unit./integration/regression, poor re-factoring and code reviews, etc. Based on the assessment findings, organizations need to perform a cost-benefit analysis and decide whether it makes sense to fuel such projects and take appropriate corrective actions immediately rather than wait for some magic to happen overnight in an organization/product by just adopting agile. If not, (like the taxi driver) organizations will fail to deliver/meet customer expectations, not be profitable, and loose out longstanding clients.

Therefore, for organizations in their attempt to keep pace with the competitive world it is not just enough to adopt agile methodology but should imbibe agility in their DNA. Varnishing an old car may give it a new look but the driving experience will remain the same; the same applies to organizations as well. In most cases, change/expected results may not be visible by just refactoring in bits and pieces (replacing the defective parts) but it may call for a complete eradication of the existing system (significant remarkable/dramatic one which would be a winning selling pitch for the organization; in the car analogy it is like buying a new car) and re-designing/re-writing the software to bring in a new vibrant spectrum.

Upon this cleanup and novel thought it is now time to think how to drive this concept (new car) effectively and efficiently! Adopting the rich agile ethodology along with adhering to solid engineering practices at this juncture would act as a fuel to propel the team/project/product/organization, accelerate, and drive towards success!

With the legacy issues addressed and best engineering techniques embraced, agile adoption certainly triggers agility and benefits the organization by delivering fast-paced, feature-rich, competitive, and user-beneficial products of significant business value!