Reading Better People, Better Process may make it seem like I’m one of those touchy-feely “people over process” types. I confess I have a fondness for people but I’m also a big fan of process. Luckily, people and process don’t exist as either/or. People and process exist as both/and. Here’s a process that can both improve your other processes your people, and the process itself.

Another Multiuse Model

This model is another Multiuse Model. This process tells what to do in a retrospective. Retrospectives occur when we stop, think, and decide what to do next. We call a one person event “introspection”. A software development team may have a facilitator for their retrospective. Retrospective permutations abound. Here are the steps for a successful retrospective.

1. Set the stage – get focused
2. Gather data – create a picture of what happened
3. Generate insights – why? And what could be done differently?
4. Decide what to do – what one thing to do, and what is the first step?
5. Close – decide how to document and plan for follow-up.

You can learn more about this process by reading Agile Retrospectives. If you are a person who would like to go from good to great, and/or work in/with teams and/or organizations who you’d like to go from good to great, stop reading now and order the book. I’ll wait.

Back already? Wonderful.

So why do a retrospective? Retrospectives involve the Learning Loop. By continuously learning to improve our process, we can learn to improve ourselves. As we improve ourselves we can improve the retrospective process. A conscientious facilitator does a their own retrospective for every meeting they facilitate. George Dinwiddie and I facilitated a two day product owner release planning meeting. After each day we met to discuss what happened that day, what it might mean for the product owners (and us), what we could do to improve, and what changes we would make for the next meeting.

Hints and Suggestions – Three Possibilities

As a bright shiny new ScrumMaster, my retrospectives always included: “And what one thing would we like to work on to improve during the next sprint?” As I prepared for one retrospective, I thought, “Wow. All I ever do is ask what they’re doing wrong. What would happen if I asked about doing more of something they’re doing good?” Based on the what the Gather Data and Generate insight steps reveal I vary the question to focus on:

• Improve (change) something you’re currently doing. Based on their retrospective, one team decided they were making too many assumptions and needed to get the product owner’s input.
• Do more of something you’re doing well. One team noticed the developers were finishing the sprint in good shape while the testers struggled to complete the manual and automated tests. The team decided to have developers work with the testers earlier in the sprint to increase the teams over all velocity.
• Add something you’re not doing. I worked with one team that decided to schedule a meeting with the product owner mid-sprint to update the product owner with new information and verify the team had the spriint goal still in focus.

For the most variety ask the team to create possibilities for all three categories.

Only One Thing

Choose one change to work on. I’ve observed a some details over the years:

1. Teams generate many possible change items.
2. In a team of equals, some team members are more equal than others. This may be due to experience, longevity, or just plain loudness. I deal with this by giving each team member two votes and then call on team members for their votes making sure not to call on the “more equal” team member first. The item with the most votes gets proposed for the “do this” for the next sprint.
3. Any change can create instability. Too many changes at once will push the system to instability and dilute the change impetus pretty much ensuring nothing really gets changed.

Buy In

The team needs to buy into the decision. I recommend using the team’s norm for group decision. I’ve seen the “Fist of Five”, “Roman Thumbs”, head nodding, and probably a couple I’ve forgotten. The point is to get everyone to agree with the decision. If the whole team doesn’t commit to make the change happen, it probably won’t happen.

Follow-up

Pay attention to the change during the sprint. If I don’t see evidence the team is working on the agreed change, I ask a question at the end of the daily meeting about how the team is doing with the change. During the “gather data” portion of the next retrospective I include a question about how the team feels they did on their change idea. Failing to follow up on the topic teaches the team that constant improvement isn’t important. All you get from then on is grand ideas and lip service.

The Unaimed Arrow Never Misses

If you’re the facilitator, structure the retrospective as neutrally as possible. This is easier said than done if you also serve as the team’s ScrumMaster. It’s critical for the team decide what change they’re going to attempt. Structuring the retrospective or guiding the conversation to your predetermined result will result in less commitment if not out right rejection from the team.

What’s Next?

The basic cycle is do, inspect, adapt. Doing starts the cycle. So do something. Then inspect, adapt, and repeat as necessary.

If you don’t have Agile Retrospectives I’d suggest you start by reading the book.

I’ll be leading a session at this year’s AYE Conference involving Introspection. The conference still has 8 openings.

She hasn’t served me well for a number of years and done some things that have severely impacted me – instead of a $7,500 tax refund, I got a $3,000 bill (because they got a $15,000 donation wrong) and I was given a bill for $2,000 with a single line itemisation “professional services”…

Not entirely dissimilar to your insurance agent.

What’s the pattern/anti-pattern here??

Loyalty + Outsourcing. (I reckon )

As a small sole-practitioner, I need to outsource many things – normally you’d think of large organisations outsourcing, but I suspect that small business are the major outsourcers. There are a bunch of things that I have to hire ‘professionals’ to do – down to having a mechanic for my car, an accountant, insurance agent, employment agency, lawyer, bank, ….

I need to focus on my business, what I do well, and hand off to others things that are peripheral and I don’t have the time, inclination, training and possibly aptitude to do well enough, or maybe be sufficiently expert in… I can afford to pay a premium for those services (in terms of hourly rate) because (apart from the recruiters) I only use them occasionally and the total impact on my budget is small. It’s like building a pipeline – the straight bits of plain pipe are commodity items and priced accordingly, the tricky bits – bends, joins, valves – are a very small but important part of the pipeline. There aren’t too many people that can do this stuff and they can charge a premium. It has to be right, it has to be on-time and it’s under 1% of the total contract (a guess).

So back to my accountant. I selected her by asking friends for references. We got on well enough and the price/service was acceptable. Then it was a ‘handled’ problem – I’d outsourced the work and it just kept ticking over – no decisions required. It’s not laziness, but prioritisation, like cleaning that attic, basement or garage out. Things will keep running just fine unless there is an emergency like a fire, flood or a relative moving in. When people die, others get to look at the things they’ve ‘deferred’ dealing with – and it looks like a complete mess and a hopeless tangle of junk… But they lived just fine that way. (In Australia, farmers build another shed to store stuff. These are amazing places to find old & sometimes valuable things. “Clearance Sales”, when the *entire* contents of a farm are sold by auction in one day are quite some fun.)

And I’m pretty loyal as well. That’s a pattern that usually works well for me personally and professionally.

Finally, I’d reframe your blog question from “What’s the anti-pattern”, to “When does a useful pattern become an anti-pattern?”

Having a single insurance agent you “just go to” is a very useful pattern – until they screw up or screw you around. Then you have to go through the pain of finding someone new… It’s trivially obvious that doing a through & exhaustive evaluation of *all* suppliers in the marketplace for *every* purchase/service is a waste of time – especially for micro- and small-business where you have very limited internal resources. And, if you work out the opportunity cost, the money saved each time will be much less than you could’ve earned with that time… Guess that’s why bigger organisations tender for goods & services – but only for a limited time. Take the hit on selecting someone – the pain, time and cost – and then reap the benefits of a single supplier. At least with a contract, you schedule when you’re going to reconsider a relationship.

Remember in PSL the lesson of “success leading to failure”?? Early success leads to a ‘lock-in’ of the solution method. Mostly the method doesn’t scale, but it’s always worked for you, so you have to stick with it until it fails catastrophically. Hopefully, you’re still around to be able to rechoose.

Stephen Jenkin, Australia