1

To highlight a bit about the team, we work by providing a service to business teams and we constantly have to manage workload. Some of our work is big changes that take a couple of weeks, some of it is work that is more urgent and probably takes 30 mins. We aren’t tied to “releases” but we are tied to quarterly deadlines.

Question 1 I like Scrumban because of how it was continuous delivery but bought in a few aspects of scrum. However people seem to say Scrumban isn’t a proper approach. After more research however I’m feeling like perhaps straight Scrum or KanBan might be more suitable. Does this sound right, and how can I find the most suitable one?

Question 2 Let’s say for example I consider full blown Kanban, the only element I think that was really useful was the weekly structure of Sprint meetings in Scrum, for example for one week sprints a sprint planning meeting and sprint review.

Is it possible, and even efficient, to have an element of this in Kanban? For example, have a kind of special Monday stand up call which adds a bit to discuss the current stack of work and it’s progress and perhaps even ambitions for the week and a Friday special stand up to see where we are as the week ends.

  • 1
    It is a challenge to answer your question as it is focused on frameworks and approaches. Would you be able to add more detail on the problem(s) that you are trying to solve? – Barnaby Golden Feb 23 at 12:42
  • 2
    What I'm seeing in your question is a misunderstanding of what Kanban is. Kanban is a approach applied to any process in order to improve it. You can apply it to Scrum, or any other process. Therefor, there is no such thing as full blown Kanban and you can absolutely have a weekly meeting in Kanban. As for Scrumban, I usually shy away form this term as it is very confusing. You can say that you are applying Kanban in the Scrum framework, but despise there being a book with the title, most of what I see when people say they practice Scrumban is just a mess. – Daniel Feb 24 at 1:15
2

By and large, if the work is product development go with Scrum and if it is tech support go with Kanban

  • The type of workload that you describe could come from product development + production bug fixes. If that is the case, go with Scrum. Designate a person as the Product Owner (PO) and empower the PO to make the final call on all prioritization. Otherwise the 30 min. urgent tickets will keep coming in and force your developers to context switch from the longer duration work.

  • If it is tech support or similar where work comes in through customers opening tickets (including internal customers, such as your business teams), go with Kanban. Presumably your customers will assign severity - critical, high, medium or low. You might want to do an initial triage to validate the severity and/or ask for additional info from customers (such as logs).

|improve this answer|||||

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.