Today someone asked me what I considered to be the most rewarding part of product management. Immediately, that quiet moment after sprint planning is complete came to mind. As the team files out of the conference room and I’m breathing a sigh of relief, I feel an incredible sense of accomplishment when the team has tasked out the sprint stories, we’ve managed to balance development and QA work loads, and everyone is excited to build the next feature.
That’s a mighty tall order! If all has gone according to plan, the following things have come to pass:
We’re doing the right thing. I’ve worked with the business owner and prioritized the product backlog properly so that we’ve chosen the right thing to work on next.
We’re doing the right sized thing. I’ve worked down the chain from the business owner through the architect and the development leads to tease out the requirements of the story in the context of a larger epic deliverable. Everyone has an understanding of what we’re trying to build, and we’ve bitten off just enough of it to complete in a single sprint. For this reason, I’ve found planning poker to be the single most valuable planning activity outside of sprint planning.
Everyone has some understanding of the thing. No one wants to hear about a feature for the first time during sprint planning. It makes a world of difference if the team has an idea of what’s coming up in the next sprint. We’ve talked about the release scope, we’ve done planning poker, there have been informal discussions across cubicle walls with a cup of coffee. Gaining clarity is a two way street – I’ve lost count of the number of times I’ve run back to my office to add requirements to an upcoming story or to add a new story to the backlog given an informal conversation in the hallway. It makes such an incredible difference during sprint planning when the acceptance criteria for a story are clear and concise.
We’re working as a team. I’ve been fortunate to work with a few great teams over the years that shared the common goal of building great software. These teams were characterized by a lack of ego, a willingness to step outside their comfort zones, an understanding that we all make mistakes (and that’s ok, but let’s learn from them), and a commitment to update the process to do it better next time. Let’s make different mistakes.
We look after ourselves as well. I’ve seen it way too many times. Some people either because they are eager to be a part of a team, afraid to let them down, or some other reason, will not speak up when something is not working on their end. Ideally someone is there notice, be it there is supervision of some kind or close communication due to the nature of the project. This doesn’t always happen, and the end result can sometimes be that now you have to deal with an issue that could have been easily resolved distributed with the time against you. I have even seen people go as far as to not inform the team that they are sick, not feeling well, or otherwise personally and completely understandably indisposed.
It’s hard to say with some people, what even causes it, but it does happen. I can’t say I’ve seen it with me so I don’t have a personal story for you, although it has happened to people around me and plenty. Once I was really sick, and had already taken a few days off as per doctor’s instructions, but we were on a deadline and the work needed to get done so there I am. I had to buy oxycodone to deal with the serious discomfort and it was helping, but focusing proved difficult. In the end I had to tell my team what was going on. I thanked them so much for understanding, and was deeply apologetic. They could see that I was still way too sick to work though. They thanked me for going over and trying though. I came back firing on all cylinders eager to help pick up the slack as thanks. Good teams with good synergy get things done, and it’s enjoyable to be part of one.
I’m lucky to have had more than a few of these quiet reflective moments over the years, and looking forward to more adventures in software development.