Julee Everett and Ryan Ripley shared a wonderful article on making technical debt more visible. In that article, they focus on visual metrics that illustrate progress in cleaning up debt.
I’d encourage you to read it.
The article also made me think a bit about my own experience with technical debt and how to influence the organization to take it more seriously. Here are some advice tidbits to make your technical debt more visible –
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.
In 2001 I was laid off from Lucent Corporation in Raleigh, NC. At the time, I was a software development director leading a group of developers and testers implementing optical networking devices. It was incredibly complex work and the teams were dedicated to doing great things.
This was just post the 9/11 attack and the Telecom bubble burst so to speak. So, all of the large Telecomm companies were impacted.
I was placed on the building close-out crew, so I had a long period of time “managing” the reduction. At that time, I began to write a book. I completed it in 2002 and it was finally published in December 2004. I remember at the time being incredibly impatient as the publisher, Dorset House, took its sweet time in the editorial and printing processes.
This description is intended to help guide the implementations of Scrum of Scrums at Program / Train level.
It all started with this picture that Mike Cohn published over 10 years ago. In the explanation he briefly mentioned a hierarchical structure where multiple Scrum teams get together when they are working on related projects.
Often I explain it as: team-based Scrum behaviors, just up a level.
I remember my first reading of the DAD – Disciplined Agile Framework by Scott Ambler that one of the areas he emphasized was governance.
When I first read it I had two immediate reactions:
- What did he mean by “governance”?
- And why care about it within agility; wasn’t that something agile intended to minimize or eliminate with transparency?
So to say that I was less than impressed by DAD initially was an understatement. But over time, I’ve kept up with Scott’s writings and explanations of his intentions with DAD. And to be honest, I like what I’m hearing of late.
Alan Cyment: Another Look at Shu-Ha-Ri
Alan Cyment gave a wonderful Pecha Kucha talk at the recent Scrum Gathering in Phoenix.
In it, he challenged the use of the Shu-Ha-Ri model or metaphor on a couple of levels –
- Is a martial arts metaphor really the best way to describe the growth dynamics of agile instances?
- Are there really only three phases of agile adoption?
- Often in Shu-Ha-Ri we can revert as well or regress in our learning.
- The notion is that the Coach is a Sensei…and others aren’t?
Alan’s metaphor was much simpler, yet I believe richer.
I think it was George Dinwiddie that first coined the term “3 Amigos” in agile development around 2009. The analogy was akin to the movie from the mid 90’s by the same name. The Amigos in the agile sense are functional roles:
- and the Business Analyst or the Product Owner.
It could literally mean more than three as well. The point was, balanced collaboration in agile teams across these roles. George was alluding to these roles from an Acceptance Test Driven Development (ATDD) perspective. He wanted these three constituencies to be heavily collaborative (conversations) around the Acceptance Tests or Acceptance Criteria for each user story.
I often cite Salesforce in my classes as a company that has:
- gone “all in” from an Agile Transformation perspective;
- done it in an abrupt Top Down fashion;
- has gone from technology to IT to now Organization-wide in their adoption;
- but most importantly is a company who shares its lessons in the community.
I always lament the fact that too few companies that are adopting agile approaches actually share their lessons publicly. Oh sure, some small bit leak out, but most unfortunately decide to keep their practices to themselves.
I was talking to an experienced Scrum Master and Agile Coach the other day about agile in general and the topic of stand-ups came up. It seems he’d had an “experience” at one of our local agile group meetings where Daily Standup dynamics were being discussed.
Here’s a link to the session. It’s a meeting from our local Raleigh, NC AgileRTP group. The topic was entitled: Do You Stand Up? I missed the meeting, but he recounted the general discussion and flow for me.
The group consensus was that: 'Chickens' (interested bystanders, stakeholders, leadership folks, etc.) should not talk during the Daily Scrum. The rational mostly surrounded that at it would interrupt the teams conversations and flow.
The Scrum Master disagreed with this view and he (jokingly) said that—when he brought up his perspective, the crowd summarily dismissed him as being wrong.