Outstanding! The script, quality of narration, simple yet extremely relevant visuals in context are professional to the core! Thanks!

@Developmentthatpays

7 жыл бұрын

That's very kind of you. Thank you!

It seems to me that there's some kind of assumption that everyone not formally doing one of these "agile" methodologies must be stuck in some kind of waterfall workflow - and thus not "agile". I'd argue that in many places a productive workflow using feedback and iterations have been in place for many years - without all the rituals, ceremonies and talk. ... just focusing on getting the work done in the best way possible. Without the overhead of these rites.

Old video and still useful. Thanks for the excellent explanation.

@Developmentthatpays

6 жыл бұрын

You are very welcome!

No word other than awesome ! You should do more videos, your voice is very student friendly.

@Developmentthatpays

7 жыл бұрын

Delighted that you enjoyed it! More videos on the way!

Kanban is scrum perfected. if a scrum team becomes very efficient, it starts to shorten its sprint until there is no sprint needed. then you have Kanban. In scrum not done well, you still have churns built up in sprints. Kanban is built to eliminate that and make sure the team work effectively and efficiently.

@Developmentthatpays

6 жыл бұрын

For the longest time I had a similar view. My argument went something like this: if working on lots of items is *bad*... and a Sprint's worth of items is *better*... then the logical conclusion is that a Sprint of One would be *best* ( = Kanban). My view has softened over time: I still hold Kanban in very high regard, but my respect for Scrum has increase over time.

@viewer844

5 жыл бұрын

I agree in part with your first point, Warren, but it might not be becuase they shortent their sprint, but because they reduce the size of their stories and make them very consistent in size. Therefore, they can complete them quickly and move them across the board to Done/Accepted. However 'Scrum not done well' converted to Kanban means 'Kanban not done well.' Just because you get rid of sprint planning and sprints in now way means you're going to be efficient or effective. Kanban ensures very little. Kanban done bad means a product backlog very similar to a traditional waterfall project. It means no WIP caps on columns, no exit criteria for columns, inconsistent story sizes, slow movement of work, more work being pulled in when another story is blocked, no retrospectives or continuous improvement, no feedback loops, and on and on. Kanban solves NOTHING just like Scrum solves NOTHING unless either one is done within its framework.

Very useful! Thank you!

@Developmentthatpays

6 жыл бұрын

You are most welcome!

Amazing video. Please make more of this kind. Subscribed to your channel. What software did you use to make the presentations?

@Developmentthatpays

6 жыл бұрын

Thank you. I'm planning to do a video about that in a week or two. Most of the "effects" are done in Apple Keynote: lots of "Magic Move"

Excellent start for the series! The video is missing the Sprint Review. Why? There is nothing prohibiting multiple (even continuous) production releases in the Scrum framework. :) Great point by Sunita Singh about Sprint Retrospectives and I can relate to a lack of value. When I was a Development Team member, I was removed from my normal team for a two month project. During my absence the purpose of the Sprint Retrospective was lost. Although the Scrum Team had a "Scrum Master" (title only), the time had been re-purposed for gathering management desired metrics. The Product owner had stopped attending and the Development Team felt that it was wasted time; they desired to inspect and adapt. I had to correct and coach the "SM" and management about the violation in order to re-acquire that time for value. When questioned, the management could provide no value for the requested metrics; they had been simply filed and ignored. Looking forward to watching the next!

@Developmentthatpays

7 жыл бұрын

Missing Sprint Review? The team that I joined had been "trained in the ways of scrum". But I had not. If they didn't do it, I didn't learn it. And they didn't do a Sprint Review as far as I can recall. (But you're right: Sprint Review should have been mentioned in the video.)

@Developmentthatpays

7 жыл бұрын

Multiple/Continuous Releases. Soooo glad you brought this up. These days, we wouldn't hesitate to release "little and often". Back then, it never OCCURRED to us to release more than once a Sprint. Completely outside of our "paradigm"!

So Kanban is basically Scrum but for smaller teams who don't need all the overhead of Scrum in terms of meetings and sprints, as smaller teams tend to already have easier, faster and more free flowing communication, where as Scrum can be beneficial to larger teams to use the meetings and sprints to get everyone up to date and discover/bring up obstacles and to stay structured and coordinated?

@Developmentthatpays

6 жыл бұрын

I've heard a couple of suggestions on why a team might be better suited to Scrum or to Kanban: - Team Experience: an inexperienced team is more likely to have success with Scrum - Project Complexity: it has been suggested that high complexity projects are better suited to Scrum. I need to have a think about how team size might be a factor. Perhaps this whole area (how to pick a framework) would make a good episode?

@Morten746

6 жыл бұрын

Yeah I would love that! After giving it some more thought, I feel like the main difference between Scrum and Kanban might be the sprints. You can always add the meetings you see fit for your project and team to Kanban, but once you add sprints, you're doing Scrum. This made me reflect upon when you actually need sprints and when you don't. I feel like sprints might be great when you're building something for an outside customer, as sprints will give them a way to gauge the return on their investment over the next couple weeks (sprint), but if you're doing in-house development, say for like an online platform or whatever, then it might not be as crucial to gauge the return on investment in as strict a manner and sprint planning might just be an inconvenience, as long as the boss trusts that the team is doing their best and working at maximum capacity. I also feel like the proximity of the team plays a role in whether you actually need a lot of the Scrum meetings, as if they're sitting right next to each other, then the communication will probably happen pretty naturally anyway, so the Scrum meetings probably won't provide much value, but if they team is scattered around a larger area and more rooms, then they might need them to stay up to date with each other and to bring up obstacles. This is probably pretty closely connected to the size of the team I would imagine.

@Developmentthatpays

6 жыл бұрын

The "outside customer" is an interesting consideration; need to muse on that one. When you say "scrum meetings", I assume you're referring to the meetings *other* than the Daily Scrum / Daily Standup?

@Morten746

6 жыл бұрын

No I actually think that the Daily Standup might be the meeting that gets replaced most naturally, but only if the team is of smaller size and working in close proximity. Makes it easier for everyone to naturally stay up to date with each other and bring up obstacles as they come and ask for help as it's needed. The Daily Standup is such a small time investment though and a minor inconvenience at most, that it might be worth it to keep it no matter what, just in case it brings value. The Retrospective meeting might still bring good value, as the subject of that meeting might not be something that comes up naturally in day-to-day development, no matter the size and proximity of the team. The Review meeting might make sense if you're doing a job for an outside customer to give them a better idea of the return on their investment and for them to see the progress, but I don't think the Review meeting brings much value if you're doing in-house development. The Sprint Planning meeting obviously doesn't make sense, as there are no sprints in Kanban. Overall, from my understanding, Kanban seems like an amazing methodology for startups!

Thank you ... I understand very well..

@Developmentthatpays

7 жыл бұрын

I'm pleased it worked for you! Thanks for your comment - much appreciated.

Thanks Gary for this great video. One of the agile principles is Inspect and Adapt. When the team moved to Kanban and dropped retrospectives, how did the team inspect and adapt? What did they do to continuous improve in their product and processes?

@Developmentthatpays

7 жыл бұрын

You've raised an excellent point. I believe it was a mistake for the team to drop Retrospectives. Having said that, the team's prior experience of Retrospectives was not positive; other teams seemed to get more out of them than we did. Perhaps we were doing them wrong.

@BugTheRoot

6 жыл бұрын

The difference between a Scrum Retrospective and a Kanban Kaizen, is the Retro is scheduled on a fixed cadence and performed ritualistically. In Kanban, teams stop to analyze how they are working any time they need to, in a more ad-hoc manner. If metrics such as lead- or cycle-time are trending upward (not what you want), the team may call a kaizen session to figure out what is going on and make changes.

Question...sprint grooming and planning allows for some definition and related items to be packaged together as part of a sprint. How does that work in Kanban to move from to-do to Kanban if there isn't planning or discussion about what is active on the Kanban board?

@Developmentthatpays

6 жыл бұрын

This is a great question. If a Kanban team _fails_ to discuss, then bad things are likely to happen. In Kanban, there isn't a formal event to "enable/encourage" this discussion - so team needs to be disciplined.

@bryanmunson9449

6 жыл бұрын

Development That Pays OK, so some level of discussion happens at all times in the periphery as well as during stand up. I am assuming during related chats that it's "filtered" what user stories are next based on related stories completing, values, etc.?

@Developmentthatpays

6 жыл бұрын

That's the theory. But it takes discipline to make sure that these discussions happen. It's a big reason why kanban may be more suited to experienced teams - or domains where the complexity/uncertainty is low.

Interesting Topic.great video. I now know the difference between scrum and Kanban but need more information

@Developmentthatpays

6 жыл бұрын

Glad you liked it. I'm considering making a "Director's Cut" version - stay tuned!

so awesome so clear..best explanation. I am your new subscriber

@Developmentthatpays

5 жыл бұрын

Welcome! Great to have you onboard.

Nice video! Thank you!

@Developmentthatpays

6 жыл бұрын

+Kartalizm1903 - You are most welcome!

Great video! Very clear

@Developmentthatpays

7 жыл бұрын

Thank you! Glad you liked it.

No demo meeting at the end of each Sprint? I find these powerful because it allows the team to show off their work and those who are remotely interested in the development of the product can see what is completed so far. I have always felt that Kanban should be used with a more mature team. A team who communicates extremely well and understands the concept of empowerment. They may not have the firm cadence of meetings like Scrum but they are mature enough to ensure not to depend on them but have discussions frequently discussing what they can do to improve. The maturity of the team will make them comfortable enough to communicate frequently with the PO or customer to show them completed work. I like them both but I always use Scrum with inexperienced teams. As they progress and develop, the principles are firmly embedded into the and they are demonstrating the right behaviours then I gently move them to Kanban, if they want to try it.

@Developmentthatpays

6 жыл бұрын

A year ago, I might have disagreed with you. My respect for Scrum has increased over time. Kanban can work well, but requires discipline. Scrum can work well... even without discipline :)

Enjoying you work!

@Developmentthatpays

7 жыл бұрын

Thank you. Are you the same Jem D'jelal that I follow on LinkedIn?

Yeah if you have supreme focus inherent.. Else we work.. But towards what and how do we steer.. (I'm a fan of both but they each have challenges)...

what software did you use to create this presentation?

@Developmentthatpays

7 жыл бұрын

Paul Manning - Apple Keynote - relying heavily on Magic Move - into Final Cut Pro for (lots of) editing.

Great Video :)

@Developmentthatpays

8 жыл бұрын

Thank you!

This video is awesome!

@Developmentthatpays

5 жыл бұрын

Thank you! So nice of you to say so!

I don't see any Project Owner in Scrum show. He's a key component, providing a unified vision on the product and customers' needs. In a retail product, someone still has to fill this role (options suggested by OSS include a BDFL and round-robin). By this and other similar observations, writing the video off as naive and incompetent. The most it is is but a single, and a shabbily done one at that, experiment with predictably mixed and inconclusive results.

@Developmentthatpays

7 жыл бұрын

Excellent point! There was a product owner; wonder why he was edited out of my memory. I'm planning a "director's cut" if this video - I'll make sure to amend the Product Owner aspect.

I don't see any benefit from KanBan besides flexible. Personally, I like structured agile better.

@Developmentthatpays

7 жыл бұрын

Think that's a fairly common view. May I ask how long you've been "doing Agile" ?

@hualiang2182

7 жыл бұрын

About 6 years. And we've been using Scrum all the time and I love it. I think the reason I see Kanban isn't well structured is b/c we aren't doing continuous integration well. Besides, I met a lot of teams using Kanban while still doing planning and retro stuff. Maybe that's practical, IDK.

@dimanemchenko1047

7 жыл бұрын

You could argue that Scrum has a lot of "waste" in it (the 95% vs 100% point is this point, really), so Kanban could be less-wasteful. You could also argue that a sprint is no longer agile enough -- Scrum was originally meant to have sprints of 1 calendar month (!!), which only gives 12 releases, and 12 "inflection" points per year where the team can inspect and adapt. Nowadays, Scrum teams typically run 2 week sprints, but even that only gives ~25 inflection points per year. I've come to see the value of both Scrum and Kanban, and in fact think that a sort of middle ground between the two is the "sweet spot", balancing the strengths and weaknesses of both. Some call this Scrumban :)

@Developmentthatpays

6 жыл бұрын

Dima - Couldn't have put it better myself!

mmm i think scrum and Kanban is exactly the same thing, its just named differently... im not sure why people like doing this? the whole point of scrum initially was to continually improve the the working environment, the way scrum was constructed was by taking work improvement methods from other management ideas and and create the perfect tool for faster workflow and if there were poor and outdated methods in scrum to remove them and replace them with something better. for some reason people made scrum a "solid workflow framework" instead if it being flexible an continually improving and taking ideas. so basically Scrum can take the new methods from Kaban, add it to the scrum structure and still be called scrum like it did since the very beginning...

@Developmentthatpays

6 жыл бұрын

I'm confused: if Scrum and Kanban are the same thing, how is it possible for Scrum to take new methods from Kanban?

@QuicoReed

6 жыл бұрын

No, they are NOT the same thing. There are similarities but they are quite different, and are intended for different types of work and therefore different types of teams. Their processes are different, their cadence is different, their backlogs are different, their roles are different.

@michaelvictor8623

6 жыл бұрын

Quico Reed I do believe its the same thing (that doesnt meen its a bad thing though) and i'll try to explain why. initially scrum was not meant to be a set product with a set of rules that can never be changed. It was an idea, a consept, an attempt to take the best practices whatever they may be, simplify them and perfect them for the fastest and best management and change it when necessary. The idea was to break away from management methods that was more traditional than effective. So it was more a rebelion against hard headed ineffective traditional ways of management. So you can't have traditional managemnet rebelion (scrum) against a traditional management rebelion (kanban) thats just funny. (kanban vs scrum, where scrum is now concidered traditional and ineffective). I hope im making sense... Kanban and scrum is a lot like fruitbaskets, a fruitbasket is not entirely defined by its content, two fruit baskets can have completely different fruit or the same fruit, it will still be a fruitbasket, the same can be said for scrum, thats why I said scrum can take ideas from kanban and still be scrum. But people try to take ideas and consepts like this make them "solid" like scrum = apple and kanban = orange and "force" them to be different. If in this case scrum became "traditional and unchangeble" then the creator of scrum failed to do what he initially dream to create, not because HE failed, but because people failed to see what he tried to create, an "idea" not n "product to sell". That being said, you cant say kanban is against scrum, becuase its the same "concept" only labled differently to achieve a different set of goals for both to ultimately achieve the best management performance, and that is not bad. its is only bad if it is labled in such a way for you to compare and reject the one or the other. Because both were meant to make people smart and flexible to learn from other management ideas, improve them and incorpotae them into the management system. Not create more fixed traditional methods of management or reject good management ideas becuase its "Scrum" or "kanban" or whatever you want to put between the "". I hope I made sence. My brain is fried trying to put my thoughts into words... -_- ~*

Its not rocket science Kanban would do so much better.....they just jeep working ob the backlog. While the other group has constqnt meetings to review and alow things down. Kanban works for constqnt release and scrum is needed for companys that have ever transitioning priorities.

Полезное видео, его прекрасно дополняет видео "Scrum - быстрое знакомство с методологией гибкой разработки ПО" vk.com/businessanalysts?w=wall-68151244_1292%2Fall