In May of 2018, I published this Back to Basics post -
The intent was to refocus attention back to some of the original thinking and mindset of the early days of agile. Not to sound too nostalgic, but life was much simpler then.
I want to add to the list I shared then:
If you want to get back to the roots of agility I encourage you to research the following…
And you might want to investigate how Spotify is implementing agile practices. Not putting them up on a pedestal but considering them a role model for learning the basics of agility in practice. https://www.infoq.com/news/2016/10/no-spotify-model
First of all, it’s been far too long for me writing something about metrics. It’s one of those topics in the agile community that keeps on giving ;-)
But I’ve been inspired (yet again) by an article that Anthony Crain wrote a while back on the topic. He introduced it as his QPPE Metrics Model, where:
Q – represents Quality,
P – represents Predictability,
P – represents Productivity, and
E – represents Engagement.
You can find the article here –
I shared this article with my friend and colleague, Shaun Bradshaw. I’ve known Shaun for the better part of two decades and he’s my go-to guy when it comes to all thing’s metrics related. Here’s his initial reaction to the QPPE post:
Arie Van Bennekum is one of the original signatories of the Agile Manifesto. So, he’s got significant experience and credibility in the agile space. He’s also the founder of a company called Wemanity, based primarily in the Netherlands, but spread across several European countries.
Arie recent shared on InfoQ about two models or approaches that’s he has invented and used in Wemanity’s journey that I thought might be interesting to share.
The Integrated AgileTM Transformational Model
Arie and his Wemanity team have created the following 6–step approach to introducing agile approaches and changing organizational culture. It’s intended to be a round-trip, iterative approach to incremental organizational and cultural change.
I’ve had a long career with estimates in software projects. While it’s been a rocky journey, I now feel that I’ve gotten to the point where I truly understand how to and the value of estimation.
But before I give you the great reveal, let me share some of my history…
I first began my career as a newbie in estimation. I fell into the trap of being as honest as a could be and I found that my estimates were often used against me. For example:
My bosses would often forget the “fine print” around the estimates. Words like – “this is only a guess until I get more formal requirements. Or, I’ve never done this before, so I really don’t know how long it will take” were never remembered. Imagine that?
People who had not a clue would weigh in on my estimates. Bosses, who were under pressure to release quickly, would cut them. And project managers, who were trying to “defend” the project, would pad them. And my developer colleagues, who always had an optimistic spin on things, their estimates would always be lower than my own. Imagine that?
And I always felt that nobody wanted the “truth” in estimates. That they couldn’t handle it. So, it negatively influenced me to pad/cut depending on the situation. But the key point is the inherent dishonesty I felt around all estimate discussions. Early on, it felt like a game of sorts. Where the last one that weighed in on a number…won. And the development team…generally lost. Imagine that?
But as in all things, I grew in my experience and in my career. Soon, around the late 1980’s, I became a “manager”. Which meant that I not only had to estimate for myself but for my group(s) as well. This showed me both sides of the estimation continuum and frankly, I didn’t like it much.
My colleague and friend, Anthony Mersino runs VitalityChicago. And agile coaching and training firm in, you guessed it, Chicago. He recently shared a post about 3 Key Steps that leaders should be taking to create business agility. The steps are:
Get Executive Buy-in and Agile Mindset
Agile Leaders Should Get the Right Mix of Talent
Foster an Agile Friendly Culture and Organizational Structure
While I really like Anthony’s 3 Key Steps, I’d like to add to or augment them…just a little bit.
In my experience, there’s a HUGE difference between getting buy-in and achieving an agile mindset. Most executives have a modicum of buy-in. Otherwise, they wouldn’t be embarking on an agile journey. However, achieving an agile mindset is different.
I was approached to speak at a startup event for a local Business Agility Institute user group here in the Raleigh/Durham area. I was quite pleased to be approached and am more than willing to present an agile topic to the group.
But the request made me think…
I’ve been engaged in agile approaches for nearly twenty years. So, I have quite a lot of experience with the core methods, practices, scaling, agile leadership, cultures, etc. But what the heck is “Business Agility” and what sorts of topics would that group be interested in?
The answer escaped me and I realized I had to do some research.
Here’s what CA (Rally Software) had to say regarding a definition and 3 key aspects:
A company’s way to sense and respond to change proactively and with confidence to deliver business value—faster than the competition—as a matter of everyday business.
1. It’s making the customer the central focus of your organization
2. It’s driving value faster, better, and more efficiently
3. It’s transforming how your business operates to achieve successful outcomes
One of the larger challenges facing many agile teams is having the requisite skills to deliver the goods. And it’s an insidious problem because it’s hidden by the very nature of cross-functional teams.
When I coach agile teams, I usually emphasize a couple of things:
I often exaggerate the responsibility by saying – the team needs to “suck it up” and work together to deliver on their shared goals. Everyone chipping in and helping each other out. There are no lone wolfs in an agile team and folks often need to do work that may be beyond their skill comfort zone.
But that has a prerequisite supposition…
Frankly, I’m tired of all of the scaling frameworks. They’re mostly driven by three needs:
Creating revenue for the firms creating them;
From a company or organizational perspective, they’re indicative of lazy, buy agile in-a-box, thinking;
And they feed the “certification happy” nature of our community.
And yes, I too am guilty of falling into the above traps.
I think the introduction of Scrum@Scale has ticked me over the edge and inspired me to write this post. That and reading this article by Neil Perkin, which takes a more reflective view to leveraging useful bits from the various scaling frameworks.
This is a bit uncomfortable for me to admit, but I have some confessions to make…
I’m a SAFe SPC;
I’ve attended a 2-day Nexus training;
I plan on attending / co-teaching Scrum @ Scale with Don MacIntyre in September;
I’ve studied (I mean studied!) and contrasted DAD and LeSS;
I’ve actively coached SAFe organizations;
I’ve been leveraging simple scaling techniques (Scrum of Scrums, bits of SAFe) for well over a decade.
So, it’s fair to say that “agile scaling” is in my bones, in my DNA, and that I’m fairly experienced. And it’s incredibly easy for me to meet a larger scale client and begin discussing scaling aspects quite early in our coaching relationship.