Viewing entries in
Agile Execution

12 Considerations for User Story Spikes

1 Comment

12 Considerations for User Story Spikes

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…

1 Comment

Product Owners – can / should they weigh-in on story estimates?

2 Comments

Product Owners – can / should they weigh-in on story estimates?

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.

2 Comments

Practices vs. Culture

1 Comment

Practices vs. Culture

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?

1 Comment

Opportunities in an Iteration or Sprint, Review and/or Demo

1 Comment

Opportunities in an Iteration or Sprint, Review and/or Demo

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

1 Comment

Back to Basics…Part Deux

Comment

Back to Basics…Part Deux

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

Comment

QPPE Metrics Model – A Measured Reaction

Comment

QPPE Metrics Model – A Measured Reaction

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:

Comment

Sprint Planning – Simple, and yet…

Comment

Sprint Planning – Simple, and yet…

It’s really quite funny. I’ve been coaching and teaching Scrum for nearly 20 years. But sometimes, my knowledge and experience sometimes gets in the way, in that I sometimes forget that the simplest of the ceremonies can often be hard to get…”right”.

One of those is sprint planning.  

I recently stumbled across two references that I think are very helpful in executing this simple and important, yet sometimes hard to get right ceremony.

The graphic is from Joshua’s article. I really like it!

I’ve also written a quick helper guide around how I’ve found it best to get started in sprint planning. Mostly with new teams. It’s a recipe I’ve successfully been using for well over 10 years and I hope you find some useful hints within.

Here’s the link: https://robert-galen.squarespace.com/s/Scrum-Sprint-Planning-Overview.pdf

Wrapping Up

Sprint planning is one of those ceremonies that embodies quite a lot of agile skills:

  • Backlog refinement

  • Estimation (at a story and task level)

  • Effective story writing

  • Collaborative workflow

  • Done and delivery

Getting it “right” can help you and your teams accelerate towards delivering on the promises of Scrum.

Stay agile my friends,

Bob.

Comment

Arie on Organizational Change

Comment

Arie on Organizational Change

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.

Comment

My Journey in Software Estimation - What a long strange trip...

Comment

My Journey in Software Estimation - What a long strange trip...

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.

Comment

Creating Business Agility

1 Comment

Creating Business Agility

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: 

  1. Get Executive Buy-in and Agile Mindset

  2. Agile Leaders Should Get the Right Mix of Talent

  3. 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.

1 Comment