I run hot and cold about being very finicky about language. On one hand, I think it’s helpful to be specific about words and labels to better enable shared understanding, especially with new ideas/behaviours; on the other hand, sometimes it doesn’t matter what labels people slap on events or artifacts as long as people are clear about what’s supposed to happen and the desired outcomes — quibbling about words can create unnecessary friction.
One of the labels that makes me twitch though is when teams have ‘Sprint Demos’ rather than ‘Sprint Reviews’. I’ve noticed this label goes hand-in-hand with a tendency to use that meeting exclusively to show completed work, which is only one of the agenda items for a review meeting. While demonstrating working product to team members and stakeholders is a critical element of this meeting, there are other feedback loops related to the work to consider if we want to understand actual progress and refine the product backlog based on what we’ve learned and delivered.
Here are the questions I often use to frame an agenda for a Sprint Review meeting:
- What was our sprint goal and what product backlog items did we intend to deliver during this sprint?
- Without this context, it might be hard for people to be clear about whether the work they’re about to see is the work that was expected
- What items were completed?
- The demo – show off that finished work! The Product Owner may demo the delivered work, but this can also be a great opportunity to give team members a chance to shine in public by having them lead demos.
- In getting work done, what problems with the work did we encounter?
- What did we learn about the work along the way that will inform our understanding of upcoming work? Update the backlog accordingly.
- What did we intend to deliver but didn’t complete? What new issues and learnings related to the work emerged?
- The point of this discussion item is not to blame the team for not delivering everything they forecast; rather, this information can be very important in updating the product backlog because the team has learned about new issues, dependencies or customer needs. Keep in mind we’re focusing on issues with the work, not the team – considering how the team worked together through the sprint is the subject of the retrospective.
- Don’t spend a lot of time on this topic, but don’t avoid it.
- Based on demonstrated progress to date, what are the updates to the overall release plan?
- The product owner can use this as an opportunity to align expectations about the overall progress of the work (most of the teams I work with are not releasing to production at the end of every sprint, so having a sense of whether we’re still on track is usually a question of great interest)
- Are there other things we’ve learned during this sprint about how product use or the marketplace have changed that will result in product backlog updates?
One pattern I’ve noticed that has been helpful in having teams have more productive sprint reviews with real feedback is to separate the team review meetings from demos to the larger stakeholder community (which are usually held a little less frequently). It’s great if you can have one meeting that serves both purposes, but when you have stakeholders who aren’t familiar with iterative and incremental delivery, or are perhaps challenging to manage, having the Product Owner host a separate stakeholder meeting to demonstrate completed features can sometimes make things less stressful for everyone.
Why does my team need a working agreement?
A strong team working agreement:
- Is collaboratively created by the team itself so that they are holding themselves accountable for doing the things they’ve identified as important.
- Clearly states what behaviours team members expect of each other: by making expectations transparent, individual team members are also encouraged to become more conscious of their individual actions and what impact they have on others.
- Describes how the team will handle instances where the agreement is brokenso that team members have more confidence about speaking up when this happens: “Hey, we agreed to do X, and that doesn’t seem to be happening right now? How do we want to address this?”
- Focuses on a few specific behaviours the team wants to pay attention to. 4-6 items is usually plenty.
- Gets updated as the team evolves – this is a living document
How can my team build a powerful working agreement?
- Describe the best or worst team member you’ve worked with.
- Give participants the opportunity to describe the kinds of behaviours they’ve found helpful or destructive in the past – this is useful information for shaping the kinds of interactions we want to foster in our working agreement
- What’s the superpower you bring to this team that others might not be aware of?
- Sometimes it’s hard to talk about what we’re good at, especially when it’s a ‘softer’ skill. Astute teams might also notice if they have a diversity of superpowers or if there’s an imbalance of strengths in certain areas
- What kind of help do I want from my team to be high-performing?
- Given how hard it can be to talk about what we’re good at, it’s really difficult for many people to ask for help, especially when the team is new and we’re uncomfortable with vulnerability. By practicing this at the outset, it lays a foundation for asking for help down the road.
- What colour signifies conflict to you? Why?
- This is a really simple exercise that yields very rich conversation about a sensitive topic. You can use paint chips, crayons, squares of construction paper or any tokens that give people a range of colours to choose from. Give them the tokens, ask them to pick a colour, then invite everyone to share their answer to the question (And no, not everyone will choose red)
- What should we do if it seems like one of us is letting the team down?
- Possibly the most important question as it helps the team prepare for when someone breaks the working agreement.
With the answers to these questions in mind, I ask each team member to propose a behaviour to include in the working agreement. I remind them to focus on capabilities the team needs to work on, not behaviours that are already solidly established. And, I encourage them to identify positive behaviours rather calling out undesirable actions (e.g. “do bring team issues up as soon as you sense there’s a problem”, not “don’t have backchannel conversations about problems”). I also remind them to include an item about how to handle it when the agreement is not being honoured.
Real-life examples of working agreement items I’ve seen teams include:
- When you think someone is struggling, offer help right away – don’t wait
- In team discussions create space for everyone on the team to speak
- Show respect for others by being on time for team meetings (this is a perennial favourite!)
- If you have a problem with someone, speak to them directly before bringing it up with someone else
If the team is small, they might include all of the proposed behaviours in the initial agreement; larger teams will likely need to prioritize which items to focus on for now in order to keep the list focused.
Care and Feeding of Your Working Agreement
Keep your working agreement visible to the team – if it’s locked away in an electronic oubliette, it’s much harder to refer to when needed. I encourage teams to post their working agreements as part of their visual management system, so that it’s on hand during team events.
Team working agreements will change as the team evolves and its circumstances change. Review the working agreement periodically to make sure it covers the actions the team needs to work on – this can be a great retrospective discussion.
As a coach and facilitator I spend a lot of time helping my clients establish new teams, and sometimes helping existing teams that are in need of a reboot revitalize themselves. I find that it’s critical to invest a little time at the outset to help everyone get on the same page about the problems to be solved and how this particular group of people will work together in this specific environment. This sets up the team so that everyone can work with purpose, make better decisions about the work, and work more effectively with each other and with the team’s partners. This doesn’t have to take a long time – getting everyone together for a day or two of structured conversation can create enough shared understanding that the team can get to work – and my experience has repeatedly demonstrated that a relatively small investment in talking (spoiler: it’s not all talking, actually) together at the outset repays itself many times over in increasing team effectiveness.
Because I can’t make everyone read Diana Larsen and Ainsley Nies’ excellent book Liftoff: Launching Agile Teams and Projects, I’ve created the following 15 item cheat sheet describing the objectives of a liftoff to help explain what a new team might want to sort out at the outset to get themselves off to a more solid start. Each of these items seems straightforward, but it never ceases to amaze me how many different understandings emerge when you sit down with the team and start to dig into these seemingly obvious questions.
The Deceptively Simple Liftoff Checklist
(Important caveat: the team doesn’t need to have a full and complete understanding of every aspect of each of these items to check it off the list – the heuristic here is Good Enough For Now)
Purpose – “Why are we here?”:
- The team has a shared understanding of its vision.
- All team members understand the key business outcomes desired to realize the team’s vision, and the indicators they will look to in order to determine whether they are succeeding at realizing those outcomes.
- Team members know who their customers and partners/stakeholders are
- The team has an initial backlog of valuable work items that will help the team realize the business outcomes
- Team members have a sense of how the business value of work items is defined and where tradeoffs might be considered in meeting customer expectations.
Alignment – “Who are we and how will we work together?”:
- Team members know who is a core member of the team, and who are external contributors who they need to work with to help them deliver.
- The team has articulated its shared values
- Team members have identified simple guiding principles to help them be successful together
- The team has a working agreement outlining specific behaviours they want to support each other in so that they can work effectively together.
- The team has identified the capabilities it possesses and the capabilities it needs to develop in order to deliver reliably and with quality, and to minimize bottlenecks/single-points-of-failure.
Context – “What’s the bigger picture? How do we understand the system and its influences?”:
- The team knows who its stakeholders/partners are, and what information/decisions/resources they need from each other.
- The team understands what decisions about the work have already been made and other constraints that will determine what/how they deliver
- The team has considered the risks and opportunities inherent in their upcoming work, and is actively considering how to mitigate risks and take advantage of opportunities for greater benefit.
- The team knows what resources are needed to deliver, and is working to get the resources it doesn’t currently have in a timely fashion.
- The team has established the initial practices it will use for coordinating, collaborating and communicating its progress.
I’m hoping to unpack each of these objectives in a subsequent post (it’s the new year and I’m optimistic about posting more than once every 18 months), and share some ideas about how you might help the team to check each of these items off and have some fun along the way.
Are you looking for a simple way to liven up your retrospectives? In my coaching engagements, I often encounter teams that are having ineffective retrospectives because they always take the same approach to framing the discussion. Using the same format for every retrospective preordains a very similar conversation each time, and it won’t take long for team members to start grumbling that the retrospectives aren’t working for them, creating a Doom Loop of disengagement.
I’ve had surprising successes dropping a handful of Rory’s Story Cubes on the table and suggesting “Hey, maybe we can use these to have a team conversation?”. Story Cubes share some of the magical properties of using LEGO Serious Play to spark a serious conversation: they’re fun, they’re tactile, and they’re easy to use. More introverted team members who might be intimidated by being asked to do improv don’t seem to notice when there are Story Cubes involved. By breathing a spirit of playfulness into the conversation, and engaging fingers as well as tongues, the people at the table will share ideas that haven’t surfaced in previous retrospectives. It’s also a great technique for dragging the conversation out of the rut of endless griping that some retrospectives seem to fall into.
Story Cubes are easy to use, and can be adapted to a number of different purposes. The Original set is enough to work with, though including another set such as the Actions (particularly useful for Retros) or some of new Mix-ins can help inspire greater creativity.
Here are some ways that you might incorporate Story Cubese into your next retrospective:
- Check In: One person rolls, then each participant picks one cube and offers an associated word to complete a simple check-in statement, such as “The last sprint was great because…” or “Today, I’m feeling like…”
- Data Gathering: Use the cubes to inspire the story of the retrospective. Dana Pylayava suggests: “Everyone picks 1 image as his view of last sprint. Speaking in turns, team builds the shared story in 9 cubes”. There really are no rules here: have each person choose one cube or a few; people can roll again if they come up dry in continuing the story. Or have each person roll and then use all the cubes to tell a short individual story about their experience of the sprint.
- Gathering insights: To mix things up and really boost ideation, try combining Story Cubes with brain-writing to encourage everyone to generate ideas about why things are the way they are. Roll the cubes, have each participant silently write as many ideas as possible on individual post-its using the images on the cubes as inspiration in identifying patterns, themes, and connections. Roll the cubes again and repeat. Then use silent affinity grouping to assemble the big picture before starting to talk about what’s been revealed.
- Deciding what to do: This is where the Actions or Voyages cubes might be particularly useful to draw out creative ideas about “What is the thing we should do differently next sprint to be more successful?”. Use the cubes to brainstorm as many ideas as possible about what types of actions will get the team to the desired destination (and then make a collective decision about which one to focus on, of course!).
- Closing the retrospective: Similar to the Check In, have participants select an image from a cube to help them complete a closing statement, such as “Our next sprint will be better because….”
While I’ve offered ideas for how to use Story Cubes for any phase of a retrospective, I wouldn’t recommend using them for the entire thing. Choose one or two of the phases and combine using Story Cubes with other techniques for soliciting input – this is a great way to start especially if your team is unaccustomed to using playful props to do serious work.
Some other ideas for how to use Story Cubes in retros:
I would love to hear from you about how you’re using them – leave me a comment!
Where to find them?: Rory’s Story Cubes are available at many toy stores, via Amazon, or directly from Rory’s Story Cubes. And no, I don’t get any promotional perks for being a Story Cubes fangirl. I just really like their product.
Well-formed user stories help Agile teams to make the right decisions about what to deliver next. Ellen Gottesdiener and Mary Gorman’s excellent new book, Discover to Deliver: Agile Product Planning and Analysis, gives Agile teams practical guidance on planning and analysis practices that will help practitioners explore all dimensions of their product so that they are focused on learning the things that will enable them to deliver great products.
There ‘s an opportunity to have the “Discover To Deliver” class offered in either Ottawa or Montreal in October. Visit this page to find out more about the course and indicate your interest in attending. The more interest we have, the more likely it is we can bring Ellen or Mary to Ottawa to offer a fantastic learning experience.
On Tuesday, I had the pleasure of presenting “An Introduction to Lean and Agile Work” to one of the IEEE Ottawa SIGs
As a prelude to the conversation, we played a simple variant of the penny game in order to spark some lively discussion and great questions to frame the rest of the evening. We then talked about Agile values and principles, and how those ideas are manifested in Agile and Lean practices. As the group was quite small, it was less of a formal presentation and more of a conversation with a few pictures to help clarify key ideas about Scrum and Kanban:
The conversation was lively and long (as an Agile coach, I tell myself that one day I’ll get the hang of this time-boxing thing!), and from the comments afterwards it was clear that the talk had sparked a lot of curiosity about how these ideas could be applied in practice. My favourite comment was “You know, we’re supposedly doing Agile at work, but we’re missing a couple of really basic elements. I get it now!”.
Here are the slides from the presentation: