Scrum or Kanban or Scrumban for Maintenance and Production Support

Isn’t the Product Owner accountable to stakeholders for product value, regardless of whether the work on the Product Backlog is for new development or support? Why does a VP need the visibility you refer to?

Hi Ian,

Thank you. VP is acting PO in this Team. I will hybrid my role as SM/PO eventually, He is seeking ways to improve the workflow. 

Here is what i have suggested to get us started:

Use of Cycle time instead of Velocity/Burn down.. that will gives us idea how long we are taking to resolve the issue from pulling in to Sprint to its completion / roll out /Bug fix.

this is my first project regards to Ticketing system. 

appreciated,

Nick

Hi Nick, I hope below resources can help you to decide which most appropriate approach for your case

Scrum approach: https://www.scrum.org/forum/scrum-forum/6290/agile-it-operations

Kanban for service operation: https://resources.leankit.com/guides/using-kanban-for-it-operations

Regards,

Gesit Ramadyan

> He is seeking ways to improve the workflow

Shouldn’t it be up to the Development Team to optimize their own workflow? A Product Owner should care about maximizing the value delivered to stakeholders. A key mechanism for doing so is to order the Product Backlog appropriately. How does the PO currently decide which items of work would be of most value to the product?

I suggest you read some of the blogs here on Scrum and Kanban. I didn't write ScrumBan, I intentionally am writing Scrum and because it isn't about taking some of each, it is about using Kanban as a practice with the Scrum Framework.  Anyway, have a read:  https://www.scrum.org/resources?search=kanban

IAN,

Not to offend you but do you even work in a corp setting. You seem more theory than actual practical work experience.

To answer the poster question use KANBAN forget this scrumban nonsense.

Scrumban was originally formulated by Cory Ladas as a means of transitioning from Scrum to Kanban. Unfortunately, the term has been widely misapplied across the industry, and “Scrumban” now more usually refers to hybrids which lack the rigor of either.

Let's get some Stacey Model up in here!!

Nikunj,

Based on the situation you described, your organization is not doing Scrum, but something else. How many products are being "maintained" by this team? It would be wise to go back to basics and commit to a framework (scrum, kanban, etc).  You mentioned the team is not comfortable with what they are doing. In order to gain confidence, the team scope needs to be scaled back and only deliver what they can within their current maturity level. 

As for the reporting requirement, it  will depend on what  is important to the person reviewing the report. 

a) Number of closed tickets vs open tickets

B) % of critical tickets closed vs open tickets

c) etc

Hi all,

For Kanban, how would you recommend setting the WIP when there are both Maintenance items and Production Support items (more critical) coming in at the same time into the product backlog?  Any reference material and page numbers would be helpful.  Thank you.

WIP are at 1st a best guess. Over time you can gather metrics like throughput to set them. Use littles law etc as a way to look back , then forward to do a rough projection. 

For Kanban, how would you recommend setting the WIP when there are both Maintenance items and Production Support items (more critical) coming in at the same time into the product backlog?  Any reference material and page numbers would be helpful.  Thank you.

TL;DR what you should do will depend on your context.

But some things you may want to consider…

It's OK to violate WIP limits in case of a need to expedite an item; but that should trigger the team to initially decide whether it is right to exceed their defined limit, and later to reflect on what happened, and whether there's an improvement they should make to improve their workflow.

In this case, it sounds like there are two competing inputs to the flow, where one has higher priority over the other.

I recommend watching this video on How an expedite request sunk the Titanic, as it demonstrates the impact on a kanban workflow, of optimizing for high priority items.