Tuesday, October 18, 2011

Scrum: Retrospective Questions

Clinton Keith, in Agile Game Development with Scrum (pg 79), lists the three questions that should be asked in every retrospective as:

1) What things should we stop doing?

2) What should we start doing?

3) What is working well that we should continue doing?

These are solid questions that are straight to the point and that match the simplicity of the Daily Scrum questions. However, what do you do if there aren't any contributions? After reading this article on Gamasutra, I got to thinking about just that. I've been in meetings that aren't active and they're a drag. Therefore, I believe that having a few canned questions to get things going isn't a bad idea. This is especially true for teams that are new to scrum.

Before I dive too deep, I recommend the above article to anyone that is looking for some good advice on how to run an interview. I'll explain how this ties into sprint reviews in a second. In the article, Jeremy Gaffney offers some ideas that will help folks being interviewed as well as those that conduct them.

Here were my takeaways:


-First, the quality of the interview is in the quality of the questions that you ask.

-Second, the value of a candidate is found in what they find valuable.



From the article...

“Ask questions for which there are no uninteresting answers,” Gaffney said. For example, a producer may ask, “Who’s the last person you fired?” He explained, “What you care about is digging out an interesting [aspect] of their past.”


Asking someone who they've fired is an interesting approach to reach the core of a candidate. However, my vote would be to keep things slightly more positive. You could try something like:

- What was your biggest success and how would you go about replicating it?

- Can you give me an example of a situation where you were certain that you were going to miss a deadline and what you did to dampen the impact?

- What are the most useful habits that a team member can exhibit?


Now then, this all parallels into a retrospective because the same rules apply. Let's think about what we're trying to get out of the retrospective in the first place. Well, this ceremony is the closure of the feedback loop. It's only logical that we'd want to inspect what occurred during the iteration to see if there were any lessons learned.

- What did we learn?


That question by itself isn't going to make the conversation flood in. How about...

- While building the onboarding tutorial, were there any aspects that you would like to revisit in the next iteration?

or

- While building the onboarding tutorial, what optimizations did you make to your workflow that helped you along the way?


Use the Sprint Backlog as the springboard to target meaningful data points. The goal being to key in on specifics with an eye on finding value that the project or team will benefit from. Asking quality questions can surface improvement issues/technical debt, new useful techniques, bottlenecks, and product insights. A good retrospective will have each and every team member walk away with a new technique to try or insights on how to improve efficiency. To create a culture of sharing is essential in building a successful team.

RE: canned retrospective questions, here are some to get you going!

While doing Sprint Backlog Item (SBI), what aspect was most challenging and why? What would make it less?

If you had to rebuild SBI, what approach would you take next time around?

What beneficial optimization to workflow did you make during this sprint?

What new resources would have improved our production cycle?

Were there any heavy refactors necessary this time around? If so, why?

Did you read any informative articles that inspired some change which directly effected this sprint?

Analyzing the problems and impediments from last sprint, have any similar issues resurfaced this time around?


I think you get the point. The goal is to get the conversation moving and to see what we can learn from one another and, thus, help us all make life that much easier.

Tuesday, October 4, 2011

SCRUM 101

Here's a quick presentation that I put together that discusses the history of SCRUM and its mechanics. It's ment as an overview and not the definitive explanation.

Whether you're a software engineer, a QA tester, a producer, or an executive that manages development you would benefit greatly by implementing some sort of Agile project management.

I hope you find it useful.

About Me

I produce and engineer games and applications. | Portfolio | LinkedIn