I wrote the first edition of my Scrum Product Ownership book in 2009. Looking back, twelve years seems like an eternity in the agile universe. Perhaps it is. Since then, I’ve published two more editions, with the last hitting the streets in 2019. At this point, I don’t envision there being a 4th edition, but you never know.
Around 2012, I developed a Product Ownership maturity and assessment tool to accompany the book’s themes and ideas. It was a simple spreadsheet with ~20 areas of consideration for individual product owners or agile product organizations.
I was always somewhat disappointed with the ease of use and approachability of the assessment tool, but I really never had the time to change the delivery format. Nonetheless, there were quite a few people who were actively using it and gaining value from the insights.
But enough background…
February 5, 2018
I’m experienced enough in the Scrum community to remember several early attempts at assessing the maturity of agile and Scrum teams.
- Around 2008 – 2010, the Nokia Test was originated by Bas Vodde in his work at Nokia. Jeff Sutherland and others have referenced it.
- Then the Nokia Test evolved into the infamous Scrum-But test around 2010. Aka, “We are doing Scrum, but…”. Below is a publication from 2011 that Sutherland shares about the evolution of the test –
- Around the same time these were evolving, in 2007, Ahmid Sidky wrote his dissertation focusing on an agile assessment framework. He called it the Sidky Agile Measurement Instrument or SAMI. And to my knowledge, it was the first attempt at a holistic instrument or framework.
My point in taking you down “history lane” is that agile assessment tools and frameworks have been thought about since ~2007. So, for the past 10+ years.
The problem is, that none of these, and the ones introduced later, have really done an effective job of helping teams improve.
If you were to have asked me about five years ago about agile team and organizational assessments, you might have gotten your head bit off. You see I used to be violently opposed to formally assessing agile teams in any way.
The roots of it probably related to aggregating team velocity. If you’re wondering, that’s not such a good thing to do either. I was worried about teams comparing themselves to each other and creating unhealthy or dysfunctional behaviors. I also worried about what THEY (leadership, managers, Project Managers, HR folks, etc.) would do with the information.
Now I’ve always felt that having maturity data around, in some form, was helpful to seasoned agile coaches. It just gets hairy when you start using it for organizational and x-team metrics. And it’s the inherent “metrics dysfunction” that is always lurking in the shadows this is a real concern.
