The Product Owner Simulation that I shared last summer has some minor updates based on a stronger emphasis on product vision. In particular, two 5 minute exercises before and after the Product Box exercise help to frame the concept of product vision and make it stronger.
Scrum has really come far!!! Check out “Scrum Your Wedding“. I love the ScrumMaster and Product Owner tips. Here’s a good one:
SCRUM MASTER TIP – The stand-up is overkill in most wedding planning scenarios, but we do think it’s useful to ask the questions at least a few times per sprint, perhaps over email. It’s your job to make sure the questions are asked and answered.
They have taken the core ideas of Scrum and made some intelligent modifications to make it suitable for a fixed deadline event planning scenario. Honestly, I think that the ideas presented here could be a great approach to doing Scrum on other similar fixed deadline projects. Thanks to Hannah Kane and Julia Smith for creating a unique and useful resource!
The Scrum Alliance just announced through a press release the Added Qualifications [PDF] program. From the release:
The Added Qualifications program will begin by first offering courses in Scaling Scrum Fundamentals. Those interested in earning an Added Qualification in Scaling Scrum Fundamentals will need to hold at least one of two foundational certifications, Certified ScrumMaster® or Certified Scrum Product Owner®.
More information can be found on the Scrum Alliance Added Qualifications page.
Through World Mindware, we will be introducing courses over the next months to help you achieve these new Added Qualifications.
Pair Programming Economics by Olaf Lewitz describes three activities in programming: typing, problem-solving and reading code. How does pair programming help? By making the balance between those three activities better.
I was poling around for a good definition of DevOps and found a thoughtful article written by Ernest Mueller called What is DevOps? Highly recommended reading as it includes lots of insight about the relationship between Agile and DevOps. FWIW, I feel that the concept of the Definition of “Done” is Scrum’s own original take on the same class of ideas: breaking down silos in an organization to get stuff into the marketplace faster and faster. I even talked about operationalizing software development back in 2004 and 2005 as a counterpoint to the project management approach which puts everyone in silos and pushes work through phase gates.
Retrospectives are a key part of continuous improvement in Agile teams. The retrospective techniques that a team uses should be adjusted to the needs of the team. In a Scrum team, for example, the ScrumMaster will often decide on the techniques to use based on the current issues facing the team and then facilitate the retrospective for the team. There are some great resources which give you collections of tried-and-true retrospective techniques including Esther Derby’s book “Agile Retrospectives” and the amazing online tool “Retr-o-mat“. As an active consultant and trainer, I am always looking for new techniques to share with my clients. Sometimes, I even create a new one (or at least new to me). The “What Did You Learn” technique is new: I’ve been using it and testing it for a few years now to refine it.
What Did You Learn?
By itself, this is a powerful question. As part of my work with OpenAgile, I’ve been helping teams and organization to focus on learning as an even broader category than continuous improvement. The Learning Circle and the processes in OpenAgile help with focusing on learning. The question “what did you learn?” is very open ended, and can certainly work as an extremely simple type of retrospective in OpenAgile or in Scrum or other Agile methods. Often people like to have a little more structure and guidance so the “What Did You Learn?” retrospective technique provides four categories of learning for people to think about, share, and discuss within a team.
Setup for this retrospective is very simple: a flip chart or whiteboard divided into four sections or columns works fine, along with a piece of paper for each person in the retrospective, divided up the same way, and sufficient markers and pens for everyone. Here is a downloadable PDF version of the handout for the “What Did You Learn” retrospective.
The facilitator will also participate at various points if they are a member of the team (e.g. a ScrumMaster). It is easiest to do this with a group in-person, but can also be done reasonably well with video or teleconferencing.
The facilitator introduces the retrospective with a welcome and, if necessary, a recitation of the Retrospective Prime Directive. Then, the process is described to the group. Each of the categories of learning is also explained as follows:
- Questions. When you can formulate a question about something, it means that you have learned about a gap in your knowledge. In other words, you have discovered something that you would like to learn.
- Information / Data / Facts. These are specific details that relate to some area of knowledge or skill. This category of learning is the simplest and is often what people focus on when asked “what did you learn?” Information tends to be dry and unemotional.
- Insights / Concepts / “Aha!” Moments. Often when we have a collection of facts or an experience, we see a pattern or make interesting connections between things. This leads us to the great feeling of an insight. Insights tend to be exciting or scary and have an emotional component.
- Action Items. These are decisions about what we would like to do in the future, but they could be extremely short-term or very long-term or anything in between.
There are three main stages in the retrospective as follows:
- Individual Reflection. For 10 to 15 minutes, each individual works silently to write down the things that they have learned in the appropriate category on the handout. Everyone should try to get at least a couple things into each of the four categories, but more is welcome.
- Sharing with the Group. Systematically going around the group and getting people to read from what they have written. This is another 10 to 15 minutes. This stage should not get bogged down in discussion, but brief clarifying questions should be welcome.
- Identifying Important Learning. The group now has open discussion to decide on a small number of things it considers the most important that it has learned. This could be based on popularity, but impact, depth, or uniqueness might also be factors in considering importance. These are the items that get written down on the flip-chart. This is usually the longest part of the retrospective and can take up to 30 minutes.
This is an excellent retrospective for a team that is going through a significant transition such as starting a new project, a major change in business direction for a product, or as a wrap up technique for sharing lessons learned with other parts of an organization. It is not a good technique for a brand new team that hasn’t worked together before as there will be little common ground for deciding on the importance of peoples’ various shared learning.