Scrum

Collaborative Daily Scrum – Alternate to 3 Questions Based Daily Scrum

Scrum is inspired by Rugby Scrum. The entire development team works collaboratively towards one Sprint Goal.

Pretty obvious but still spelling out – Rugby Scrum can never be played individually in a team.

Working solo or without collaboration (read pair programming, swarming or mob-programming) is not even a choice in Scrum/XP.

With this background in mind, let’s focus on Daily Scrum.

Daily Scrum

Daily Scrum is a sprint planning in small. You replan the sprint every day. – James Coplien

A lot of Scrum teams use 3 questions based daily scrum. On the surface, it looks good but it comes with some inherent problems:

What Stops Scrum Teams from Self Organizing?

by ShriKant Vashishtha 1 Comment

One of the key indicators to know whether Scrum is working in a team comes from the fact if the team is self-organizing or not.
Before getting into the reasons on what stops teams to self-organize, let’s see the life without self-organization.

If You Need Kanban in Scrum, You’re Probably Doing it All Wrong!!!

by ShriKant Vashishtha 7 Comments

The original idea of Scrum came from a 1986 HBR article “The New New Product Development Game“, written by Hirotaka Takeuchi and Ikujiro Nonaka. The teams at Honda and elsewhere reminded Takeuchi and Nonaka of the game of rugby and they called this style of project management “Scrum,” a short form of the term “scrummage” where the game is restarted when the ball has gone out of play.

So what’s so significant about rugby scrum?

In rugby scrum, the ball gets passed within the team as it moves as a unit up the field.

Scrum is all about everyone doing everything all the time. It’s an important point to remember as otherwise, Scrum becomes yet another framework with 5 events, 3 roles, and 3 artifacts.

The foundation of Scrum encourages one-piece continuous flow.

So in a Collaborative Daily Scrum, instead of answering 3 daily Scrum questions, a team looks at the Scrum board and plans on how to swarm or mob to finish the top PBI (Product Backlog Item) on the board.

It may happen, depending upon the tasks identified for a PBI, 3-4 people decide to swarm and finish it. And then the rest of the team picks the next PBI.

Daily Scrum is a sprint planning in small. You replan the sprint every day.

If a team is working like this, there should be couple of stories (depending upon size) in progress at any point in time.

So you see, if a team decides to swarm or mob, one doesn’t require to set explicit WIP limits anymore. The disciplinary act of stopping at numerical WIP limits is not required as that becomes part of the system.

The team focuses on finishing existing PBIs before picking anything new.

As we discuss the key idea of collaboration (swarming or mobbing) here, it’s important to understand that the idea of “swim-lane Scrum” (each team member individually taking ownership of a PBI through the stages of the process) doesn’t really work. It blocks the delivery pipeline as any PBI a tester may work on comes after a few days, a week or so.

At that point in time, a tester may get multiple stories to test at once and may become the bottleneck. That kind of scenario is not the ideal state of flow but is more like a Scrumfall in which work arrives in a batch after a period of time.

Kanban Mythbusters Series

There are other posts on Kanban Mythbusters series which you may find interesting

References

Streamline Your UAT and DevOps – Kanban Boards

by Avienaash Shiralige 4 Comments

In my earlier post, we discussed using planning boards to improve your backlog planning and eventually to improve your planning flow. Main project workflow remained same.

Note: People landing on this post directly, please read earlier post to get context of the problem.

This team was using 2 week sprint model for execution. Often stories got completed(tested), but left on the scrum board UAT pending. All real users were on-field consultants, hence not easily available for UAT. This reduced team throughput(velocity). Team decided to change their approach and modify their definition-of-done. They decided to have a done column before UAT. Post demos relevant stories were moved to done. In-fact they did multiple demos to product owner all through out the sprint as stories got completed. They configured their execution scrum board as shown below.

Use Planning Board for Product Backlog Grooming

by Avienaash Shiralige 4 Comments

In our earlier post – Improve sprint throughput we had discussed about how important it is to have stories ready for play before team picks it as part of the sprint. In short, if half-cooked stories are pushed to sprints for execution, then team will spend lot of time analysing, re-working and this eventually reduces team throughput. To address this challenge, few of my teams thought of creating a separate planning board in Jira to track planning readiness. This board was used by PO primarily to keep a tab on the backlog and also by team members during backlog grooming session.

Team was using Atlasssian Jira, I will show here how we modified the workflow and boards within Jira. Some of the issues teams had faced with the backlog not being ready were:

Insufficient scenario analysis in user stories
Lack of functional and technical impact analysis
Not much details/mocks within the story
Team doing sizing estimate during sprint planning – this was the first time team was seeing those stories and hence made sprint planning long and inefficient

Hence a workflow was designed to address above issues. Take a look at the workflow below(pasting it from Jira).