Scrumban - Your Questions, Comments and Concerns
Vložit
- čas přidán 27. 07. 2024
- Last time, we went from Scrum to Scrumban in 6 steps. Today, we'll address your comments. And I'll go out in the rain.
= = = = = = = = = = = =
New for 2024: my best-ever training:
"How Your Agile Teams Can Achieve Predictability and Productivity WITHOUT Burnout"
→ www.developmentthatpays.com/w...
= = = = = = = = = = = =
Grab your FREE Scrum to Scrumban Cheat Sheet: www.developmentthatpays.com/c...
Today, I’m looking through YOUR comments, questions and concerns around the move from Scrum to Scrumban. We touch on a lot of subjects, including:
To give things a tiny bit of structure, we’ll talk about the 6 steps that we looked at last time:
- Visualise the work
- Impose WIP limits
- Add more columns
- Stop early binding; start ordering
- Stop estimating
- Move to triggered planning
For future videos, which of the following would be interesting for you:
- When to use Scrumban
- How to implement Scrumban
- Scrumban metrics
- Scrumban jira
- Scrumban board
- Scrumban tools
- Scrumban ceremonies
- Scrumban vs kanban
Let's me know!
-------------------
127. Scrumban - Your Questions, Comments and Concerns
#DevelopmentThatPays
• Scrumban - Your Questi... - Jak na to + styl
As a died in the wool Scrum Master I have to admit I resisted Scrumban (or as Kanban Dan calls it "Kanbum") but after several months of doing it have to admit my Team is far happier without many of the meetings they now do not have to attend (we stopped Sprint Planning, and Refinement (Backlog Grooming being replaced in 2013)) and now only have 2. The Daily Scrum/Daily Kanbum and a Retrospective every 2 weeks.
Planning is performed ad hock on each story as it is taken on by the Team, which has resulted in stories taking longer to complete (get to Done) as quite often it is the first time some members of the Team have seen the story.
You would think that this would make people unhappy, stories taking longer that is, but because we have kept a track on how many stories we were delivering with Scrum and how many we are now delivering, something strange has become apparent.
We used to do Story refinement a week in advance of the start of the next Sprint. This meant Stories that were ready would sit for a week before going into sprint. If you ad this time into the mix what you find is that now, stories actually get to "Done" around 40% quicker than before.
As you can imagine, people are not unhappy about that.
And, we still have a ways to go to in improving how we work so there is a potential for even greater savings.
So far, with this Team, the move to Kanbum has proved popular all round.
Wait! What? I KNOW just how dyed-in-the-wool Scrum you are, so this is THE most surprising comment... EVER!
Thank you you so much for sharing/ And especially for sharing the results you've been getting - very, very impressive!
this is like im taking a trip with my favourite lecturer while having a recap class. im entertained! and most importantly, i learn a lot!
Lovely comment! Thank you!
I think that scrunban is applied to high skilled teams, eg. software engineers that deals with new technology. In my experience, the planning poker is also important to get all team to the "same page" avoiding missunderstandings, to provoque new members to talk interacting with the team. I really fight to avoid in my teams plannings that the seniours discuss and juniors listen and the planning poker is the tool that I use to get people out of their shells. Another thing that we must consider is the PO side, when in that position all clients that I attended required a forecast for the next month or two. With Scrunban this becomes a harder task.
Fantastic videos (this one and the previous one). Enjoyable and insightful, both to improve the way we do Scrum ... and to go beyond.
Es ist sehr schön diese gut gemachten Videos zu sehen, zu teilen und sich slebst und die beteiligten Kollegen weiter zu entwickeln. DANKE :-)
Thank you!
(And Thank you, Google translate!)
Thank you for these 3 bridges place
Wow, what an interesting take on the scrumban. Thanks for answering these comments and questions. Great stuff!
Thanks Heather!
Visualizing is so key! Thanks for sharing this, cheers!
Many thanks Adriana!
Thank you.. enjoy watching your videos. Very informative, helpful and fun. We were thinking of moving to Kanban from Scrum and now I am thinking Scrumban will be a good stepping stone for now. Cheers
Sounds like a plan! (And look out for a new course on moving from Scrum to Scrumban.)
Much more likely to give Scrumban a try. The last point of fear is the ticket splitting and stakeholder predictability - I'm keen.
Great to hear!
You channel is pure gold. Subscribed!
Welcome aboard!
Just a beautiful setting, and well do video!
Thank you!
I would love a deeper dive into the estimation/non-estimation process of Scrumban. I found out my new team had been doing Scrumban but outside forces moved them back into Scrum. My goal is to get them back to Scrumban since they were more productive and enjoyed it. I'm just new to the process and would love some more info.
I still have to see that video about estimating and forecasting when it comes out. However, I find that this requires a very tight-knit team to work with more or less equivalent skill levels. In my team, (very small about 3 people, one highly skilled developer - myself, a junior developer and a product owner) we just introduced the concept of Scrum, but we are not being dogmatic about it. We don't have estimates per se, but we're organically growing the stakeholders and the team to use the methodology while not impacting their existing jobs leveraging capacity planning.
I'll be setting up the first estimation workshop now that we have some tasks done, but the concept of it will be talking about relative complexity (again talking about work/Scrum vs doing the work). The purpose of it is to help gauge how to rate user stories and use it to flag when things need to be broken down.
The near-term objective is not to do full Scrum or any process, but to get used to the concepts around it. Then pick and choose which one would satisfy what we need.
All this while ensuring the lights in production are still on.
Very fun and relevant. Superb educational content. Thank you!
What a lovely comment. Thank you!
This one is a bit of a departure from the norm... as you'll see!
Remember to grab yourself a copy of the Scrum to Scrumban Cheat Sheet: www.developmentthatpays.com/cheatsheets/scrum-to-scrumban
We have all written scum instead of scrum. I had a recurring meeting in my calendar for a year titled "Daily Scum Meeting".
😂 - ha yes! I do it all the time!
Was already prior, but definitely going to consider this approach. Having done Scrum for almost a year now there are some deficiencies that have arisen and always kind of bothered me. Point est, planning, and planned grooming come to mind. While we have mini-projects from time to time, we're more of a maintenance shop and working in sprints is impossible to adhere to strictly. I'll need to re-watch your prior video on this again and jot some notes written down, so when I have time I can introduce and give it a test run. There's not a ton out there on this so this information has been very helpful. Looking forward to the follow-up videos.
Ryan - You're right that there's not a ton of info out there - nothing like there is for Scrum. Which got me thinking about a way we (viewers of this channel) might share experience. I've started a Scrumban group on LinkedIn. Would be great to have you on board: www.linkedin.com/groups/8705950/
As a Project Manager that has utilized a variety of methodologies, I would definitely use Scrumban. I like Kanban's visualization (transparency) the applying of Lean to Scrum (no estimating) the the use of WIP limits and additional columns to promote a more pure "pull" system. Now, how can I convince my stakeholder and Execs that we can still have predictability (as if we had that with velocity or burn down, lol)? On a side note, I dont like the restaurant analogy for "pull" systems given most kitchens I've work in will work on multiple meals at the same time, of course each at various stages. Their is no WIP, so as a result, a kitchen in a restaurant is a better example of loosely controlled chaos largely due to the fact that there is no WIP and orders are not pulled, but pushed based on the number of customer walking in the door at any given time. Just an observation.
As a creative/ critical thinker that's only just discovered that there is such an occupation as 'innovation', I'm watching/ reading a LOT to get up to speed. At the risk of sycophancy, you're are by far the most understandable, well structured I've found, so. Thank you. Now, I have nothing to do with IT. I have no idea if I'm going to be. So, I wonder if you have considered applying or have applied your principles to other 'work'. I think I have a sense that scrumban in particular can be used in a great many situations. Also, applying scrumban to the work of one person, rather than a team?
Paul - Thank you for you kind words - very much appreciated!
I'm a big believer that the "agile" principles we use in software development can applied to great effect for non-IT applications. (This, of course, shouldn't be a surprise: many of the principled pre-date software development.)
Glad that you mentioned applying agile/scrumban to the work of one person: you reminded me of a book I need to get back to. It's called "Personal Kanban".
You hold on to the value of reviews and I completely agree.
Now when I do not have a more or less clear/clean sprint goal in Scrumban to show to the customer at the agreed date (this meeting usually has to be planned well in advance or better still has to take place at regular times), but possibly I just have an unfinished product with rough edges instead to show of, this might get difficult.
Even working liberally with branches, most stories are relaying on others (especially when cutting stories into smaller pieces).
How to manage this aspect of reviews efficiently.
I guess the question is: do you always hit your Sprint Goals?
We definitely plan on trying this with our Production support team where SprintsScrum don't make sense because of every changing priorities if/when defects come in that are impacting customers in production. We're in a SAFe Agile environment so I need to figure out if we'll be allowed to do this :-)
Scrum can do a lot of things... but (as you said) support stuff isn't one of them.
I'm about to start something that might be of interest to you: get on my email list by grabbing the Scrum-to-Scrumban Cheat Sheet - www.developmentthatpays.com/cheatsheets/scrum-to-scrumban
Hi Gary. I'm following you for more than a year now and I absolutely love your videos. However, I don't remember having seen any episode focused on the explanation of the Agile Manifesto and the 12 principles. It would be great to have a series of episodes focused on them.
Andrea - I've been wondering about covering things like Agile Values - and the Agile Manifesto and the 12 principles. Thanks for giving me a push!
Thank you for confirming what we are doing by accident to be a thing! We attempted to "size" our tasks, be rigid in a timebox of 1 week sprints and we evolved in the team knowing the size of a task, after all they wrote it. They also know when to commit and how many of these tickets in a given sprint. Regarding the length of a sprint.. Well, sometimes its 5 days, sometimes it's 7 days. We declare "victory" when the items we committed to are completed! This approach is working for us. We are getting a 8-12 month project completed in 8 weeks.. How could our approach be wrong? A rhetorical question.
So cool that you stumbled on this by accident! And it sounds like you were clear that you'd improved your process. Is that the case?
@@Developmentthatpays Yes. We've made "the process" fit us. It just seems to me that "Agile" is an oxymoron. How are you being Agile if you are following a Rigid process? We took the idea and made it work for us. But always looking for what can we do better (i.e. We do a sprint Retro). Love your videos, I have showed my team a few of them after a couple of our Stand-ups to give of food for thought to begin our day! Thank you!
LOVE this: "It just seems to me that "Agile" is an oxymoron. How are you being Agile if you are following a Rigid process?"
Diane - The response to the Scrumban episodes has been amazing. As a direct result of you comment - and others in a similar vein - I've started a Scrumban group on LinkedIn. Would be great to have you on board: www.linkedin.com/groups/8705950/
I have started to do scrumban with my team just a couple of days ago. But since we haven't a clearly defined way of work (we did not have done "teamwork" in a literal sense until this week) I think it will need time to break the old habits (Working on multiple projects at once does not help).
For now the our main problems are about using a common board to keep all work in one place, who should write stories/tasks and simply remember to update the board when we start/finish something.
Great to hear you've moved to Scrumban. Would love to hear how things progress over the coming weeks and months.
Fabio - Your comment - and similar comments from others - inspired me a to start a Scrumban group on LinkedIn. I hope will be a kind of support system, where people would be able to share experiences with Scrumban. Would be great to have you on board: www.linkedin.com/groups/8705950/
Hi, thanks for introduce me to Scrumban, however I could not completely understand the "Start Ordering" step, with the Ready column. I'd assume that when you pick up from Product Backlog to To Do columns (be it Scrum or Kanban), you'd already be reviewing and prioritizing those cards, why this additional step? In what sense does this improves over To Do column in a Scrum board?
Side notes:
1) I don't see a trend of pre-assigning team members to tickets on the Sprint Planning or previous refinements, so that Scrumbum would need to fix it. But, always positive to remember it.
2) No estimation, it doesn't shocks me, as you said, major value of refinements are the discussions, awareness and commons understandings. If estimating, it should be like a code to remember the conclusions you reached earlier.
Great comments one and all.
Starting with the side notes:
1. Pre-assignment - I surveyed a couple of groups and was pleased to find that most teams don't do it.
2. Scrumban (and Kanban) essentially exchange estimating for story slicing. Same value in the discussions, without the negative impact of the estimations.
Start Ordering has two intentions:
1. To order the Sprint Backlog. Not all teams do this... but I agree with you that many do.
2. To order the smallest possible portion of the Sprint Backlog. Two weeks can be a long time in an Agile world, so ordering the entire Sprint Backlog can be considered a waste.
@@Developmentthatpays Thanks for you answer. Indeed, some may be using better practices then other, as Scrum does not prescribe any, so always good to highlight some of them. Nice work.
Right now, we are working on several different projects and doing week long sprints to get as many different projects worked on with minimal context switching. Right now there is a different product backlog for each, and I can just work on the upcoming sprint worth or refinement on them. Try to get a coherent vision that informs the next sprint goal. How would manage work like this in Scrumban?
Would love to move from Scrum to Scrumban, would really focus the minds of the team on getting things through the board, and would hopefully lead to less silos of knowledge (when you take tickets not in your comfort zone). One question, In the videos, there wasn't any mention of cycle-time. Surely this is a key metric for measuring your speed of delivery in Scrumban? (something Daniel Vacanti talks about in Actionable Agile Metrics for Predictability..)
Giles, I believe his point is to move measured cycle time from a more granular measurement (e.g. 2 week sprint) to quarterly or bi-annually.
I probably should have asked this earlier, but what's the point in splitting up stories into smaller stories if there are no story points/estimation?
I guess you could ask that question the other way around: if the stories are split... and therefore all stories are small... then they'd all get the same Story Points... so the points become irrelevant. Does that make sense?
This is awesome! But, what I would clearly want to see is doing Scrumban with your developers from another country :(
Distributed teams do present particular challenges. Not sure Scrumban presents any particular difficulties.
We went to Scrumban-ish due to the high amount of Ops interrupt work the team must deal with. Having limited WIP, do you recommend just another swimlane for that as you did with Blocked, or a Column so you can physically see the project WIP not moving and ideally get some percentage of interrupt to project?
I know that some teams have a "silver bullet" swim-lane for urgent items. However, I consider it to be an anti-pattern. The team is aiming for "flow": getting (a strictly limited amount) of work across the board in the shortest possible time. When new - urgent - work comes in, there are two options:
- Interrupt the flow (as would be the case for a "silver bullet" swim late)
- Slot the item in at the top of the "ready" column, so that it is the next item to be built.
I prefer the latter option. If the team is working well, the delay to the urgent item will be minimal.
Does that make sense?
Make a book!!!! Sell it!!!
Does Kanban to Scrumban make sense?
Tricky one... as it could be argued that they are one and the same.
There's no link to the topic of estimations :(
way too formal Gary - lose the jacket! :-)
Hee hee. I rode my bike post that spot yesterday... into a headwind and horizontal rain. Needless to say, I wasn't wearing a jacket!
Did you really have to print it out the comments on a paper? Couldn't you just use a tablet/phone etc? what a waste
What can I say: it was a less enlightened time. ☺️
I am really disturbed by this scrumban stuff. I mean I really recognize the kanban influence on this way of working but I only a superficial lyaer of scrum over it. Kanban i about smoothing the flow of work whereas scrum is about engaging the team in beeing a part of the brain power about building the right thing. If I summarize (a lot), Scrum is all about the Sprint Goal, there was mention of nothing regarding this, if we just keep the retro/review...I men we re still far from real Scrum
Every once in a while I get comment that inspires an entire episode. YOUR comment may inspire an entire SERIES.
Just to be clear: I wouldn't be a rebuttal. Just an interesting discussion centred around this key phrase: "Kanban i about smoothing the flow of work whereas scrum is about engaging the team in beeing a part of the brain power about building the right thing"
@@Developmentthatpays oups sorry i did not mean to produce such a storm. But really basically it means that even if kanban does not prevent the engagement of the team. And scrum doesnt prevent wip limitation.
@@lutaseb - It's a storm in a good way! 👍
@@Developmentthatpays ha cool. Sorry ...well you know... the french & foreign languages...etc ;)