I periodically do a coaching circle as a service to our agile community. I invite anyone to it and it’s free. Think of it as a Lean Coffee format discussion with folks looking for coaching advice.
This question came up the other day:
I'd like to hear how your teams handle spikes - do spikes have acceptance criteria - yes/no? Do spikes have story points yes/no?
And it generated quite a nice discussion around the idea of spikes. And it made me think about whether I’ve ever written about them before. I was shocked to realize that I really hadn’t done a deep dive into my thoughts on spiking. Well, here goes nothing…
I engaged a contractor to come over to my home the other day to give me an estimate for doing some external work on my house. I needed some carpentry repairs to my siding, a few windows replaced, and a few repairs to my screened-in porch.
The weather has been challenging lately in NC so the house has taken on some damage. Not too much, but I like to stay ahead of things regarding maintenance.
He gave me an estimate for his time (hours) and costs to repair each item.
I was sort of taken aback by the estimates. They seemed much longer/larger than the ones I had done on my own so I shared them with him.
When I did, he gave me a sideways stare. He said that if I wanted to do the work, then my estimates were valid. But if I wanted him to do the work, then mine were irrelevant. He noted that this is what he did for a living, that he had glowing recommendations (he did!) and that he stood by his estimates as valid.
He also mentioned that, with all due respect, I was biased. I was the customer so I saw things in a different light (easier, quicker, lower cost) then he did. He also mentioned that I had little (recent) experience ;-)
In the end, he said that I either trusted him or not. And he asked – did I want him to do the job?
I quickly apologized for my presumptuousness, and wholeheartedly said YES.
I saw a LinkedIn discussion thread that was initiated by Allen Holub. The initial post was:
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 –
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.