I saw a LinkedIn discussion thread that was initiated by Allen Holub. The initial post was:
https://www.linkedin.com/feed/update/urn:li:activity:6503389838526468096
What practices are best at promoting culture? A couple years back, Robert Martin and I had a somewhat public debate about whether culture or practices come first. Bob advocates the shu-ha-ri approach: start doing practices, even by rote, and the culture will naturally arise. He used someone bowing when stepping on the mat as an example. At first, it's just rote. Eventually, respect emerges. I took the opposite approach: start with culture and good practices will emerge. If you have a culture of trust and autonomy, better lead time is a natural outcome.
In the real world of consulting, however, it's very difficult to *start* with culture. The people writing the checks typically want to improve something more hands on. So, my question is: in that world, where you need to start with practices, which practices (if any) lead to a good culture the fastest? If you're introducing practices in order to change culture, which practices would you introduce? I have my own ideas, but I'm interested in your experience.
I’d like to riff off of this a bit. I’m thinking of a couple of things:
Do practices lead to culture OR flip it. I think it’s a flip and Allen seems to agree BUT then backs off because it’s hard.
Is that the right approach? Or is it a business-related copout?
And what about the idea of Culture Hacking. Which I haven’t heard a lot about lately. Could that be part of it.
I like this post because it gets to the root of what a view as a BIG problem. And if everyone ignores it, where does it leave us?
I was reading a blog post from a coach who was working with a continuous deployment team. In essence, every story (work item, PBI, etc.) from their sprint made it into the customers hands immediately. They received feedback on each in real-time and took follow-up actions as appropriate.
Since they were using Scrum, they were still conducting a Sprint Review every few weeks. The coaches question related to the value of the review. As it seemed that everyone was questioning it in this particular context. That is, since they saw (and accepted) things in real-time, what was the need to see them again in a review? Or were they just doing it because the Scrum Guide said to do it?
And the backstory was that the coach was struggling with dogmatic Scrum in the organization. I.e., doing things just because the book said to do them, rather than thinking and adapting.
This question made me think a bit about Sprint Reviews. And it led to the following online response to that coach –
My reply
In May of 2018, I published this Back to Basics post -
http://rgalen.com/agile-training-news/2018/3/5/back-to-agile-basics
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 –
https://techbeacon.com/how-software-teams-can-measure-anything-qppe-metrics-model
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.
https://www.infoq.com/articles/future-ready-organization
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…
Estimate Newbie
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.
For #1
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.
Basic Definitions
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…
