DeepakBhalla

Embracing The Sprint Internal Demo

By Deepak Bhalla Sat 01 September 2018 12 min read

Challenges & Questions

Note: This is an introduction to the problem, if you are not interested in it you can skip directly to the implementation

As a Scrum Master at a company that follows the Agile/Scrum methodology I've faced challenges trying to facilitate communication between team members. In our daily standups the questions we typically asked of each team member are "What did you do yesterday", "What are you doing today" and "What is blocking you from completing what you are doing". The question "What did you do yesterday" is a tricky one since it results in an answer which encapsulates the companies & individuals standards of done. By that I mean the task might follow the companies standard of done e.g. 'deployed to a customer facing application' and the individuals, which is likely not codified.

But a scrum team works together, and they are all responsible for the deliverables of the project. Although asking an individual what they worked on is an important indication of progress it is ultimately the team that together will agree that it a user story is really done to their standards and whether its truly ready to be released to clients/the wider world.

So we also have to ask the team as a whole "What do we all agree is done?" and as an effect "What are our public facing deliverables?". I think if you don't ask this question you might end up experiencing some tricky consequences.

Answering the question is far too complex for a 15 minute timeboxed standup meeting and needs a lot more input that one person can offer. So how do we answer it and what goes wrong if we dont?

An Inefficiency Example

Let me give an example of the inefficiencies of only having a daily standup to measure "done" and never attempting to answer the question "What do we agree is done".

In this example we fictionalise a cross-functional scrum team responsible for improving a companies aching meetings system. The team consists of Joe (A DB Engineer), James (A Front End Engineer), Amy (A Backend Engineer), Aurelia (A UX Designer), and Martin (The Scrum Master/Backend Engineer). They walk into their daily stand-up on the third day of a two week sprint and Joe grabs the conch and starts the standup.

Joe: "Yesterday I worked on our DTO projection system on our DB wrappers. You can now make super lightweight queries and only request the information you want. It'll fix the issues the slow loading issues the dev team was complaining about. Today I'll be working with Amy and Martin to make sure those new lightweight calls are made on the backend. We'll hopefully save the company a bit of money when we remove all those unnecessary join calls. I have nothing blocking me."

Great, Martin's work as Scrum master seems to be done, the three questions are ticked off and everyone knows what Joe has done. Lets move on with the conversation.

Amy: "Yesterday, Martin and I worked on a new API endpoint to replace one of our old and slow settings page API calls. We sent over the specifications to James (The Front End Engineer) who is going to call it on his side. Today Martin and I will be working with Joe on making those API calls and many other calls even more efficient. What a time to be alive etc. We have nothing blocking us."

Martin: "I'm with Amy, except with less enthusiasm."

Aurelia: "Yesterday I finished 95% of the new settings page, James has taken a look and given me his thoughts. Today I'll be finishing that and I'll send them over to James as soon as I am done! I've been asked to design something for a new project one of the new interns will be working on so I might be delayed with my next task".

Martin: "Lets talk about that with whoever assigned you the work Aurelia. Ideally we'll leave it till after this sprint."

James: "I worked on the completed bits of Aurelia's mock implementation yesterday. Thanks for the API calls guys I'll try and implement that today as part of my next user story 'A user wants to click a button and call the outdated SOAP APIs'. I have nothing blocking me"

It seemed like everyone answered the three questions. Martin the scrum master did a good job of dealing with Aurelia's out of project block and the team is ready to put their heads down and do some work. Each standup follows this ritual until the sprint is over.

The team completes their two week sprint and all their user stories are moved to done, before their retrospective they have a sprint review. In the review they present to some key stakeholders, including the CEO who has a personal interest in the project. The CTO and Product Owner agreed that this service which is feature flagged in production should be slowly ramped up to all of the company. Everyone seems happy and the team walk outside gleaming with pride at their successful sprint.

Joe: "That UI looks great James. I didn't see it until now, really great work."

James: "Thanks, those API calls became so quick the user barely had any time to even see the loading state! I would have showed you but I knew you were busy with the new projection system."

Martin: "Definitely, I think we all did a great job this sprint. I did noticed a few UI inconsistencies that luckily no-one caught when you demonstrated James. It seems like the CSS was a little bit off in the settings page and as a result it looks a bit different from the rest of the platform."

Aurelia: "James and I will take a look at that thanks for the spot."

Amy: "Should we be asking for the users ID number on the settings page anyway? Can't we just get that information from the database? I think you can just call our API with the user token and we'll auto-populate the ID from their details. That parameter was just there so devs can test to multiple accounts."

Martin: "Probably not, you're right. Maybe we should get rid of the parameter all together? Maybe we don't even half those parameters, they're just in the database as a nice to have. We're just doubling up the information the user needs to enter. It seems inefficient"

James: "Oh that's fine, we can improve the form, no worries. Let's remove the fields if we don't need them."

The team fell subject to a few problems:

  • Fault lines where communication stopped between sub-groups within the team. As such a lot of the work that was done was agreed between Aurielia and James was not communicated to the wider team.
  • The team has gone all the way to the sprint review without Joe, who is a critical member of the team (and responsible for it's success) seeing the deliverables. His input, although it can be valuable was never asked or included in the process. Joe was "Told it was done" but has no concept of what that actually means.
  • The final UI didn't meet the whole teams standards of done and after the meeting some work will have to be done to fix those bugs. The small UI quirks could have been spotted earlier if the team could gather internal feedback on what they considered "done". James owned most of the deliverables that sprint and understandably communication faltered.
  • Some work James did wasn't needed and didn't fit the Sprint goals, this meant wasted time that could have been spent elsewhere.
  • The standup was used to keep the team informed of what was completed, but they as a team didn't agree it was done.

Now obviously this example is a little bit hyperbolic but its based on previous experiences. If you dont think your team has this issue try this: At the end of your next standup take 10 minutes our of your teams time and ask your team "What pieces of work do we all agree is done". Take note of who is unaware of what has been produced or hasn't seen its final implementation, also take note of who is in disagreement that a user story is actually complete.

There is always non structured communication going on between team members that can help prevent these types of issues. Some teams work extremely effectively and won't need to change, but when you have team members operating autonomously (owning and working on whole pieces of work to completion) you risk falling victim to these types of inefficiencies without knowing it. When those errors get spotted is the first time the whole team asks "What work do we all agree is done?".

Formalising the "What work do we agree is done" problem

Even in small teams that don't break the two-pizza advice agreeing on what the whole team considers "done" is hard. How would we make sure we don't get to the sprint review without the whole team signing off on the deliverables? How do we make sure the team individual receives regular feedback from the team as a whole on what they consider done? This is a difficult problem to articulate and probably one that can be best expressed through a few questions:

  • How do I, a team member, make sure everyone in the sprint knows what I've worked on and consider done and not just the members of the team I've worked with? (i.e. Frontenders showing their work to backenders)
  • How do I, a team member, make sure I'm producing work that fits the objectives of the sprint?
  • How do I, a team member, make sure that my deliverables are meeting the expectations of the rest of the team?
  • How do I, a scrum master, make sure members who are in charge of producing and delivering features on their own get feedback on their deliverables from the rest of the team before the sprint review?
  • How do I, a team member, demonstrate a new feature I'm proud of to everyone in the team without dragging them all out of their work?

The Implementation

To solve the observed "What does the team consider done" problem I propose the "The Sprint Internal Demo" as a new agile regular check-in meeting where every member of the team demonstrates what they've been working on (no matter how small) and receives feedback from the rest of the team. It a short time-boxed meeting that should happen multiple times per week and be comprised of sprint team members only (in order to maintain a judge free environment), it can be open by invitation to other interested parties in special cases. It follows a core set of rules that helps it function effectively:

  • It is a demonstration and not a talk, i.e. A developer won't talk about what they've done (that is best done in the standups) the developer will demonstrate it on a screen.
  • Each team member should present something no matter how small. If you are pair-programming, pair-present.
  • A demonstration doesn't necessarily have to be a customer facing implementation or the demonstration of a completed user story. If you've been working on an endpoint it can just be a cURL request, or it could just be hitting 'run' on a proof-of-concept implementation outside of a production system. It can also be a bug fix and doesn't have to be a new feature. If it helps you in the sprint it is welcome to be presented.
  • Its casual, informal, and conversational. No slides. "You are presenting the product of your work, don't do work to present."
  • A demonstration is short, just as long as it needs to be and no more. Hopefully most presentations shouldn't come as a surprise to anyone so brevity is key to maintain interest. As such, everyone should be prepared to do a small demonstration and all demos should be ready to go when the meeting starts (not stuck compiling).
  • Each presentation is followed by a Q&A where all the members of the team are encouraged to ask questions and provide constructive feedback.
  • It is a supplement to the standup and not a replacement
  • It doesn't replace a sprint review (where stakeholders are present) it prepares for one

I recommend it happens at least twice a week, ideally on a Wednesday and Friday near the end of the day to allow for at-least two days worth of deliverables to be presented. That gives each team member time enough to get something up and running. I've found it works well when time-boxed to 8 minutes (max) per team member (not including a recommended but not enforced 2 minutes for a Q&A).

Try to not time-box the Q&A section, although the whole meeting should be short the Q&A is where the real work happens and you'll be amazed and just how much communication can go on in this time. Keep it fluid and give time for discussions to happen.

Working out the kinks

This is my way of solving the problem, I am not going to say its running in every team at my company. Its what I found has worked best for my team, as such the idea is still in its infancy and subject to change. I wanted to start gathering feedback around this process and share it with the world to see if it helps any other teams who face similar issues.

I truly believe this can make even great teams function more effectively. If you have any feedback I wholeheartedly welcome I can be reached at contact @ thisdomain.com.

Deepak Bhalla