Agile is mainstream. As per the latest State of Agile report, 86% of software development teams surveyed had adopted an agile way of working. This is a 49% increase from the previous year. Such rapid acceleration in Agile adoption has unintended consequences. As we analyzed teams across multiple industries it became apparent that many had drifted from the original intent of the Agile Manifesto and in fact some had drifted so far that they became rooted in what we refer to as ‘WaGile’ a combination of Waterfall and Agile activities.
Losing the forest for the trees- As teams were rapidly organized into distributed Agile units, the interdependencies between them were not fully captured which meant that executives were now unable to get a single pane view of how their enterprise was performing and where the constraints and best practices were.
Dilution of the Agile Manifesto– The comfort of following a defined process meant teams started ‘’Doing Agile’’ with daily stand ups, burn down charts etc. instead of ‘’Being Agile’’ where the Agile Manifesto focused on customer centricity, collaboration and delivering value was implemented/measured
Some teams are more autonomous than others– Teams in an enterprise are not homogenous and thus adoption of Agile amongst them varies. Thus creating an enterprise standard of delivering value/software is difficult. It is difficult for coaches/leaders to ascertain relative maturity of teams and grant them autonomy as per their maturity and promote best practices and create an enterprise standard for Agile maturity
Case in point:
A fortune 500 financial services organization had heavily invested in their Agile Transformation. They had hired agile coaches and consultants, provided training resources and even organized in person program increments every quarter – they covered all the aspects.
However, two years in when they conducted a Q&A style survey of their Agile teams to understand their maturity – the results were shockingly low. Their scores on automation were the lowest. Is this a case of bad data or bad implementation?
In our experience, this is a challenge most enterprises face. They do not a have consistent data driven method or process to benchmark their team’s agile journey:
Subjective and Objective
Enterprises tend to adopt a mixed bag of measurement criteria where some metrics are data points which can be traced to an activity/deliverable whilst some others are subjective opinions of Subject Matter experts or the team members themselves. This may dilute the efficacy of the report while increasing the manual effort of capturing/computing the data
Same metric, different formulae
The most difficult aspect is to bring all the teams to a common and consistent understanding of the metrics and their method of measurement. It may sound simple, but anyone who has been part of an Agile transformation journey will tell you of the pitfalls of attempting a common way of measuring story points! And it’s not only a common way of measuring, but organizations are also faced with many different tools for measurement in their ecosystem.
No Common Denominator
Not all the metrics being measured are organized around the same unit. Some metrics such as production incidents may be captured per month only and it may not be possible to trace them by teams whereas some others such as testing defects may be by Agile team per sprint where the monthly trends may not be maintained.
Power point, Email, Dashboards, Daily, Weekly, Monthly
Different teams adopt a different method of reporting their metrics either via e-mails, weekly presentations or even Power BI or tableau dashboards. The reporting frequency of these metrics also varies. Thus, an executive is not able to see all of the data, consistently on a single pane and may have to employ further computation on top of the reports provided to retrieve the information they seek
In a recent discussion with a CIO, we were discussing Agile maturity and how to gauge the maturity of agile teams. How would you measure whether a team is delivering at pace, with quality and is bringing value to an organization? How do you setup a framework whereby teams can learn from each other building a best of breed structure when it comes to Agile.
It was then, that he gave us the challenge of coming up with a method of consistently measuring his teams on Performance, Pace and Predictability using something akin to a credit score and thus was born the"Agile Credit Score".
Agile Credit Score
An Agile Credit score is a gamified version of an actual credit score, where based on parameters an individual’s credit worthiness is assessed and they are accordingly awarded a score which benchmarks them against the population. This score is not static and based on behavior/actions it can change month on month.
Similarly, the concept of the Agile credit score is to identify a common set of parameters to measure all teams in an enterprise on a defined frequency (monthly or release cycle) so that their Agile maturity can be objectively determined and thus they may gain more autonomy in the release process.
Like the financial credit score provides categories of credit worthiness, the agile credit score organizes the teams into categories of foundational, progressing and best in class and based on their behavior/actions a team can improve their score and become Best in class.
Much like a credit report which provides recommendations on improving the score, the Agile credit score app also provides recommendations and goes one step further by connecting the teams with experts who can help them implement these best practices.
Principles of Agile Credit Score
Objective & Automatic
Select only those metrics which can traced and automatically captured by an existing engineering tool/application used by the teams (e.g. Jira). This eliminates manual intervention and additional overhead on teams to capture, maintain and report data. This also provides transparency as all the data can be traced back to source.
Reuse, not reinvent
Even though we adopted a set of 20 metrics in the inaugural Agile Credit Score app, we are not tied to them. We recognize that different aspects of the agile journey may be of importance to each enterprise. For e.g. for one enterprise the number of patents filed during the month was critical and for another scope creep mattered. Thus, the app is designed to be flexible and can adopt different metrics in its computational model
App for Good
The goal of this app is to enable teams to learn from each other without the fear of criticism. Thus all of the data is aggregated at a team level and not by Individuals in a team. There is an in-built trigger which guides the teams to experts within the enterprise they can learn from. There is also a leader board to provide healthy competition. But it is really not about who is on top or on the bottom of the leaderboard. It’s is really about how teams that are struggling on a certain metric can learn from a team that is excelling in that metric. The tool really becomes a learning tool rather than a tool to beat teams over the head for not doing a good job.
Product Quality and Risk
A key feature of the tool is that it links teams with SMEs within the organization who can help them remediate gaps and implement Best Practices. These SMEs are a purpose driven pod of experts which represent the entire SDLC. Thus the PQR pod becomes the vehicle of improving Engineering maturity across the enterprise which analyzes the engineering patterns/processes across teams, provides feedback and solution and helps them attain Quality whilst maintaining Velocity.
Through our many conversations with technology executives, Agile coaches and teams we have realized that everyone has a common starting point – consistent, reliable data across teams. Without clean data all the downstream analytics will be skewed.
Executives are also keen to measure impact or business value not just the output produced by their teams. This brings technology and business together and leads to enterprise agility (not just agile software delivery).
Thus most organizations are sharing this journey of transformation from a common starting point to a common goal and our platform is an attempt to bring them closer together and help them collaborate.
If you would like to join us on this journey, please do reach out to me atAdrian.OLeary@coforge.comwe would be happy to schedule a demo/discussion of the Agile Credit Score app.
Many thanks to Purna Singh for his contribution to the paper.