I’m Not Here to Be Your Friend
I was recently talking with a friend who was having some problems with adopting Scrum on a couple of their teams. They were describing symptoms I’ve seen before in organizations where the QA folks struggle to keep up with the rest of the team. Because I enjoy inflicting help on people, I offered to talk to them on my own time to offer some stories and experiences that might help them.
Some of the symptoms included not finishing the sprint work, disagreements about what done meant to the developers, testers and business people, struggling to finish regression, missed deadlines and releases. It’s always tough to gather enough context in a short amount of time to offer some advice. I could see the main challenge was getting the team to buy into a shared goal and removing the silos. Having said that, these guys seemed quite collaborative, I think they were simply having problems adjusting to Agile given they’ve only been trying it for a couple of months. I think they’re on the right track and seem committed to improving which is just great. Anytime people want to give up their own time to learn is a good thing in my books.
As we talked about ideas about how to find balance I suggested one way to help manage these symptoms is to pull less work. Of course every action has some impact and I mentioned that this can create idle time, especially in cases where “the development work” is low effort but the “testing work” is high. You could have developers idle! Nooooo! I could see an adverse reaction to that suggestion so I made a joke about making sure “resources” are 100% utilized! The reality is, people need slack, especially to learn a new process and move forward.
I asked the product owner flatly that if they are missing releases now. He said yes. I asked if they have quality problems as a result of in-sufficient testing. He said yes. I then asked what’s the harm of slowing down? Your missing releases with lower-than-desired quality now. You’re only fooling yourself if you think slowing down is going to cause problems because you already have those problems now.
I could feel a bit of shock from a couple of people in the room after I said that.
The point is, when you are looking for a coach or consultant, they’re not there to be your friend. They are there to help you figure out how to solve, manage or cope with your problems and you are not going to like some of the answers you get. A good coach is going to tell you either the brutal or kind truth and the best you can do is establish personal safety by having an agreement and shared understanding about what is expected from the coach from your perspective and the same from the coaches perspective. Once you can get that agreement in place what unfolds can happen in the name of progress.
Does Your Stand-up Happen After the Stand-up?
The daily Scrum (AKA standup) is not a status meeting. It’s purpose is to provide a forum for team members to co-ordinate their work and raise any obstacles preventing them from getting that work done. I’ve noticed a pattern from numerous teams I’ve worked with and am wondering if you’ve noticed the same.
The “stand-up” ends up being a ritual where the drones…er team members, answer the 3 questions because, well, that’s what Scrum says you’re supposed to do. What did you finish yesterday, what will you finish today and what’s blocking you. Pretty simple stuff. I worked with one team that had terrible ‘standups’ until they started sitting down. One team member (who was kicked off the team) made it a point to bring Ken Schwaber’s book to prove to me that you don’t have to stand at the standup. I asked him if he could remember a time when I said they had to stand-up. He grumbled and stormed away.
I’ve noticed a pattern of teams going through the ritual only to do a real standup after they finish the ritual. The ‘standup’ itself is a status meeting with the 3 questions and I’ve noticed the teams that exhibit this pattern finish that pretty quickly. Then they move on to the real standup, focus on the work on the task-board and co-ordinate their work for the day. I’m sure some purists would call this some type of critical dysfunction, but what’s the harm? From my observations, the ritual lasts 5 or 10 minutes and the ‘real’ standup about the same. Oops, that puts us over the 15 minute time limit. I guess all is lost then.
How about you? Does your team function like these other teams I’ve observed?
A Retrospective on Retrospectives
I had an opportunity to help another team out with their retrospective the other day. These guys hadn’t done one in over 3 months so I offered to help out. I was curious to understand why they had stopped doing them although I was pretty sure I knew why already. Keep in mind this team isn’t following Scrum, they practice daily standups but otherwise it’s (IMO) just adhoc process which suits the type of work they’re doing.
One of the team members was busy and couldn’t make it (which was a piece of data on it’s own) but we went ahead anyway and did a safety check first. I don’t remember the exact name of the techique from Diane Larson’s and Esther Derby’s Agile Retrospectives book, but it’s the one where you ask people to write down whether they are an explorer (fully engaged), shopper (want to pick out at least one idea), vacationer (yes! I don’t have to do REAL work!) or prisoner (get me the H outta here!). I was pleased to see all “E”‘s.
I explained to them as a facilitator I wouldn’t be participating and that I’d just be helping. I offered a couple of suggestions, a retrospective on why they stopped doing retrospectives or a timeline of the last few months similar to a release retrospective. They opted to go with the retrospective on why they stopped doing retrospectives. I asked them to write down some positives and negatives about past retrospectives that I hoped would spark some dialogue. The output was simple and we were done really quickly without much discussion:
Good Things:
- had a chance to slow down and talk about how things were going
- got to see thoughts from other team members’ perspective
Bad Things:
- they had been combining their retrospective with another team (it’s a small company, so they’d have about 10 – 12 people from 2 teams that work fairly closely in one retrospective). As a result, the other team was dominating the retrospective
- they were too busy to do them
Those were the two main items from each after we clumped them together using an affinity diagram and after a quick chat they decided on one thing to start doing. Start doing a 30 minute retrospective every 2 weeks. 30 minutes was enough time to ‘be away from work’ and I suggested they put up a timeline to capture good and bad things as they come up. They thought that was a good idea and they also agreed that one person would take ownership of the retrospective every two weeks so they would be sure they’d do it. Time will tell I suppose!
The energy was really low during this retrospective as well. It felt a bit forced as I had to poke them to get them to open up a bit and try and focus on each other instead of me. We wrapped up quickly since I sensed they were pretty tired and since we got to the point quickly, there wasn’t much reason to keep going.
I learned something too. Next time I facilitate, I’ll get out of the way. Like, physically out of the way. We have a couch and a couple of chairs in the area that are setup great for discussions, next time I’ll stand outside the circle.
I had done something similar with the other team as they had mentioned their last few retrospectives ‘sucked‘. Their reasons were similar and they also added that they rarely have any tangible or actionable output to move forward with. They just end up talking and talking with a lot of “we should…” language.
Next time you experience teams going through the motions or feeling like retrospectives are getting in the way of ‘real work’, try uncovering why they feel that way. Chances are there are some problems under the covers that you can clear up pretty quickly and get back on track.
