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.
Perhaps it’s just me, but I’ve been indoctrinated into the Tuckman Model as THE view or model when it comes to team maturation and overall health.
You all remember Tuckman, don’t you?
He presented the following stages:
- and Performing
- sometimes Adjourning
that teams go through in their evolution to a solidly performing state.
One of the things that it’s influenced in my coaching and leadership style is the predilection to honor the team. That is, once a team is formed and performing, I am loathed to break them up for whatever reason. Even good reasons like the business priorities have changed or there is a desperate need for the skills of one team member in another team. Or even, the team has some dysfunctional relationships brewing.
For years and years, I've been a strong advocate of goal-setting within your agile teams. Ares where I think goals are important include:
- At the daily stand, focusing the conversations towards the teams' goals;
- During sprint planning and at the sprint review, focus towards the sprint goal;
- If you're doing releases, ala SAFe release trains or a similar mechanism, then having a release-level goal is important;
- To me, Definition of Done and Definition of Ready, are goal-oriented. Providing clarity on the teams' constraints;
My friend and colleague Shaun Bradshaw and I were coaching at a client recently. We started to have a conversation about velocity, not directly driven by the clients’ context, but simply in general.
Shaun was focused on velocity as a relevant metric within agile teams to drive conversations between teams and upper management. And I was struggling to “get there”.
Part of his focus was to create visibility around the difference between average velocity and current sprint velocity. Furthermore, the teams and management would be able to see:
- Velocity gaining stability over time (predictability, low variance)
- And increasing over time (short-term burst)
As part of newly formed and/or newly coached agile teams.
Now I really get what he was saying. And I agree that teams in these contexts should be displaying activity and behavior towards those two results.
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