I haven’t thought of the Pareto Principle in quite a long time.
It was a central theme to my 2004 Software Endgames book because of the implications of Pareto and software defects (trending, clustering, resolution, complexity, etc.) It was a rich and interesting way to view defects at the time. Still is.
Then I wrote a blog piece entitled Pareto and You – Separating the Wheat from the Chaff in 2013, where I explored the implications of Pareto beyond software testing and defects. At the time, I saw the principle as something that could potentially have broad implications beyond software and into life itself. That is, could we view it as something as reliable, consistent, and law-like as the law of gravity?
I had been thinking the answer to this was yes. That is, as long as we view it as a lens for guidance rather than a law that strongly drives our behavior, measurement, and reactions. Consider it a Pareto Compass that would guide you towards True North in your understanding of complexity.
We were chatting about agile coaching the other morning in the Moose Herd and the principal came up again. I mentioned it as a lens that an agile coach could leverage in their assessment of and navigation thru Agile & Digital Transformations. Afterward, I put on my brainstorming hat to envision scenarios in my agile coaching journey where I might be able to look at the world through a Pareto lens—
Dare I say it, it’s a—Community of…
PRACTICE!
I was in our Moose Herd the other day, yes, you’ve herd me say that more than a few times in blogs ;-)
And we were talking about Communities of Practice (CoP’s) as a phenomenal way to “raise the bar” in agile organizational contexts.
Everyone was aware of the practice and had participated in them. But there was a general feeling that most organizations don’t have a good recipe for a great CoP. So, we started brainstorming some of the tactics or patterns for a Good-to-Great Community of Practice. Here are some of the ideas we explored—
I’ve been involved in agile for ~20 years and I’ve noticed a consistent anti-pattern that never seems to change.
People wait too long to ask for help!
I’ve noticed it in my coaching. By the time I usually get called into a situation where an organization is attempting to implement agile is, dare I say it, things are off the rails. Sure, a part of me thinks that’s a good or normal thing. But that’s the revenue generation part of me.
The principled agile coach part of me always wishes that they had reached out earlier. That it would have saved so much aggravation and frustration, wasted time & effort, and ultimately cost.
But it’s not just as a coach. It also applies to my leadership experience too.
If a project was off-track or a commitment would be missed, I usually found out at the last minute. Far later than when I could have actually helped or done something. I always work hard as a leader to create safety for bad news, to be approachable, and to be grateful for it. Very hard. But it still shocked me how often folks wait too long to share something with me. I often wonder, what did I have to do to create the culture where sharing challenges was rewarded, was the norm, and not feared?
I’ve seen cobbled together Scrum teams for years, but I realized just the other day that I’ve never written about them. So, now I will…
What are they?
They are an anti-pattern and are a team in-name-only. That is, there is no collaboration because everyone works on a unique product, application, service, or platform.
I often see this anti-pattern in Ops organizations where the coverall company is adopting Scrum. The leadership team feels compelled to form teams everywhere—out of individuals with very different skill-sets, roles, and application-level responsibilities.
For example, if it’s an IT administration and support group, probably every member of the group has 1-10 applications or platforms that they are individually supporting. With little to no overlap in skills or area ownership across team members.
Someone approached me the other day for some coaching advice. It seems that they’re in a Coach / Scrum Master role and have a team that, well, isn’t doing very well.
They’re pushing back on the use of agile approaches—seeming to be going through the motions of Scrum. They’re not delivering much in the way of value. And, to use his words, they’re simply not motivated. Which was his question—
How do I motivate this team?
Certainly, this isn’t the first time I’ve heard this question and it certainly won’t be the last. My first thought though was—you don’t motivate a team; they have to motivate themselves. But, as I answered the question, I thought of the following as a Motivation Continuum for today’s teams—
I’ve written a lot about product ownership, product backlogs, and user stories over the years. But the other day it struck me that I hadn’t shared something that has worked well for me for many years.
It’s an idea that is coupled to two notions—product backlog refinement and the 3-Amigos metaphor for story evolution.
I noticed in several companies I’ve worked for that teams struggled with getting the stories effectively delivered. There seemed to be, for lack of a better phrase, a lack of ownership in story delivery. That is, stories often missed the mark in functionality, quality, integration, etc. And when we discussed this in our retrospectives, there was a lot of finger-pointing and blaming, but no real solution ideas.
I believe I tried this first at a company called ChannelAdvisor around 2007-2008. So, you can see why I’m surprised that I haven’t thought to share it until now.
I’ve always been a huge Pink Floyd fan. And Dark Side of the Moon is one of my top 100 favorite albums of all time. And Time is one of my favorite songs on it.
Here’s a snippet from the lyrics that I think serve as a fine entry for this post.
So you run and you run to catch up with the sun but it's sinking
Racing around to come up behind you again.
The sun is the same in a relative way but you're older,
Shorter of breath and one day closer to death.
But I digress…
I’m mature, experienced, or old enough to remember a time when software development was treated as a time-based activity.
You were measured by—
How fast you typed
How many lines of code you wrote (per hour, per day, per project)
How many hours you worked (typing as fast as you could)
How much time you spend (not typing) in meetings, writing documents, etc.
How quickly you could hack-together a design
How many bugs you produced
How many times you had to rework your code
How many breaks (bathroom, lunch, etc.) you took and for how long
I believe the thought at the time was—the more time you spend working, the more value you delivered to the company, the more you earned your pay. The optimization goal in this case was on time and production.
Sounds like a really good model, doesn’t it? And I’m not joking with the above. This was real!
I’m writing this around the time when businesses are essentially locked down by Covid-19 and everyone is working virtually. It remains to be seen what types of working habits and new norms will emerge and stick after we recover from this viral attack.
Here I’d like to explore SAFe PI Planning as a planning construct or pattern. Talk about the origination of the idea. Then explore remote PI planning as something that we could do virtually.
But what I really want to focus on is an extension to PI Planning that could nearly negate the need to do it either face-to-face or virtually.
PI Planning – The Intent
The intent of PI Planning is to get a number of teams together for face-to-face planning once a quarter to commit to a body of collaborative work. It’s a scaling tactic that has its roots well before agile hit the mainstream. For example, a similar pattern was shared by Dwayne Phillips in his book The Software Project Managers Handbook, published in 1998. Dwayne called it Cards-on-a-Wall planning. I’ve used the technique to plan larger-scale waterfall projects with 100+ participants.
This post is inspired by one from John Cutler.
I want to take a diversion a bit on John. I was talking about his article at our Agile Moose Herd the other morning. I shared that he is one of the “Top 10” folks in our industry (agile, products, transformation, culture, etc.) that makes me think more deeply with everything he writes. John is a thought-provoker, a leading-edge thinker, and a courageous writer. He often says, what needs to be said, before anyone else is saying it. I truly appreciate his voice!
Now, back to the post. It was fairly short and entitled—Kryptonite and Curiosity.
John started out by exploring common organizational phrases that can be kryptonite in nature. That is, they can trigger a negative response in us. For example—Bring solutions, not problems, was one of them. You get the idea.
