Development That Pays
Development That Pays
  • 130
  • 5 419 045
Agile Velocity: measuring what we don’t want?
Velocity is Agile's most ubiquitous metric. But does it measure the right thing? Let's talk about that.
zhlédnutí: 501

Video

Is Agile about the engine... or the steering wheel?
zhlédnutí 410Před 21 dnem
Is Agile like a train? Or is it more like a car? Let's talk about it.
How to Supercharge your Agile Board (Kanban Board)
zhlédnutí 2,3KPřed 3 měsíci
I'm sharing EVERYTHING I know about Agile Boards... in the hope that YOU will share with me. I look forward to talking to you in the comments. 👍 = = = = = = = = = = = = New for 2024: my best-ever training: "How Your Agile Teams Can Achieve Predictability and Productivity WITHOUT Burnout" → www.developmentthatpays.com/webinars/p-and-p?ref=yt = = = = = = = = = = = = Notes: - There's a mistake at ...
Best Agile decision-making tool is not an estimate
zhlédnutí 1,2KPřed 4 měsíci
The most powerful decision-making tool in your Agile toolbox… is also the most under-used. Which is weird, because outside of Agile, it’s used all the time. = = = = = = = = = = = = New for 2024: my best-ever training: "How Your Agile Teams Can Achieve Predictability and Productivity WITHOUT Burnout" → www.developmentthatpays.com/webinars/p-and-p?ref=yt = = = = = = = = = = = = 159. Best Agile de...
13 ways to BREAK Scrum. (Easier than you think.)
zhlédnutí 1,9KPřed 8 měsíci
None of the "breakers" are picky: you'll find most of them in the Table of Contents of the Scrum Guide. = = = = = = = = = = = = New for 2024: my best-ever training: "How Your Agile Teams Can Achieve Predictability and Productivity WITHOUT Burnout" → www.developmentthatpays.com/webinars/p-and-p?ref=yt = = = = = = = = = = = = Check out the full Scrum Guide here: scrumguides.org/ 158. 13 ways to B...
What you taught me about Scrumban. (And Kanban.)
zhlédnutí 1,8KPřed 8 měsíci
I asked you about Scrumban and your replies caught me by surprise. It is Scrumban that's confused... or is it me? = = = = = = = = = = = = New for 2024: my best-ever training: "How Your Agile Teams Can Achieve Predictability and Productivity WITHOUT Burnout" → www.developmentthatpays.com/webinars/p-and-p?ref=yt = = = = = = = = = = = = Links: - The previous episode on Scrumban: czcams.com/video/c...
Will the real Scrumban please stand up
zhlédnutí 2,3KPřed 11 měsíci
I've been something of an advocate for Scrumban. But I'm the first to admit that it has a problem: it suffers from an identity crisis. = = = = = = = = = = = = New for 2024: my best-ever training: "How Your Agile Teams Can Achieve Predictability and Productivity WITHOUT Burnout" → www.developmentthatpays.com/webinars/p-and-p?ref=yt = = = = = = = = = = = = Let's talk about it. 156. Will the real ...
Work together?
zhlédnutí 855Před rokem
Would it make sense for us to work together? Let's jump on a 30 minute call to explore options. Pick a day/time that works best for you: - calendly.com/brainbox/30min
Why is Agile so... ANNOYING?
zhlédnutí 2,1KPřed rokem
Cast your mind back to your first Agile team. What was the first thing that struck you? The first ANNOYING thing? = = = = = = = = = = = = New for 2024: my best-ever training: "How Your Agile Teams Can Achieve Predictability and Productivity WITHOUT Burnout" → www.developmentthatpays.com/webinars/p-and-p?ref=yt = = = = = = = = = = = = That's the question I'm asking in today's brand-new episode. ...
The Top Agile Channels - #2 Will Shock You!
zhlédnutí 1,4KPřed rokem
We're counting down the top Agile Channels (on CZcams) by subscriber count. = = = = = = = = = = = = New for 2024: my best-ever training: "How Your Agile Teams Can Achieve Predictability and Productivity WITHOUT Burnout" → www.developmentthatpays.com/webinars/p-and-p?ref=yt = = = = = = = = = = = = LINKS 1 - Development That Pays - www.youtube.com/@Developmentthatpays 2 - Agil Es - por Cris Rua -...
Time to stop the madness. Time to stop estimating.
zhlédnutí 6KPřed rokem
The biggest problem in Agile today is the degree to which we rely on estimates. = = = = = = = = = = = = New for 2024: my best-ever training: "How Your Agile Teams Can Achieve Predictability and Productivity WITHOUT Burnout" → www.developmentthatpays.com/webinars/p-and-p?ref=yt = = = = = = = = = = = = 📎 Grab your FREE "Estimates vs. #NoEstimates" Cheat Sheet: pages.developmentthatpays.com/cheats...
You're in the right place
zhlédnutí 654Před rokem
You're in the right place
Agile Forecasting... WITHOUT estimates?
zhlédnutí 9KPřed rokem
Agile Forecasting... WITHOUT estimates?
Agile Estimates. Builders Estimates. Not the same.
zhlédnutí 2,8KPřed rokem
Agile Estimates. Builders Estimates. Not the same.
The BEST part of Estimating. And how to ditch it.
zhlédnutí 11KPřed 2 lety
The BEST part of Estimating. And how to ditch it.
Agile Estimating has an EVIL side effect
zhlédnutí 13KPřed 2 lety
Agile Estimating has an EVIL side effect
Agile and Broken Promises
zhlédnutí 5KPřed 3 lety
Agile and Broken Promises
Scrum Guide 2020 - Product Goal in, Estimates Out
zhlédnutí 9KPřed 3 lety
Scrum Guide 2020 - Product Goal in, Estimates Out
Is your Agile Team the right "shape"?
zhlédnutí 4KPřed 3 lety
Is your Agile Team the right "shape"?
Doing Scrum? Or Kanban? Or Scrumban? It's for you!
zhlédnutí 3,6KPřed 3 lety
Doing Scrum? Or Kanban? Or Scrumban? It's for you!
Cheat Sheets: Scrum vs Kanban vs Scrumban
zhlédnutí 37KPřed 4 lety
Cheat Sheets: Scrum vs Kanban vs Scrumban
Putting the 4 kanban principles to work
zhlédnutí 29KPřed 4 lety
Putting the 4 kanban principles to work
What is Kanban? From Coffee Shop to Kanban Card
zhlédnutí 47KPřed 4 lety
What is Kanban? From Coffee Shop to Kanban Card
What is Kanban? Kanban Explained with a Coffee Cup
zhlédnutí 91KPřed 4 lety
What is Kanban? Kanban Explained with a Coffee Cup
Openness, Courage, Respect, Focus and Commitment
zhlédnutí 10KPřed 4 lety
Openness, Courage, Respect, Focus and Commitment
Scrum Pillars: Transparency Inspection Adaptation
zhlédnutí 11KPřed 4 lety
Scrum Pillars: Transparency Inspection Adaptation
Scrum Sprint + FREE Cheat Sheet
zhlédnutí 12KPřed 4 lety
Scrum Sprint FREE Cheat Sheet
Sprint Retrospective + FREE Cheat Sheet
zhlédnutí 9KPřed 5 lety
Sprint Retrospective FREE Cheat Sheet
Sprint Review + FREE Cheat Sheet
zhlédnutí 16KPřed 5 lety
Sprint Review FREE Cheat Sheet
Sprint Planning + FREE Cheat Sheet
zhlédnutí 12KPřed 5 lety
Sprint Planning FREE Cheat Sheet

Komentáře

  • @tochukwuchigbo6026
    @tochukwuchigbo6026 Před 8 dny

    Nice tutorial. So informative.

  • @PaulHenman
    @PaulHenman Před 15 dny

    "Waterfall is like a train" ... bites tongue trying to avoid mentioning SAFe's Release Trains 😀

  • @PaulHenman
    @PaulHenman Před 15 dny

    "Something of an accent left" 😂

  • @PaulHenman
    @PaulHenman Před 15 dny

    Focusing on velocity -> feature factories -> keep shovelling widgets out the door & don't waste time thinking about feedback ☹

    • @PaulHenman
      @PaulHenman Před 15 dny

      But if you're stuck in that situation and the pressure is to increase velocity, simply change all your 1SP stories to 2SP, your 2SP to 4SP, etc.

    • @Developmentthatpays
      @Developmentthatpays Před 14 dny

      I've had that happen. Lead Dev: "I know this sucks, but from now on: if it's a 5, it's and 8; if it's an 8 it's a 15."

  • @gromajor
    @gromajor Před 21 dnem

    big thanks for that series of videos. I realize now that I am doing kanban since ages then. 🙂

  • @stantoniification
    @stantoniification Před 26 dny

    My experience is of a team that prioritises items by value, but uses velocity to create a sense of predictability around release dates etc.

  • @nissimhadar
    @nissimhadar Před 26 dny

    w

  • @benhill4874
    @benhill4874 Před 27 dny

    Good point! In the US we are often more about driving the amount of work completed - Velocity. But Value, as you say here, is much more important. So how to measure value rather than Velocity, or with it, is the real question.

  • @youngloenoe
    @youngloenoe Před 27 dny

    Gotta measure the outcome to make sure the work has value. Or else it becomes a factory just putting out work so people have jobs.

  • @Swartblits
    @Swartblits Před 29 dny

    Do not agree on the point that story slicing is easy. 2 reasons: 1. You are assuming that it is already known what the slices might be. Idea of estimates are that you can estimate anything, but you can not always slice everything. Often tickets created on green fields projects can be abstract or contain an element of the unknown. It becomes a problem for short term forecasting. I have this important next epic, by when will it be done? 2. The admin it takes for teams to slice stories are arguably just as long as it may take to estimate them. - "So lets slice this story, lets start identifying what needs to happen. How many components will be touched? Is it something we have done before?" - "Well.. not sure.. first we need to see if we find out.. then we need to do this.. but I would have to come back to you on this.. not sure" Get my point? More tickets and discussions with slicing just moves the effort for the team to understand a story before taking it on from something called "estimates" to "slicing". Is the one then better than the other or not? I'm willing to give #NoEstimates a try and simply blindly pull in a number of stories without slicing. Over time with enough data anything becomes defensible, until the stakeholder asks: "This epic, by when?" then.. again its ooh aahh.. At least in that case a reasonable answer from scrum is possible where a much wider range is possible via #NoEstimates. What is we simply say, rough estimates is good enough, no slicing required. Small, Medium, Large. We map story points onto it and call it a day. At least I will not have the Product Owner prioritizing the backlog, ask the question ANYWAY, since he would like to know when a particular coming item will be done to coordinate with other teams..

  • @CreativeThinking52
    @CreativeThinking52 Před měsícem

    Very helpful. Thanks for sharing your knowledge. Have a great weekend. ☕

  • @CreativeThinking52
    @CreativeThinking52 Před měsícem

    Very informative video. Thank you so much for sharing your knowledge. Have a great weekend. 👍

  • @mammadjafarzade7687
    @mammadjafarzade7687 Před měsícem

    dude repeats the video title for 30 seconds straight..

  • @kenechukwuujam1479
    @kenechukwuujam1479 Před měsícem

    Thank you so much for this lesson. I was so captivated by it. So in summary, for Scrum and Kanban, let fools contend, whichever is properly done is the best option (apologies to Alexander Pope).

  • @olegklymov523
    @olegklymov523 Před měsícem

    I am going to try it and tell you the result in 6 month =)

  • @olegklymov523
    @olegklymov523 Před měsícem

    I have the only question about User Stories that are huge and need to be decomposed. How to deal with it?

    • @Developmentthatpays
      @Developmentthatpays Před měsícem

      That's the art and science (!) of Story Slicing. This episode goes in to more detail: czcams.com/video/K6PqofeqoCc/video.html

  • @X12koni
    @X12koni Před měsícem

    The content is awesome and helps a lot, thank you so much.

  • @CreativeThinking52
    @CreativeThinking52 Před měsícem

    Very helpful. Thanks for sharing Have a great day. 👍

  • @justinoneill2837
    @justinoneill2837 Před 2 měsíci

    hey @Development That Pays , great stuff- i'd love for you to talk about the process as a whole (for Kanban). I've been doing scrum(ish) but watched your latest video 𝑯𝒐𝒘 𝒕𝒐 𝑺𝒖𝒑𝒆𝒓𝒄𝒉𝒂𝒓𝒈𝒆 𝒚𝒐𝒖𝒓 𝑨𝒈𝒊𝒍𝒆 𝑩𝒐𝒂𝒓𝒅 (𝑲𝒂𝒏𝒃𝒂𝒏 𝑩𝒐𝒂𝒓𝒅) and you really convinced me to go with Kanban. The concept of a "trigger point" is really useful along with a lot of other things you said.. but back to my request,,, i'm trying to figure out the exact process of how it all comes together for Kanban and how to implement it w/ my weapon of choice Favro (similar to Trello). For example, I'm guessing I would need: 1. Roadmap/Initiatives (timeline view/ sheet view) 2. Release Planning (kanban view) 3. Product Backlog (list view) 4. Work Board (kanban view) 5. Release (kanban - but do i even need this one?) I also have a concept of an "Inbox" collection where things come in from external sources (github/ feature requests from a form/ bugs from a discord channel/ team ideas/ ect). it's kind of like a catch-all would be checked periodically and bring in work to the backlog if it makes sense (originally stole this idea from GTD). but anyways, yeah I guess i'm getting stuck on the exact flow of a card from step 1. to 5. and how everything feeds into everything. it would be cool to see the entire journey, from high level initiative getting broken down to low level completion and handed off [rinse/wash/repeat].

  • @r.walid2323
    @r.walid2323 Před 2 měsíci

    Thanks for the explanation, as well as the attached sheet.

  • @user-sz1tc2xi2d
    @user-sz1tc2xi2d Před 2 měsíci

    excellent presentation in finest way

  • @jozsefcsaszar6164
    @jozsefcsaszar6164 Před 2 měsíci

    Number 5 all the way - maybe even a flag marker (maybe No. 4 - but then u gotta show some context visible even externally so I don't have to open the card to read comments or PRs etc. )

  • @jacobtolman726
    @jacobtolman726 Před 2 měsíci

    Adding a swim lane (row) above/below is a great idea. I wonder if I can get Azure DevOps to automatically change a card visually when it is moved to "Blocked". Hmm...

  • @dfana
    @dfana Před 2 měsíci

    Awesome, can you share how to implement this in Jira? Or other tools? Thanks!

    • @Developmentthatpays
      @Developmentthatpays Před 2 měsíci

      That's a great idea. (I wonder where I could acquire a licence...)

  • @meshiapennix1663
    @meshiapennix1663 Před 2 měsíci

    Great explanation!!! Thank you.

  • @jncompany1603
    @jncompany1603 Před 2 měsíci

    Very detailed information. Looks good thanks for my free copy.

  • @mjmendozaiv
    @mjmendozaiv Před 2 měsíci

    I've seen codes that looked like the right ladder -- it made riches alright, but that would also mean the ladder will be reused by other clients. These clients needed fine-tuning to the ladder, more features being added. And that quick-and-easy build that provided riches has comeback to bite in the ass because it became unmaintainable. The only way to get more money is to sell that same ladder to new clients which would mean more headaches maintaining that ladder. I say, good luck!

  • @boriseduardosanabriaperez8291

    Thanks for this

  • @YisraelDovL
    @YisraelDovL Před 2 měsíci

    🎯 Key Takeaways for quick navigation: 00:00 *🛣️ Walking the Board Overview* - Introduction to the concept of "Walking the Board" or "Walking the Wall" in Agile stand-up meetings. - Explanation of the importance of starting stand-up at the top right of the board. - Discussion on the financial and practical reasons for starting at the rightmost side of the board. 01:27 *📊 Stand-Up Progress Review* - Detailed walkthrough of the stand-up process, starting with discussions about specific cards on the board. - Illustration of how team members provide updates on the status of tasks and address any issues or blockers. - Emphasis on the importance of keeping discussions focused and brief during stand-up meetings. 02:48 *🌟 Moments of Glory* - Reflection on the satisfaction of moving cards across the board during stand-up meetings. - Discussion on the significance of allowing team members to move their own cards, adding to their sense of accomplishment. - Exploration of the impact of acknowledging individual achievements and fostering a positive team dynamic. Made with HARPA AI

    • @Developmentthatpays
      @Developmentthatpays Před 2 měsíci

      Wow. That might be the first AI-assisted comment on the channel :)

  • @onlywenilaugh6589
    @onlywenilaugh6589 Před 2 měsíci

    Fine for development work but companies and trying to squish engineering / support work into this model and it winds up taking more time for spint meetings and jira work than actually getting things done. Hate it. It's micro management for non dev teams.

    • @Developmentthatpays
      @Developmentthatpays Před 2 měsíci

      Are you referring to Scrum? Kanban? Both?

    • @onlywenilaugh6589
      @onlywenilaugh6589 Před 2 měsíci

      @@Developmentthatpays Scrum and they said if that doesn't wind up working, we would try Kanban. Both micro manage work I've done for years and are more of a hinderance and time waster for engineers IMO.

  • @Aum882
    @Aum882 Před 2 měsíci

    Good content. The cheat sheet came to mail. Thank you.

  • @andrewmorrison510
    @andrewmorrison510 Před 2 měsíci

    But this No Estimate approach requires you to refine the whole 'project' into small User Stories at the start - isn't that waterfall?

    • @Developmentthatpays
      @Developmentthatpays Před 2 měsíci

      Surprisingly, it doesn't require that at all. All that's required is a more or less stable "rate" of break-down. (And, for that matter, a more or less stable rate of... just about everything!)

  • @mickaelarazor5260
    @mickaelarazor5260 Před 2 měsíci

    Both can be combined but we have to remember something. What is the target of what we are doing? - Put a shelf on the wall? - Store my books? - Or put a nail exactly at the right place? And if I decide to use a screw for the last one? Will that cover my needs? TDD helps the developper to develop. BDD helps the team to satisfy the requirements. With TDD, what happend if the shelf by itself is not perfectly aligned with its own spécifications, and does not match the requirements? TDD is forcing you to add integration tests. If not, at the end, it can not cover the complete target, and you will have to fix the complete system. Using BDD, you will first think about your needs. Maybe two nails will be enough. Then if you have to reach better performances, as the storage of a bigger object, you will be able to add the two extra nails that you need.

  • @saschadibbern339
    @saschadibbern339 Před 2 měsíci

    Vasco's discovery is not so much a discovery, as it is a result from common statistical principles. As example an average 'storypointet' project would tend to a story point distribution that falls into Pareto (80-20) distribution. A project with too many complicated stories (breaking away from pareto to like a non-pareto 60-40) would in the end be taken into discussion as there are too many stories that are too complicated and need division to manageable pieces. What Vasco's method can encourages is to decomplexify the stories in the start or in the process of the project, aka. we learn as we go.

  • @malcolmlisle543
    @malcolmlisle543 Před 2 měsíci

    A brilliant job as usual Gary. You covered all of the salient points. My favourite blocking method is to change the colour of the card but leave it where it is. This works really well with WIP limits because it still counts as WIP even when it is blocked so does not get forgotten about and can be focused on to get the block removed. One amendment I would suggest is don't use "Design Done" or "Development Done" there is only one Done. Use Design Complete and Development Complete that way you don't get the conversation around is it Done? Done Done? or Done Done Done? Reserve Done for it is Done as far as the Team is concerned and either in production or waiting to be released.

    • @Developmentthatpays
      @Developmentthatpays Před 2 měsíci

      Agree with you 100% on blocked items. There's a related item that I'd love your option on: there are some comments along the lines of "blocked, pending action from a third party". If the block really is "outside of the team's control", perhaps there's an argument for moving the blocked card "outside of the WIP limit". What do you reckon? (I'm aware that creating two kinds of "blocked" will end up with liberties being taken!) One more thought on this: if "blocked-by-third" party is something that happens regularly ( _is part of the workflow_ ) then what's actually required is a new column (or column pair). Put another way, the item isn't blocked, it's just moved to a new process.

    • @Developmentthatpays
      @Developmentthatpays Před 2 měsíci

      On the one-and-only "Done": a couple of people commented that I neglected to mention Definitions of Done (DoD) - note the plural. Think it's the kanban way to have a DoD for each process column. So "Design is complete when the DoD for Design has been satistfied", So "Dev is complete when the DoD for Dev has been satistfied", etc. How do you feel about multiple DoD's?

    • @malcolmlisle543
      @malcolmlisle543 Před 2 měsíci

      @@Developmentthatpays If the block really is "outside of the team's control" should it stay in the sprint? The problem with putting it in the Blocked column is that you do not go back to it because you are getting on with other things. Keeping it in place on the board means there is a regular, in your face reminder of a problem/Block that you need to get rid of either by fixing it or removing it from the sprint and dealing with it more appropriately. If Blocked by third party is part of the workflow, officially or unofficially, it is not blocked. That is like saying these items are blocked by the release team because they have to wait to the next quarterly release to go live. Something that is blocked should be able to be fixed or there is a much bigger problem that the development team has identified but should not get bogged down with. Blocking an item on the board is to highlight it to the team in case it may impact others, but also to highlight that help is needed to fix it. if it is going to take a while to fix think about removing it and getting on with things the team can do.

    • @malcolmlisle543
      @malcolmlisle543 Před 2 měsíci

      @@Developmentthatpays I have worked with teams where design was imbedded and Done meant released into production so there was only one DoD, but this is the ideal and most organisations do not have this capability. This is where different DoD can be useful. The problem I have with multiple DoD's is when they are within the development cycle. I only see impediment if there is a Dev DoD and a Test DoD etc. They are just additional hand offs, stage gates that impede progress, add bureaucracy and ultimately waste everyone's time.

    • @Developmentthatpays
      @Developmentthatpays Před 2 měsíci

      @@malcolmlisle543 - [Re. blocked items] Sooooo much good stuff here - especially the bit that hadn't occurred to me: throwing the blocked item out of the Sprint.

  • @tlingit
    @tlingit Před 3 měsíci

    That's the clearest explanation of both Kanban and Scrum that I've yet seen. Thank you. Liked and subscribed.

  • @hildajimenez9568
    @hildajimenez9568 Před 3 měsíci

    @Developmentthatpays, I noticed the link to the cheatsheets doesn't work! Nice video!

  • @meovang5185
    @meovang5185 Před 3 měsíci

    Great video Gary! I like the way you express the idea with animation. Very straightforward! Instead of getting rid of estimating, can we do story-slicing to get better estimations? I think the information of story points is not quite like junk food. It can be helpful in some use cases.

    • @Developmentthatpays
      @Developmentthatpays Před 2 měsíci

      Your comment reminds me of a team I worked with recently. The first time I joined them for an estimating session, I couldn't believe what I was witnessing. But then it happened 2 weeks later. And again 2 weeks after that. Here's what I saw: item after item after item was assigned a 3 or a 5. Very occasionally, there was one that fell outside of this range. I was amazed! What's my point? It's this: when you get to a point where (almost) every Story is a 3 or a 5 *there's no longer a reason to estimate!* Back to your question: "Instead of getting rid of estimating, can we do story-slicing to get better estimations?" Yes, that will definitely help. And you might find it helps so much, that the estimate it no longer required! Hope that makes some sense :)

  • @user-by9tg7iu3n
    @user-by9tg7iu3n Před 3 měsíci

    This channel is in every way my cup of tea, thank you!

  • @Kezrush
    @Kezrush Před 3 měsíci

    Great presentation as always! Uncle Bob is 100% an Agile guy... He was there at the beginning of the creation of the Agile Manifesto and wrote more about his approach in his book, Clean Agile. Keep being awesome.

    • @Developmentthatpays
      @Developmentthatpays Před 3 měsíci

      I'm not really sure how I could have made such a big mistake! Sorry, Uncle Bob.

  • @YisraelDovL
    @YisraelDovL Před 3 měsíci

    How do you keep saying that Uncle Bob isn't an agile guy!! He is one of the Authors of the Agile Manifesto!

    • @Developmentthatpays
      @Developmentthatpays Před 3 měsíci

      How ignorant of me! THANK YOU for correcting me - I won't make that mistake again!

  • @jacobtolman726
    @jacobtolman726 Před 3 měsíci

    Adding this to my short list of required watching for any project manager or scrum owner.

  • @Fanmade1b
    @Fanmade1b Před 3 měsíci

    A shame, that I only discovered this video now and not earlier. I (software developer) have had these arguments about estimations for several years across multiple companies now. The only good argument about holding on to estimations that I ever got was the part about validating the common understanding in the team. So if half of the team estimated three story points and the other half estimated eight, we usually found out in the following discussion that there were completely different understandings in place. I really like that you both mention and tackle that point in your video as well. But I also have to agree that the story slicing also isn't easy. At least in the team of my current employment, where we're working on a shop system, the stories are already cut down in very small pieces regarding their functionality. That doesn't help that much though, because it is built on a very complex infrastructure. So for example a story can be to show a new label on a product on the product detail page. Regarding the story, I don't think that you can get it small. What you can do though is to add a lot of technical tasks. In this particular project, one technical task could be to retrieve the information for that label from the CRM system. Another task could be to integrate that value into the specific mappers and transfer objects. Another task to validate that it's properly published into the cache. Another task to add it to the API that provides the data to the frontend. And then another task to actually show the label in the frontend. If you think "Gosh, that sounds like a really complex system!", I'd answer "It's not complex, it's ridiculously over-engineered!", but that's another topic :D But apart from the particular example, I think that this has more multiple advantages: - Smaller pull requests. Reviewing a PR for three files that add some very minor extension to the system is easy, but one with dozens or even hundreds of changes is hard. - Faster feedback. If you for example have your first PR where you just create the skeleton for a new module and you immediately get the feedback that there is already a module which you could just extend, you spend less time working into the wrong direction. Ideally, these risks would already be mitigated by working in pairs or groups, but that's another topic ^^ - Less conflicts. If you create small PRs fast and als rebase and/or merge the target branch back on a regular basis, you will have less and smaller conflicts with other changes. - More parallelization. If you have the manpower, you can have multiple people (or even teams) tackle different parts of the same issue at the same time. But that's just my current opinion on this topic and some of it has not yet been validated by myself, even though I'm trying to try it out myself. By the way; The example for the label is a real one from my current project. It was one of the first actual tasks I saw in that project and the resulting PR hat more than 2500 changed lines in a total of 42 files. For adding one label to the product. It got marginally better, but a software like that in combination with a management that is resistant to advice made me quit and now I'll try out all those great concepts in my own projects while working as freelancer on the side :)

  • @ashleydickson62
    @ashleydickson62 Před 3 měsíci

    Honestly, all this scrum, kanban, scrumban becomes a triumph of illogical definition over simply doing what is effective in the circumstance, ie dogma over agility...

    • @Developmentthatpays
      @Developmentthatpays Před 2 měsíci

      I've heard that a lot over the years, mostly (entirely?) from developers like me. People who are really well placed to "do the thing right"... but are very poorly placed to "do the right thing". And they're poorly placed to even realise it.

  • @omarfessi2761
    @omarfessi2761 Před 3 měsíci

    I have worked with both approaches, after coup, watching this tutorial enforces perfectly what I've learned from both of them and gives me more confidence explaining to people why it was better to use what it was decided to be used. Thanks bro

  • @chrisjolly4085
    @chrisjolly4085 Před 3 měsíci

    Why adding a "design done" and "dev done" column and increase WIP? Only for the pull purpose? When there is no room ór capacity to move or pick an item from design to dev, shouldn't the designers ask if the developers need help as stated earlier in the video? By implementing a "Done" column and increase the WIP, you only shift the problem a bit.

    • @Developmentthatpays
      @Developmentthatpays Před 3 měsíci

      I got this a bit wrong in the video. I _added_ the WIP for the "Done"... and I should have _taken it back_ when I introduced shared WIP. (See comments from @paulhenman above.)