Have you noticed the gap between what Agile PROMISES and what it DELIVERS?
If so you're in the right place.
Here you'll find the small - and not-so-small - things that make all the difference.
So that you get stuff done, and have more fun doing it.
Gary Straughan
Founder of Development That Pays
Пікірлер
Nice example for BDD & TDD and non-IT field. Thanks
I would go with TDD in an actual world, but BDD in this case of hanging a shelf is more practical and faster with a quick mallet touch and alignment check. I would think in most organizations is the lack of awareness of TDD which drives development/QA organizations to move to BDD. There is again the talk about white box and black box testing which also plays an important role as to whether development teams resolve to TDD or BDD. In deployment pipelines we also have Sonarqube which helps with coverage analysis but component/integration tests are usually black box tests written by QA organizations. TDD or BDD is a very debatable topic and past experience has told me that really depends on what the development/QA (engineering organization) are comfortable with to get latest code to customers asap.
This video goes to the point and super easy to understand.
Nice!!!!
Nice tutorial. So informative.
"Waterfall is like a train" ... bites tongue trying to avoid mentioning SAFe's Release Trains 😀
Oh wow, is that a thing!? 🤪
"Something of an accent left" 😂
Focusing on velocity -> feature factories -> keep shovelling widgets out the door & don't waste time thinking about feedback ☹
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.
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."
big thanks for that series of videos. I realize now that I am doing kanban since ages then. 🙂
Excellent news!
My experience is of a team that prioritises items by value, but uses velocity to create a sense of predictability around release dates etc.
That sounds good to me 👍
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.
You're exactly right: if we're not careful it becomes a factory.
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. ☕
Thank you! You too!
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?
That's the art and science (!) of Story Slicing. This episode goes in to more detail: kzread.info/dash/bejne/fWqE09GfldTVc8Y.html
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. )
Yep, number 5 is way to go.
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!
That's a great idea. (I wonder where I could acquire a licence...)
Great explanation!!! Thank you.
Very detailed information. Looks good thanks for my free copy.
Glad it was helpful!
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
Wow. That might be the first AI-assisted comment on the channel :)
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.
Are you referring to Scrum? Kanban? Both?
@@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.
Good content. The cheat sheet came to mail. Thank you.
Excellent. I'm glad the cheat sheet made it through.
But this No Estimate approach requires you to refine the whole 'project' into small User Stories at the start - isn't that waterfall?
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!)
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.
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.
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?
@@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.
@@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.
@@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.
That's the clearest explanation of both Kanban and Scrum that I've yet seen. Thank you. Liked and subscribed.
Awesome, thank you!
@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.
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 :)
This channel is in every way my cup of tea, thank you!
Thank you! (Extra points for mentioning tea!) 👍
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.
I'm not really sure how I could have made such a big mistake! Sorry, Uncle Bob.
How do you keep saying that Uncle Bob isn't an agile guy!! He is one of the Authors of the Agile Manifesto!
How ignorant of me! THANK YOU for correcting me - I won't make that mistake again!
Adding this to my short list of required watching for any project manager or scrum owner.
Really? Fantastic!