47:32 Branching and Publishing 49:23 Bugs 51:02 Geographically distributed teams. Online boards. 54:10 What about timing for a daily meeting 55:20 Benefits versus timeboxing
@planetjam35292 жыл бұрын
21:31 WIP Limits
@LearningToCodeAndDesign2 жыл бұрын
I loved seeing when he took the audience questions and started using a Kanban board to get to them.
@SOS_126 ай бұрын
I am listening this in 2024!! Thank you from the future!
@thearchibaldtuttle9 жыл бұрын
Despite of all the technical tools that support Kanban, a physical board is my most preferred tool.
@WHEATLEY0075 жыл бұрын
Absolutely. Dump Jira and get a whiteboard
@pandittathe89722 жыл бұрын
@@WHEATLEY007 pppp
@pandittathe89722 жыл бұрын
@@WHEATLEY007 p
@LearningToCodeAndDesign2 жыл бұрын
Yeah. I’m seeing that illustrated so much in this talk. Super enlightening.
@jakobhansen20949 жыл бұрын
Re comment ~53:00 on TFS missing the done column: Visual Studio Online now has the "Split columns into doing and done" when you setup columns "Board\Settings"
@wewantthefunk737 жыл бұрын
This is a land of rainbows and unicorns. I can't wait to live here. All I need are sticky notes, a whiteboard, and a marker.
@glengiancola65226 жыл бұрын
it works, beautifully
@atchg33883 жыл бұрын
This is a great lecture on Kanban. Thank you.
@stephanie95334 жыл бұрын
Great presentation thanks! i am using zentao project management tool. It's a total game changer because it's Scrum tool with open source version more features with cheaper price. It's been the tool I've been dreaming of for foreverrrr!
@pvs1088 жыл бұрын
Kanban is the greatest miracle ever happened. Kanban rocks.
@pedroveas47514 жыл бұрын
Very good presentation, but I think only mature and self-organized team supported by they organization can adopt it. Organization with Waterfall background usually not allow this without a manager involved that generally cause huge noise, there by frameworks like Scrum or methodologies like XP may facilitate and protect a process flow optimization methods and maybe with that umbrella, then Kanban can be applied.
@hugodsa899 жыл бұрын
I honestly wish he went through everything ;(
@adolfoforonda33639 жыл бұрын
I wish he would have used a more realistic example. I'm confused if there are multiple projects in the backlog and one has random items in the breakdown how does one associate the breakdowns with the backlog item? It seems like it would get untenable with stickies.
@barsun1239 жыл бұрын
+Adolfo Foronda First of all you only put one project per Kanban board. When we breakdown a backlog item the new items replace the old "sticky." If you need to have tractability back the original EPIC (see user stories if you need a definition of EPIC) you can include the EPIC name on the "sticky."
@adolfoforonda33639 жыл бұрын
Barry Sunshine thanks so much this clarifies things.
@multiseiberpurz89817 жыл бұрын
Use 1 project kanban and one per project
@krzychaczu6 жыл бұрын
If you need to use a single Kanban board, consider using “swim lanes” (horizontal line across the board) for each project.
@venus54712 жыл бұрын
Good lecture on Kanban overview.
@juhip18 жыл бұрын
Eric --- how do you calculate WIP ? does team size contribute to what your WIP will be ?
@alexisXcore932 жыл бұрын
A bit late, but as far as I know its going to depend on the individuals and the kind of task. Lets remember that we should've have broke it down enought for the stickies to not take too long
@kingsleyoji6494 жыл бұрын
Do different job titles/responsibilities/expertise have different backlog priorities or would this be beneficial??
@shubhrendusinha6 жыл бұрын
For prioritization, it was mentioned that the team decides what to pickup. But thats dev team, they wont have much insight on the business need/impact of items. How will they pick "one" item from backlog if their WIP limit allows only one for now. Assumption is that multiple business communities have posted multiple items with same priority on backlog. In Scrum, you have a PO to decide the top priority.
@WHEATLEY0075 жыл бұрын
I hope that you've had this resolved by now. If not, its highest to lowest (in priority) from top of each columns list, to the bottom of the list. Ie . the items at the top of each column is the most important. Further, the items in the right-most column are (in most cases) more important than those in the next column (going right-most to the lest). Eg- items in 'QA' would be higher in priority than those in 'in progress' .
@Geza_Molnar_8 ай бұрын
@@WHEATLEY007 I guess the question was about how the stickies get their order in that list called backlog. When that's done, the work is done as you wrote. With the note, that the backlog list can be re-prioritised any time.
@Geza_Molnar_8 ай бұрын
@shubhrendusinha There is no saying in the 'definition' of Kanban how you prioritise the work items / tasks / issues / bugs / you_name_it waiting in the backlog. You may have a so called Product Owner (to represent the User / Customer), or you may have the Users/Customers doing it directly. For sure, with the help of someone from the Dev Team, as often, for prioritisation one input is dependency and anothers are the effort and duration of the work (how much business value is brought by how much investment and when). You can find looots of diagrams and calculations how to do that - adapt one or two to your needs, try out, and evaluate. (e.g. www.google.com/search?q=software+development+prioritisation) Prioritisation is the same no matter which approach you choose (a good rule of thumb is to look from the end users perspective 🙂 - have a look on the Kano model). And when you have a PO around, maybe, the PO will do the Business Analyst job, too, talks with the Users / Customers, understands their domain of work and the sector, summarises their needs and wishes in e.g. epics and user stories, discusses the acceptance tests etc. So, why not to have a PO?! one more note: Kanban is _better_ in certain environments than Scrum or Waterfall where prioritisation changes a lot, new high-priority items pop-up frequently. (To handle that, you need much more 'disciplined' colleagues, too!) Where planning is reasonably possible for medium-/long-term (e.g. there are just a few changes on the way), other approaches bring better efficiency due to optimisations. You may engage yourself in drafting out the 'Change Map' of the organisation around the Dev Team : where are the changes coming from, how frequent they are, which other org units are affected, what are the effects, where they originate at, how frequent changes are.
@ModMINI3 ай бұрын
You can still have the product owner in Kanban.
@jwuhome7 жыл бұрын
Time to buy stocks of companies making stickies.
@tarnopol4 жыл бұрын
Best comment ever. "Agile" is like a fucking cult at this point, but what else is new? Can Americans do anything outside the nonstop hype machine, outside of irrationally leghumping The Next Totally New Thing That Will Solve Everything? Answer: no. No one who has project managed along the waterfall method, roughly, has ever been so rigid as is advertised. And god knows few projects have ever actually followed a real waterfall-like model. I'm in instructional design; I've said for decades that the moment I see ADDIE actually followed, then I'll start to critique its real-world performance. Till then, agile just seems a new synonym for "Don't make me think or make decisions early on; I don't wanna scope; I don't wanna contingency-plan; I don't wanna think--makes my head hurt and makes me want to go poopie!" Kick the can down the road. Yeah, agile might work for widget-like content, like code. It won't necessarily work for all projects of all kinds regardless of content. But these people have to invent competencies; whore out their own supposedly radical new way of doing shit; and generally create the guru-buzz. Then, ten years from now, we'll have the anti-agile reaction. And so on. It's like tulip bubbles, basically: the madness of business-crowds. Plus, the ones in the know, know this: agile, waterfall or not--they will push any model that promises to pile more work on fewer people while giving fake-power to the white-collar proletariat. All that matters is increased profit and market share. The rest is the bullshit you tell the troops to get them to revel, if possible, in their exploitation.
@josephgolan54848 жыл бұрын
Great video! I'm currently implementing an open source online kanban board called Kanboard in my organization. I really enjoy how simplistic it is. While it doesn't have done columns for each column! i may request this as a feature or program it myself.
@victorbenoit12288 жыл бұрын
Great. Thanks for sharing the video. Just to show I was paying attention, at time mark 53 tp 54 a WIP limit seemed to be violated, 2 stickies in validate column. I suppose since the board serves the user, and not the other way around, you just note the exception, and keep carrying on.....
@shankarkrupa8 жыл бұрын
The answer is at 15:26 . Related and somewhat identical stories.
@drapsin893 жыл бұрын
14:19 Didn't know Michael Phelps grew a beard and likes Agile project management
@jimmiller9330 Жыл бұрын
Where on the “board” is the architecture and requirements defined?
@Geza_Molnar_8 ай бұрын
@jimmiller9330 In his specific board at "Breakdown" - what may be read as "refinement". Though, his board is more specific for the handling of questions during this talk than suitable for software development. The Kanban board adapts to the work under consideration. There are weird and funny ones on the internet, it's worth for a search 🙂 You may define a board as that suits your team, the environment, the work etc. - they may be even branches in the middle (I saw that). Two general examples for sw dev: - you have a wider-longer lifecycle on the board that at the left (beginning) includes also the work of e.g. the Product Owner and the Solution Architect and the Software Architect, etc. - you may have a board for the PO, one for the Software Architect, and one for the Dev Team - the result of their work 'falls off' their board on the other's board, however not necessarily knot together so tightly, they are not related every time (some tools have automatisations to support this) As a heretical example for both 'sides' of Kanban and of Scrum: - a scrum board for sw dev work running that in sprints - AND a kanban board for bugs (possibly higher priorities) and other errands like research, evaluation of new tools, architecture work, etc. - and then adaptive 🙂prioritisation and share of capacities.
@srivalok295 жыл бұрын
I wish the example had a more real feel to it. Reality is usually much more complex and I dont see that addressed here
@karimsoboh68624 жыл бұрын
Well, I´m a strong SCRUM fun, but u make me like KANBAN after this video ... what is ur book name? wanna look through amazon on it, Thanks.
@ralphwallace22233 жыл бұрын
An excellent overview.
@jackyang74015 жыл бұрын
Very nice video, the test video about Kanban
@gulabeerkhan21502 жыл бұрын
Amazing presentation
@ricardomestre75495 жыл бұрын
Brilliant, many thanks!
@AISNIGLTD5 жыл бұрын
physical board requires physical attendance but when dealing with teams across geography how do you deal with time zone issues
@WHEATLEY0075 жыл бұрын
Have them get their team mates to push tickets across the board. A happy functioning team should be willing to do this
@toober2474 жыл бұрын
Covered at minute 51 onwards
@jesusbasketball87404 жыл бұрын
Priorities can change in scrum in any given/on going sprint directed by the Product Owner. For the team is Managing work from backlog/priority which is similar in Kanban you still have the same work to dev/test/perf/deploy in Kanban. If your trying to reduce overhead of scrum ceremonies that’s fine but show me proven time/cost savings on delivering software? If requirements, test results all other unknowns become impediments what is difference in each process? Both processes can pull new if impediments occur or new priority or defects. It’s Product Owner responsibility to manage and communicate effectively to the team. Time box or not solutions have to be delivered to the market or your consumers efficient and quickly.
@Geza_Molnar_8 ай бұрын
@jesusbasketball8740 I agree with you on most of what you mention. However "Priorities can change in scrum in any given/on going sprint directed by the Product Owner." - in the ongoing sprint???
@TheFlacidFlamingo Жыл бұрын
Someone get this audience a cough drop and a glass of water!
@MrApaHotel2 жыл бұрын
I need kanban to clean my house
@rzozaya19696 жыл бұрын
Why comparing SCRUM to Kanban? I think that SCRUM uses a Kanban board, I don't think it's a versus thing, but Scrum uses Kanban, right?
@krzychaczu6 жыл бұрын
Right. Consider Scrum when continuous / daily delivery of the value is not possible and your process needs to deliver value in scheduled releases.
@DmSujaEntrepren7 жыл бұрын
THIS MAKES SOOOOOOOOO MUCH SENSE!
@mowglibwoy7 жыл бұрын
Well done. Thanks!
@pohjoisenvanhus5 жыл бұрын
Some would probably prefer more the predictability of time-boxing.
@Geza_Molnar_8 ай бұрын
@nyrtzi And at some environments it is possible. Even waterfall is possible at some other places. Where change of priorities and new high-priority items are part of the daily reality then Kanban is the choice, imo. Evaluate how frequent are changes around the Dev Team, where they come from, what are the consequences etc. (create the 'Change Map') and you'll have a gut feeling which work coordination approach suites that specific situation.
@andystewart85649 жыл бұрын
Apologies if I missed this but does the 'Track' column have a sticky limit number or is it endless? Because if it does have a number would that alter the overall amount of stickies on the board at any one time? Great video btw.
@micmcp9 жыл бұрын
There isn't a limit to the number of stickies in Track; however, stickies in Track do not count towards the limit either.
@andystewart85649 жыл бұрын
Thank you for your response,
@elizabethmarsh36977 жыл бұрын
Andy Stewart u
@ModMINI3 ай бұрын
'track' is outside direct control of the kanban team so there is no limit, but if there are a lot of items in 'track', it is a signal that there is something broken in the larger organization and for the team lead to strive to resolve. In software one could put a soft alert threshold
@pollafattah70624 жыл бұрын
OK, strange times!! He kisses the book at the end and I am thinking "IT'S CORONA TIME"
@adishabhatra4 жыл бұрын
So much for selling Kanban - LOL
@shekhar03043 жыл бұрын
Dear Friend, this presentation is from 2015...People used to kiss so many things back then...
@13175112 жыл бұрын
Come on give Doug a break and let this gent talks estimation and schedule..and really no one asking follow up questions there..FANTASTIC
@NedHasovic6 жыл бұрын
Some dude just went on stage to say his MANAGER will talk about Kanban... Did that just happen? Sad...
@thebolivei6 жыл бұрын
Ned Has Hi I m from 🇧🇷 what is a backlog?
@rohan27263 жыл бұрын
@@thebolivei things to do list is called back log
@dangeorgescu64605 жыл бұрын
What happened with your Scrum Master after you made the transition from Scrum to Kanban? He was fired?
@martygraw97083 жыл бұрын
He’s the PM updating TFS
@Geza_Molnar_8 ай бұрын
@@martygraw9708 🤣
@ModMINI3 ай бұрын
they evolve to kanban flow masters.
@SainiAnkur6 жыл бұрын
nice information
@KrystianKaczor8 жыл бұрын
I watched the video. Honestly, Kanban in this context is limited to using the Kanban board. It is not the Kanban method by David J. Anderson. Genrally, it's Eric's way of using Kanban board for project management. It is interesting that David J. Anderson started off building Kanban the method by using Kanban board at Microsoft in parallel with oficial Project Management process. That was prior 2010. From this perspective ideas presented here are kind of a step backward. No doubt it can be useful. Having Track column which doesn't count to WIP makes no sense. I would put the item back to backlog with flag on it. Magical spreadsheets - No, thank you.
@marcellodias94167 жыл бұрын
You´re probably talking about Lean Kanban,this is just using a Kanban Board. Lean mindset is much more compliant with real world, than the Agile mindset in my opinion.
@KrystianKaczor7 жыл бұрын
Marcello Eduardo de Oliveira No, I mean the Kanban method. Have you read the book by David J. Anderson? System Thinking-> Lean-> Agile, that's the relationship. From generics to more detail.
@marcellodias94167 жыл бұрын
No,Not this book,In fact I hated Scrum so much,that I[ m skiping everything that is related to Agile and concentrating myself in Lean,but returning to WIP and Kanban and this specific case,I have no experience with Games and consoles development,I imagine how difficult it would be to have an accurate WIP calculus,I develop ERP, a much more consolidated market(not too much space for inovation,with years of experience of how to solve problems),for this specific scenario I think Erich is more interested in the mechanics,the flow control,their "WIP" is their feeling,but you´re right WIP is in the core of the methodoly,for 99% of us,it does not make any sense to practice Kanban without knowing how much work can be done simultaneously. I imagine how do people that Develop WebComponents,and specifically the Polymer project,how would they calculate WIP ,if they don´t even know what they´re have as problems(they have to make a web Component work on all browsers,that they don´t know the internals),How would Nasa calculate WIP also? For me,what makes Kanban much superior than Scrum,is exactly the granularity,and teh fact that it does not have sprints,wich bu design are totally against innovation and quality,at least inmy own experience,and my research on the Internet.
@KrystianKaczor7 жыл бұрын
I have no idea why you had to mix Scrum in conversation about Kanban. You have a very narrow perception of Kanban. It's more than the board. WIP comes from constant improvement, not form Excel sheet. Gosh, so many mixed up keywords in one reply.
@marcellodias94167 жыл бұрын
I only talked about Scrum,because in The Video Erich talked about Scrum,Just it,and why I don´t want to read anything about "Agile Kanban",because Agiel for me is bad as a MindSet itself, and concentrate myself in "Lean Kanban" About WIP caclulus I have no Idea,where did you get the Idea of Excel and all other silly things,let the people who read both answers to jugde. Have a nice day.
@anandsingh97194 жыл бұрын
16:00
@philip71844 жыл бұрын
I still like Zen Tao software, full life cycle management tools, which including Kanban tools
@anandsingh97194 жыл бұрын
1:00
@vbachris2 ай бұрын
36:52 he breezes over feature flags and stored work that doesn't have value until all tasks complete. that's REALLY hard to do
@sirisaksirisak69814 жыл бұрын
They bring kanban into agile method not all steps, in kanban product line they have control point to protect materials or items in assembly product this method aim to have a material or an item in time in product line protect lack of material and safey stock and sunk cost, kanban means the number code of materials or item part paper put in the bin along the assembly line in product station control points this method aim to avoid lead time in MRP chart to have enough materials we call JIT just in time in product line in order to save time, see in flow chart from start to finish out come.Kanban Pros suit for made by order product have high flexiblity in productivty not fix. Cons lack of creativity and product developed cause focus on finish in time.
@johnjacobs19694 жыл бұрын
Interesting guy :)
@redpilldude8688 Жыл бұрын
The estimating answer was underwhelming. For complex cross functional projects, we need to know the start, late start, end and then critical path to be best able to work cross functionally at an enterprise level. His estimations would be lacking, to say the least. Not to mention updating them somehow on his board. This is fine for coding but not real projects at a high level.
@nvmcomrade5 жыл бұрын
17:06
@jamesjanse37314 жыл бұрын
Physical boards are great, but then COVID happened :p
@CarlHeaton7 жыл бұрын
kAnban not KONbon :(
@NoobWithaaGun6 жыл бұрын
The longest book promotional video I have ever watched....
@lindachaparro29415 жыл бұрын
46:22 jajajajajaja
@zerge696 жыл бұрын
Please don't actually use stickies; there are plenty of great Kanban SaaS solutions out there.
@hugodsa893 жыл бұрын
Sometimes it’s easier to begin with a physical approach especially because the barrier and implementation cost is so much lower then.