I might be the first one to complain about bad managers. Heck, throughout my career, I’ve had more than my share of incompetent, self-centered, and poor-intentioned leaders. So, it would be easy for me to jump on the bandwagon in the agile community that lambastes managers on a daily basis.
No, you say. This doesn’t happen. We in the agile world embrace and respect all roles and all people.
Well here’s an example from the Larman & Bodde – Large-Scale Scrum (LeSS) book. The reference is from Anton Zotin, an agile coach, and it was published on LinkedIn. And no, I’m not picking on Anton or the LeSS guys. I’m just using this as an example. There are countless others.
I was having an email conversation with an agile coaching colleague the other day. In one of her replies, she said the following:
BTW I really like the way you articulate your concerns about the agile community at large. It’s helpful to share with my leadership and customers as we try to navigate a very messy space of certifications, frameworks, and competing agile voices
The final point she made really struck a chord with me. The notion of competing agile voices.
It made me realize that, YES, there are many, many agile voices today. And one of the real challenges is to figure out who to listen to. Where’s the value and the experience? And how to avoid the “noise” or how to separate the wheat from the chaff?
I want to share some ideas around this challenge. No, I’m not sharing any secret filter or the 1-person to listen to. They don’t exist.
But I do want to share some advice for handling the high voice count and how to become a more discerning listener when it comes to the noise.
And it’s getting worse…
I read an article by Angie Jones the other day entitled - 7 Habits of Highly Effective SDETs. If you know me, you know how enamored I am of Steven Covey and Angie, so I read it with great anticipation.
And indeed, it was a great piece that focused on the evolution of testing and the testers role.
But it also made me think about testers in a different way. A melancholier way. It reminded me of the song, Where Have All the Flowers Gone, by Pete Seeger. It’s a very dated folk song written in 1955. A year before my birth ;-)
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.
I have a confession to make. I’ve fallen into a trap and I need to get out of it.
Gosh, Bob, what’s wrong? What is it you might ask?
I’ve been saying: “The Scrum Guide says” way too frequently. It’s almost a daily mantra and I suddenly realized that I need to stop it.
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.
I’ve been teaching and coaching Scrum for nearly 20 years. During that time, I’ve always tried to stay true to the basic Scrum guidance and the Scrum Guide. But I’ve also shared my own practical experience.
One of the things that I’ve been consistent about in my guidance is that the ScrumMaster is NOT a manager or HR role. That is, they should not be “mucking around” with personnel performance issues. At least not directly.
For example, they should not be writing/executing Performance Improvement Plans (PIPs) or removing folks from teams or firing folks.
So, you can imagine my shock & chagrin when I saw an article by Barry Overeem that seemed to be saying the opposite. Now I’ve followed Barry for many years and I normally align with his recommendations. Or at least I see the soundness in his perspective. And often he simply makes me think about things in new ways. Which I appreciate.
But in this case, I think this is a very dangerous point of view and flat out wrong. So, let me share my thoughts…
There’s been a movement afoot in the agile community for a while. It’s about getting back to basics. I characterize it as:
- Agile leadership is nice, but…
- Agile planning & forecasting is nice, but…
- Agile Project Managers are great, but…
- All the certifications are nice, but…
- Scaling frameworks are nice, but…
- Accenture, Gartner, etc. interest is nice, but…
- DevOps and Business Agility are nice, but…
- Adoption, transformation, etc. are nice, but…
- Making $billions is nice, but…
We’ve lost the essence of agility. We’ve forgotten the very things that got everyone excited in the first place. The simplicity. The power of the team. The results that an engaged customer can inspire.
In the first part of this post, we explored these “rules”:
- Allow Architecture to Emerge
- Treat it Like a Product
- A Picture is Worth…
- Everyone IS an Architect and Everyone OWNS the Architecture
Now, I’d like to continue sharing the final set of four rules for your consideration in your agile architectural travels.
#5) Keep it Simple and Connect to the Customer
This one is quite near and dear to my heart. Why might you ask? Because I really like complexity. I like engineering complex solutions to simple…complex customer problems. And it’s also quite comfortable for me to fall into that over-engineering, gold-plating, doing more than is required mindset.
Wow, the title sounds quite bombastic, doesn’t it? And I sound quite full of myself, don’t I? Well…perhaps I am.
Nevertheless, I want to go on record with some simple and pragmatic advice for agile organizations and teams when they’re trying to sort out how architecture “fits” in agile contexts.
In no particular order, here are my guidelines:
#1) Allow Architecture to Emerge
I know you’ve heard this before, but it’s really, really important. The difference is moving from traditional architecture, which –
- Performs Big Design Up Front (BDUF), aka Big Bang;
- Develops a “complete” architectural concept before coding begins;
- Approaches construction horizontally, with delayed layer integration