Putting the 4 kanban principles to work
HTML-код
- Опубликовано: 10 мар 2020
- In Parts 1 and 2, we saw kanbans of all shapes and sizes: cups, Post-Its, - even people! Today, it's time to bring everything together - to turbo-charge our kanban board.
= = = = = = = = = = = =
New for 2024: my best-ever training:
"How Your Agile Teams Can Achieve Predictability and Productivity WITHOUT Burnout"
→ www.developmentthatpays.com/w...
= = = = = = = = = = = =
-------------------
143. Putting the 4 kanban principles to work
#kanban #agile #DevelopmentThatPays
Previously… I got a coffee cup pushed in my face Today… we’ll uncover 4 kanban principles, and look at how that they can help YOU in your Agile development team. Whether you’re doing KANBAN or - and this might surprise you - SCRUM. In the coffee shop ---- Things started so well. So simply. A lone barista, bestriding his humble coffee shop like a colossus(!) Doing everything his defined process: Order Make deliver Adding a dedicated order-taker didn’t seem like a big deal, but with specialisation came the need for orchestration. Key to that was the buffer: In the coffee shop, this area of counter On the board, this column. The grey colour a reminder that no value is added here. Waiting. A waste of sorts.But it’s a price that we willingly pay to switch the system from push to pull. A board fit for a development team ------ Let’s step out of the coffee shop for now, and make our board a little more development-oriented. How about a defined process of: Development Test Release Now, if I was working alone, the board would work as is. But working as part of a team. A team with specialisation: developers, tests - even dedicated deployment personnel - we’re going to need to handle those hand-offs. That means buffer columns. And again it’s with a heavy heart… that I colour them grey - to remind us that no value is added here. To work ------ Let’s give this team some work to do: Into Development. Typically the longest time. Into Dev Done and immediately into... Test”. hopefully that won’t take too long. Into Test Done”. And into “Deploy”. In this team when Deployment is done, the task is DONE. (Which is why I haven’t splt the Depoly column.) Some thought went into this, you know! How long did it take to get from end to end Around 30 seconds. Scale up ----- There are 6 people on this team, so we can do better. Oh. And let’s add in some Development Environment-appropriate music! Looks like this are popping out every 5 seconds or so. That’s 12 per minute. That’s a useful metric. But there’s another that’s arguably much more important: the time it takes a single item of work to get from end to end. Best case - as we just saw - is 30 seconds. But what if the board looked like this Imagine how long it would take this pink card to make it all the way across. Seriously. I really need you to imagine it. I am not animating that mess! Limiting Work in Progress ------ We already know that the cure for this: it is to impose Work In Progress (WIP) limits. So let’s do that. And again, keep your eyes on Mr Pink. Took.. sure, a good bit more that 30 seconds to make it across the board - about 20% more. But way less time than this [the crowded] case. This is an important point: work in progress limits don’t just limit work, they limit time: the time it takes for one item to get all the way through the system. Waste ------- Why is that important In the coffee shop, wait too long and the customer may change his mind. Can something similar happen in development Of course it can! Let’s take the WIP limits away for a moment. And go crazy with the Post-It’s. What if something comes to light that means that all of these have to be re-worked Or we learn something that makes ALL of these irrelevant All that development time that went into there items down the drain. A waste. Shared WIP ---- CLearly those WIP limits are a big deal. And before we move on, I’m going to make a small optimisation. As both of these columns belong to the Dev Team, instead of the Devs having limits of 4 and 2, I’m going to impose a shared WIP limit of 5. I can’t use the red lines any more, so I’m going to replace them with a number at the top. Similarly for Test: instead of limits of 3 and 2, a shared WIP of 5. Did you notice that I just reduced the WIP of the system by two By now, you know that that should be a good thing. All other things being equal, it will get work across the board faster. Of course, all things are not equal: reducing WIP is one of those things that’s simple, but far from easy. Focus on Flow ---- Let’s throw a spanner in the works: Development is at capacity. And that capacity is all in the grey. The entire Dev team is stu
• Putting the 4 kanban p... 
Хобби
We're back with the third and final part of the Coffee Shop Trilogy.
Watch out for a "special effect" that I've never used before!
Absolutely love the tuber presentation/edit style, effective and lively!
So nice of you to say so. Thank you!
Succinct language, crystal clear presentation - What more to ask for. All of the videos set a benchmark for understanding Agile concepts!
big thanks for that series of videos. I realize now that I am doing kanban since ages then. 🙂
Excellent news!
Just discovered this channel. Where have I been for so long? It's so wholesome.
Perfect example. Clear, understandable and concise.
Thank you - much apprecaited.
This is so helpful
Happy Birthday. Thank you for your ability to take complex applied theory and allow everyone to embrace knowledge and get it. That's an incredible gift that has made a difference in my life.
I think I learned more from these three videos than I have from all the in-office training my company has provided. Very good series.
That's really nice of you to say so. Glad you found the videos useful.
Amazing work, explanations. Simply excellent, well done. Thank you
Thank you! Very nice of you to say so 👍
Nice compilation 👌👌👌
Thank you!
Very useful Kanban videos! Thank you so much for your contribution and btw I liked your shirt on this video!
Stay safe and have a good one
Just remember this is free. Thank you 🙏
You're most welcome!
I really appreciate your humour! Thanks for the explanations :)
AMAZING! Love it.
Brilliant Gary! Thanks!
You're most welcome!
I simply love Gary
Awwww.
This is so simple and well explain 👏
Brilliant!
Love the video Gary :). One common thing that can be done and which is no secret to anyone and is part of the kanban principles and /or practices is to define explicit quality policies and criteria from one Column to another, kinda like a mini dod per column. i.e: What needs to happen in order for that element to go from column A to B?
Excellent, very useful! Thanks for this, I'm going to pin those principles on my board.
Glad you liked it. Pinning the principles to the board in a great idea!
Putting your head down and "doing your job" can break the system that you're in. Remember to look at the context in which your system is working and adjust accordingly.
Hi Gary. Wanted to say thanks for your many teaching videos that have helped me pass my PMI PMP exam today. I know you are Agile focussed, but it has all brought me a greater insight to project management generally, but particularly Agile, scrum , and kanban. Thanks my friend....it felt like you travelled the road with me! Keep up the good work. 👍
Many congratulations. Great news!
Hi Gary, thank you for the valuable content again. Can you please show how to create better "Pull system"? How to encourage people for "pull"?
Devs should go with scrum master to the playroom for foosball match. You would be surprised how quickly tests are done then... Seriously, great episode! Mr Pink beats even Mr Who. 😂
Ha! You're so right!
excellent series:)
Thank you very much!
Nice explanation. I like it.
Glad you liked it
Great production quality yet again Gary!
Loved the Tardis effect, gave me a good chuckle :)
Ah ha! You spotted it!
We've used a mix of traditional, Agile, Scrum, and Kanban in our PM approach towards software/video game projects. The worse thing that comes up are egos and the term "Feature Creep." When you only have 5 months per project, feature creep is detrimental to your time and quality mgmt.
Feature creep is a killer.
Nice!
Thank you!
Well done. One "other thing they can do" is invest in operational improvement to increase speed and capability. Tool development, for example.
Yes, agree 100%.
As always, great work. Just one wrinkle. what if something fails testing and needs Development work but you're grid-locked by all the previous columns waiting for testing to open a slot? Or is failing in the test phase not an option?
It seems I can use the Kanban concept can be used in business operations
Definitely!
Hello Gary. Thanks for another good class.
Is it possible to add a column between DOING and DONE for those items that needs some external help or answer?. For example for some devellopment that needs to be consulted with some expert... It could have a limit to just 1 item.. Thanks!
Yes, absolutely. (It's quite common to have a User Acceptance Test (UAT) column.)
Genial
Gary, do you know any virtual tool that would implement the rules you gave (WIP limits on stage, stages split in doing/done, …) please? Thank you.
Jira has WIP limits. Trello also has WIP limits (via a power-up). But I'm not sure either support shared WIP limits.
I wonder if anyone else knows?
Thanks for the answer.
Hygger has the sub-statuses (in progress / done) in the stages, but unfortunately the limit only applies to the "in progress" sub-status.
In a dev-ops environment, how would you blend shiny new features and boring maintenance tasks? Our stakeholders just don't want to know about the latter and it's irritating!
It is irritating, not least because the same stakeholders will be the first to shout when something breaks.
This is one thing (among several!) that Scrum gets right: it's down to the Scrum Team - only - to decide what to select from the Product Backlog. The team is considered to be best-placed to pick the right mix of "shiny" and "boring".
@@Developmentthatpays Absolutely, I call it "getting it in the neck both ways!". Must look at trying to borrow this from Scrum. Obviously, we've also got a bit of imbalance between the dog and its tail that we need to address. Thanks for coming back, this is useful!
i have a problem with in solving with the flow but the organizayipn has limited the access of employees to do specific job only
how can we do kanban in this situation
Not sure where you are on this journey, but my first question would be "why" is such a restriction in place? What happened in the past which caused them to start the restriction?
Could you clarify what you mean? Does everyone in the team "do everything"?
Youre fucking hilarious man love this shit.
Thank you!
Great video! :)
Does anyone has a Kanban for Marketing Agencies?
We do some kind of Scrumban, and our board’s columns has each member of the team... which I think is not the best. I think we should use row as departments/members, and then create columns of doing, etc.
Does anyone has other ideas to share?
Thanks!
There are lots of non-software companies applying Agile methods - including Marketing Agencies.
I agree that a work-centric board - rather than a people-centric board - is the way to go. Would love to hear how this works out for you.
Devs should not do testing. They know the inner workings of the system too well and will most likely test the happy path. Consultans and users will use the application in ways a dev would have never thought of.
Devs should be able to write tests until there are only happy paths left.
Depends on the team. In my experience, it's easier for Dev to complete automated testing which allows Testers to complete the manual testing thus putting their efforts towards finding more complex breakage.
I disagree...devs can and should be part of testing upfront or side by side with testers as the team progresses which in turn clarifies feedback, granted it’s time to do that work the skills these Dev often benefits peer review or mentoring or learning hands on the go you know...
Does it mean that if a developer tests something, noone else can test it? Damned!
"Guys, stop everything! Things can be tested only once!"
Hugues Peccatte no you misunderstood me...everyone as developers along side with testers can develop the work and their test scenarios...the goal is test automation so the results are testable being repeatable each time and gives both developers and testers assurance that all is good as their go along about their work knowing the outcome has been tested and their assumptions/goals/business rules are validated....perhaps as an analogy Doctor Who isn’t a specialist the Barista is however the Barista could tell the Doctor how to make standard coffee to his quality of making it (that’s up to him of course) while he is out for whatever reason and return later that Doctor can continue the business a bit longer on regular coffee.