Loading

Scrumban

scrumban

Scrumban is an Agile management methodology blending hybrids of Scrum and Kanban and was originally designed as a way to transition from Scrum to Kanban. Today, Scrumban is a management framework that emerges when teams employ practices from Scrum with the Kanban Method. The Kanban Method act as a lens through which to view, understand and continuously improve how the team works together. Scrumban uses mixed techniques of both methodologies. It combines basic features of Scrum with the flexibility of Kanban. Scrumban uses planning on demand principle to fill the backlog and tasks are assigned only by the pull system like in Kanban. Also, just like in Kanban, the board stays persistent, while only the tasks and their priorities change. This method is mostly used for fast-paced process where the environment is dynamic.

The A2F perspective on Scrumban is the following:

  1. On Demand Planning triggered by WIP Limits.
  2. Work Items/Tickets will have SLAs to when it will get done versus doing estimates.
  3. You don’t have to break down the Work Item/Ticket into Sub Tasks.
  4. A cadence for standups (e.g. three days a week, every day, or twice a week).
  5. On demand or a cadence for Demos (e.g. once in two weeks, once a month).
  6. A cadence for Retrospectives (e.g. once in two weeks, once a month).
  7. Team size can be bigger or smaller than a typical Scrum Team.
  8. Your Iterations will be based on Goals rather than a finite set of “stories” like you have in Scrum.
  9. Scrumban Teams still need to coordinate with other Lean|Agile Teams, participate in Program level meetings, and prepare and participate in Big Room Planning.

Below are the best practices for each of the Scrumban ceremonies:

On Demand Planning

Attendees: Backlog Owner, Facilitator, Implementation Team.

When the number of work items in the “Ready” State decrease to certain thresh hold (e.g. 2 Work Items), then On-Demand Planning meeting would take place to replenish the “Ready” State.

Iteration Planning Input:

  1. Top prioritized Work Items from Backlog Owner are groomed and meets the Definition of Ready.
  2. All Team members are present (in person or over WebEx), unless otherwise communicated to the Facilitator.
  3. Team members should know their own individual capacity for the team prior to Sprint Planning.
  4. The Facilitator displays the Team Backlog on the WebEx/Projector.

The On-Demand Planning ceremony should follow the following guidelines:

  • Backlog Owner should be present for the On-Demand Planning ceremony with prioritized backlog of Work Items. This requires that all Work Items are groomed with Title, Narrative, Description, Acceptance Criteria, and other supporting information as needed.
  • Backlog Owner will discuss and re-iterate the Iteration goals they would like to accomplish during the Iteration and present the prioritized Work Items to the team, one at a time, from the top of the backlog. If the Work Item is technical, a spike, or defect, it should be read by someone from the Team.
  • Team may ask questions to get clarification. Details of the Work Item may be updated at this time. Further details of Work Item and Sub-Tasks can be discussed in real time when its being worked on.
  • Every Work Item will have a SLA to when it can get completed. The SLA should be provided by the person that will be working on the item.
  • if there is no support work raised in the current sprint then the team can take equivalent Story points from the backlog.
  • For remote team members, it is important the Facilitator has access to a screen sharing service, such as, WebEx to share their screen with the team. If possible, tele-presence is highly recommended. For example, if team members are in Europe and the U.S. – having a tele-presence between Europe and the U.S. helps to unite the team and make them feel more like one team. This also is helpful when doing point estimation.

Iteration Planning Input:

  • Work Item(s) Commitment based on WIP Limit.
  • Iteration Goals identified, reconfirmed, and agreed to.

Standup

Attendees: Backlog Owner, Facilitator, Implementation Team.

The team will have cadence to often to meet. The standup should be as short as possible and cover what they accomplished the day before, what they plan to accomplish the current day and inform the team of any obstacles that may hinder their work. The Stand-up ceremony should follow the below guidelines:

Input:

Prior to the Standup, the team should update the Work Items they worked on with the cycle time (how much time spent on the Work Item).

  • Standup should occur as early as possible in the day.
  • The Facilitator will project the Scrumban Board during the Standup and shares on WebEx (for example) for remote team members.
  • People should stand up during the meeting.
  • If there are critical updates by outside team members (i.e. removing blockers), they should attend and go first, so they can leave right afterwards.
  • Based on the prioritized Work Items on the Scrumban Board, team members should volunteer to give their progress on that Work Item (based on what they did the day since last time and what they are going to do today, and if they are blocked).
  • If issues come up during the Stand-up, the issues should be put into the Parking Lot. After the Standup, the people that need to discuss the parking lot issue(s) should stay back to discuss.
  • Blockers should be noted and put through an escalation process to help ensure timely resolution.
  • Team members should close their laptops during the standup, so they can listen to everyone’s progress.
  • If a team member cannot make the Standup, then the team member should provide an update via e-mail the team before the standup.
  • After 2 minutes or when you have critical mass, start the Standup even if people are missing.
  • Before ending the Standup, the Facilitator should review the Cumulative Flow chart with the team to ensure everyone is still confident in finishing their work based on the SLAs. If certain people are not confident in finishing their work, then have a deeper conversation after the Standup.
  • If Backlog Owner has concerns about certain Work Items, he/she should request a separate meeting or meet after with that individuals or individuals to discuss further.

Output:

  • Clear understanding of what the Team is working on.
  • Raised impediments that the Facilitator needs to help get resolved.
  • Understanding how much progress the Team has made and how much is left on the In-Progress items against the SLA.

Note: For remote team members, it is important the Facilitator utilizes a screen sharing service, such as WebEx, to share their screen.
Note: For Logistical purposes, Lean|Agile Teams can stagger their standups to be sequential (back to back) if they are sharing the same Backlog Owner and/or Facilitator.
Note: Have a good size room with video/audio conferencing capabilities for the Standups.

Obstacle Removal Process and Escalation

Impediments that are blocking team members from completing their work should be put through an obstacle removal process. The obstacle removal process would follow the below process:

  • The Facilitator should create and track the blocking issue on a virtual or physical team level Kanban (resolution) board.
  • After 24 hours (business day), if the blocking issue is not resolved, then the blocking issue should escalate to an immediate technical/business leader.
  • After another 24 hours (business day), if the blocking issue is not resolved, then the blocking issue should escalate to the appropriate manager.
  • After another 24 hours (business day), if the blocking issue is not resolved, then the blocking issue should escalate to leadership.

Demo (On Demand or Cadence)

Attendees: Backlog Owner, Facilitator, Implementation Team, Invited Stakeholders.

The Demo ceremony will be held to formally accept Work Items and/or provide an interactive update to Stakeholders. The Backlog Owner accepts the Work Item, the Servant Leader facilitates, and the Implementation Team demos the work completed since the last Demo or only the Work Items requested. This ceremony should be timeboxed between 1 to 2 hours depending on all the stakeholders attending and the scope of the demo. The Demo should follow the below guidelines:

Input:

Sprint Summary Report from JIRA.

  • Facilitator will give a high-level summary of the Iteration’s goals, what the Team committed and delivered. For work items not delivered based on the SLA, an explanation should be provided. The Facilitator should only spend 5 to 7 minutes on this.
  • The Backlog Owner must be present to review the Work Items, and confirm that all acceptance criteria have been met. As each Work Item is presented by the Implementation Team, the Backlog Owner should accept or not accept the Work Item based on the Definition of Done, which including the Acceptance Criteria.
  • The Backlog Owner should only accept Work Items that fully meet the Definition of Done. Work Items that don’t meet the full Acceptance Criteria should not be accepted unless the pending work is cosmetic or considered minor – in which a negotiation between the Implementation Team and Backlog Owner will occur.
  • Stakeholders may also be invited to the Demo to view the completed Work Items.
  • The Implementation Team gives a demo and overview of the Work Items completed since last time.
  • Implementation Team members should demo their work to the Backlog Owner and any present stakeholders. However, stakeholders should refrain from asking questions until the demo is completed.
  • Stakeholders should provide feedback as necessary. Feedback will be filtered and prioritized into the Team Backlog by the Backlog Owner. Backlog Owner is responsible for collecting the feedback. However, the Facilitator can also assist as needed.

Output:

  • Work Items Acceptance.
  • Backlog Owner & Stakeholder Feedback.
  • Updated Release/Version Report(automated in JIRA or another tool).

Note: If the Backlog Owner can accept Work Items in real time, that would be preferred and the Facilitator will schedule the Demo with the PO and Implementation Team member(s) that worked on the given Work Item.
Note: Demos should be showcased on the QA or Staging environment from an integrated build.

Retrospective (on a Cadence)

Attendees: Backlog Owner, Facilitator, Implementation Team.

On a Cadence that the team decided, a Retrospective ceremony should be conducted to review the processes, issues, progress, and opportunities to improve. The ceremony should be timeboxed between 1 to 1.5 hours depending on the scope of issues to be discussed and frequency of the meeting. The Retrospective meeting should follow the below guidelines:

Input:

Retrospective notes from last time and general observations.

  • Facilitator reviews Retro notes from last time and general observations that were made. The readout should not be more than 5 to 7 minutes.
  • Facilitator gathers the team’s input on what worked well, what didn’t work well, and what can be improved for future Iterations and work. Facilitator should be empowered to use gamification techniques to engage the Team (refer to www.innovationgames.com).
  • Implementation Team and Backlog Owner should vote on top issues (dot voting is a popular technique – each person gets 3 dots and they can apply those dots on the issues that are most important to them. For example, 3 dots on one issue, 1 dot on each issue, or 2 dots on one issue and 1 dot on another).
  • Root cause analysis should be performed on the top issues by using techniques like Fishbone analysis.
  • Develop a plan based on the root cause analysis to address the top issues that were selected for improvement. Technical Work Items can also be created and prioritized in the Backlog.
  • Servant Leader facilitates an Agile Maturity Assessment with the Team and Backlog Owner once a quarter or release (described in detail in the Assessment section of the Playbook).
  • Now and then, the Facilitator should use the Retrospective ceremonies to celebrate the Team’s accomplishments.

Output:

  • Facilitator captured what worked well, what didn’t work well, and what needs to be improved.
  • Prioritization of what needs to be improved.
  • Root cause analysis on how to improve on the most critical issues.

Note: For remote team members, it is important the Facilitator utilizes a screen sharing service, such as WebEx, to share his or her screen.
Note: For improvement opportunities that are dependent on people outside of the Lean | Agile Team, the Facilitator should coordinate with the external person/group to ensure the improvement is implemented/completed.

References

Ladas, Corey (January 2009). Scrumban: Essays on Kanban Systems for Lean Software Development. Modus Cooperandi Press.

Reddy, Ajay. "Scrumban [R]Evolution- Get the most out of Agile, Scrum and Lean Kanban". Pearson.