Skip to main content

Making Agile Management Meaningful

In the past, one of my favorite go-tos when exploring the web was Quora, the popular question and answer site. I would read through a lot of high quality answers by subject and domain experts; perfect for when I had some time on my hands during the boring commute to work. One day I saw a highly rated answer on my feed, and began to read through it without paying attention to the author’s name. I glanced at the author name and was stunned to see the Quora profile of US President Obama.

Over time the rational, crisp, and domain-specific answers were replaced by fluff posts; stories of personal challenges and triumphs became popular. These stories had the feel-good factor but contained no compelling learning, other than perhaps an increased sense of empathy. My enthusiasm took a beating too, since I didn’t feel a sense of personal development after reading these answers. The intelligent contributors were relegated to the background as well.

We should think along the same lines when we talk about implementing Agile—it’s important to segregate fluff from tangible goals and results so that we do not end up isolating the intelligent participant or contributor. The Agile implementation should not be just conducting ceremonies, but a mind-set which gives quantifiable results.

Some of the ways to make this possible are found below. Note that this is not a one-size-fits-all, since every team may have unique challenges and ecosystems.

 Agile Metrics for the Team and By the Team

Teams can define goals for themselves. These can be internal facing goals and define measurable improvements that the team want to see for themselves. Some examples could be velocity improvements, bug count reduction, and code review process improvement to prevent bug leaks.

This will provide quantifiable goals for the teams and the relevant Agile meetings could be focused around these goals. For example, the retrospectives could have discussions around how the team is performing for these identified goals and if any change is required in their implementation. If the code review process is overhauled and yet bugs are still being found, there should be action items around the changed process.

Understanding the Value Provided by Best Practices vs Stringent Implementation

There are times when some of the best practices don't make sense to everyone. For instance, it might be a good practice to update actuals every day for effective burndown, but unless the team understands the value it brings it will seem like just another administrative task being insisted upon by leadership. Teams need to understand and be on board with what everyone is expecting to gain out of it.

Looking at Holistic Improvement

Agile implementation should not have a narrow focus. If the organization’s goal is faster time to market, then the focus area is not just the number of features that the team can deliver but also the other areas that have the possibility of delaying time to market (lack of effective prioritization or unstable deployment infrastructure, to name a few). For this goal, team’s velocity is not an effective measure. Instead, cycle time needs to be analyzed to identify the problem areas.

Analyzing the Problem with Proper Context

While touching on problem areas it is possible to come up with solutions that seem obvious but might not be accurate. One scenario may be that if the team is analyzing a regression, obvious solutions may appear as the use case was missed while testing, with a solution of more exhaustive testing. Fishbone Analysis or 5 Whys are effective ways that could help the team reach the correct root cause.

Frequent Agile Maturity Surveys to Identify the Achilles Heel

We can’t solve a problem we don’t know about. These surveys would provide specific areas of improvements and call out blockers, instead of speculating on problems.

Overall, we are not looking for team members that are observers, but those who can be participants to start with and continue to contribute. Helping them understand and get on board to the value-add brought about by this transformation is the first step toward that goal.

About the author

Ruchi Wadhera has always been compulsively curious, a quality that has driven her to invest in areas of interest such as Agile, Technology, and Travel. She values the human aspect of Agile which inspires her to bond with her team as individuals. Having spent seven years of her professional life as a Java developer, she strives to comprehend any problem from her team’s perspective before looking for solutions. Holding a Bachelor's Degree in Information Technology, she is also a Certified Scrum Master and SAFe Agilist.