0

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.

Improve this question
3
  • 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
    Commented Feb 23, 2020 at 12:42
  • 3
    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
    Commented Feb 24, 2020 at 1:15
  • Seems very subjective; "Does this sound right?" "I like..." it will be difficult to identify an authoritative answer to the question - too much of the criteria is built on personal, idiosyncratic, unspoken criteria.
    – MCW
    Commented Jun 9, 2020 at 10:39

2 Answers 2

Reset to default
3

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
1

Just-in-time (what IT people mistakenly call Kanban) doesn't impose any restrictions on when and how you run your meetings. You can do daily meetings or weekly meetings - if you and your team is agile you should build the process that suits you.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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