Видео

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

"Something of an accent left" 😂

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

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

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

w

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.

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.

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..

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

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

dude repeats the video title for 30 seconds straight..

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).

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

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

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

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

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].

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

excellent presentation in finest way

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. )

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...

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

Great explanation!!! Thank you.

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

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!

Thanks for this

🎯 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

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.

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

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

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.

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.

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.

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

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

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.

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

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.

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

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

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 :)

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...

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

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.

Used different views of the board which includes a swim lane for a sub-team or person. Gives the advantage of being able to see the work and in case of Scurm, allows the daily standup to focus on individuals work progress. Also fan of subtasks that allow work to parsed based on dev, des, test, etc.