- 93
- 5 242 256
Mark Shead
United States
Registrace 15. 02. 2011
Mark Shead is an Agile coach and software engineer. This channel is videos of things he has made to try to help teams follow Agile principles or to demonstrate technology that will help programmers write code more efficiently. If you are interested in learning more about Agile, you can sign up for his weekly lunch and learns and get a copy of is book here: www.xeric.net/#starting-agile
Agile Principles #2 - Welcome changing requirements, even late in development.
The second Agile Principle says: "Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage."
I've published a book called "Starting Agile" that is designed to help you start your team's Agile journey right. You can buy a copy from Amazon, but I'm giving free copies away to my subscribers from CZcams. You can signup for a copy at this link:
www.xeric.net/#starting-agile
I've published a book called "Starting Agile" that is designed to help you start your team's Agile journey right. You can buy a copy from Amazon, but I'm giving free copies away to my subscribers from CZcams. You can signup for a copy at this link:
www.xeric.net/#starting-agile
zhlédnutí: 2 247
Video
Merry Christmas - A video Christmas card
zhlédnutí 608Před 2 lety
Merry Christmas - A video Christmas card
Agile Principle #1 - Satisfy the customer through early and continuous delivery
zhlédnutí 9KPřed 2 lety
Agile Principle #1 - Satisfy the customer through early and continuous delivery
Agile Minimal Viable Product - Skateboard vs. Car
zhlédnutí 3,4KPřed 2 lety
Agile Minimal Viable Product - Skateboard vs. Car
What Agile Taught Me About Homeschooling.
zhlédnutí 2,5KPřed 4 lety
What Agile Taught Me About Homeschooling.
Agile Transformation - Is that how you become Agile?
zhlédnutí 15KPřed 4 lety
Agile Transformation - Is that how you become Agile?
Because Amazon - Making Agile Decisions (Cartoon)
zhlédnutí 19KPřed 4 lety
Because Amazon - Making Agile Decisions (Cartoon)
What is DevOps? (explained in a two minute cartoon)
zhlédnutí 43KPřed 5 lety
What is DevOps? (explained in a two minute cartoon)
What is Behavior Driven Development? (4 minute cartoon on BDD)
zhlédnutí 64KPřed 5 lety
What is Behavior Driven Development? (4 minute cartoon on BDD)
What You Need To Know About Behavior Driven Development In 4 minutes.
zhlédnutí 10KPřed 5 lety
What You Need To Know About Behavior Driven Development In 4 minutes.
What is Agile Development Methodology? (hint Agile isn't a methodology)
zhlédnutí 39KPřed 5 lety
What is Agile Development Methodology? (hint Agile isn't a methodology)
Regular Demos - Creating Agile Software
zhlédnutí 20KPřed 5 lety
Regular Demos - Creating Agile Software
Talk To Users - Agile Principle of Face-to-face Communication
zhlédnutí 17KPřed 6 lety
Talk To Users - Agile Principle of Face-to-face Communication
Standup Meetings - What's the Goal in Agile Teams?
zhlédnutí 33KPřed 6 lety
Standup Meetings - What's the Goal in Agile Teams?
Why Have A Daily Standup - Agile Practices
zhlédnutí 79KPřed 6 lety
Why Have A Daily Standup - Agile Practices
Your video has left me inspired to pursue my own creative endeavors.
watch my contnenttt
So its basically BS
Great explanation! I´ll share with my friends! Thanks!
👍🏽👍🏽
good description so continues
I'm failing Spanish cause I can't memorize anything so I hope this helps
That really is helpful, thank you. I shall persevere with this and work through the text paragraph by paragraph.
If you think that writing software is like painting a house, then you are definitely 100% an accent coach, and 0% a software engineer. Most companies don't write software for just one customer. That is the beauty of software de development. That is, if you have product managers who are good at their jobs. You are not painting a house, but creating a tool to enable any future customer to have a house in the color they choose. Otherwise you'll be out of business soon. If the product manager didn't take the time to realize that color choice is a variable for customers, and is asking you to change things like this mid flight, then it is a failure of the product manager to do the requisite due diligence and market research. Software development is expensive, and not enough effort is put into planning things out. It is simply unrealistic for most companies to work for one customer at a time unless they charge outrageous rates. In that case you're really not giving the customer a competitive advantage so much as you are over charging them for your own negligence in gathering proper requirements
> It is simply unrealistic for most companies to work for one customer at a time unless they charge outrageous rates While some companies make software to sell to others, a very large percentage create software for their own use. > If you think that writing software is like painting a house, then you are definitely 100% an accent coach, and 0% a software engineer. No analogy is going to be perfect. Painting was chosen to represent some thing in a project that can be changed, but requires significant rework if the customer changes their mind. The goal of this example is to get people thinking about how they can make smaller investments before letting the user experience what has been created and provide feedback. But all analogies have their limitations. Do you have a better analogy that explains the need to leverage change in a way that provides a competitive advantage for the customer?
'Promosm' 😢
Love your work and will love to collaborate. Its been very useful for onboarding newbies and reiterating standards for the old blocks.
👏🏻👏🏻👏🏻
Thank you so much for the video; it validates what my problem is: recalling (I call it retrieving) what I read or hear.
Glad it was helpful!
Both educational and informative at the same time, thank you!
I can see the value of Agile but scrum is interesting. With some scrum masters, the team spend a lot of time following the rituals rather than doing the actual work. Some stake holders get really annoyed with the meetings upon meetings but they have to attend to be seen as embracing the agile way! We have a joke: Confucius says "Talking doesn't get the rice cooked!" There is a point with which the amount of time spent on figuring out ways to improve things in the past far outweighs the benefits of the returned improvements. Sort of like a dog chasing its tail. I am only sharing this because of some scrum masters who are so rigids in their rituals that the process becomes bogged down in the mechanics of getting things done, which contradicts what being agile is all about! Great video, by the way, and thank you very much!
Awesome video, thank you!
What an awesome video - thank you very much!
No intresting stories on stand up meeting 😅
Great job! Very useful!
Hello If you can need more animation video for your channel i can help you!
Thanks. I took a look at your youtube channel to see your work.
Quite informative Really appreciated
Agile is very much a methodology, an adaptive set of METHODS called VALUES and PRINCIPLES...you follow "specific ways" of approaching work...not calling them methods or methodology is not helpful....especially as methods develop as a result of following the so-called principles.
Very useful. Thank you.
Glad to hear it was helpful!
Thanks for good explanation and animation.
I couldn't make the session but I've just caught up with it and it's brilliant, thank you. Very useful!
Thanks. I'm glad it was useful!
In Agile's wide realm where workflows reign, Two champions stood, their prowess plain. Scrum Bum, the stinky, a booger-picking knight, Against Kanban, the curry lover, in belching delight. Scrum Bum, with his board of tasks in sprints, Moved stories along without giving an inch. His method was rapid, like his pick and roll game, Each booger flicked with precision, his strange claim to fame. Kanban, with a board that flowed like a stream, Managed his work in a continuous dream. He loved his curry, a spice so divine, With each hearty belch, his columns would align. The battle was epic, a sight to behold, Scrum Bum’s plan versus Kanban’s flow of gold. One picked with gusto, the other let fly a gas, Their methods in contrast, a class against class. The product owner watched with a curious eye, As story points flew and burps filled the sky. Scrum Bum, with a sprint, a backlog attack, Kanban, with WIP limits, no work to stack. Scrum Bum's stench wafted over the field, A tactical cover, his olfactory shield. But Kanban stood firm, his palate quite strong, Belching back with a curry-powered song. The duel of methods, a war of the ways, One with his nose, the other with his braise. Yet as the dusk settled on the battlefield wide, The two found respect, and a sense of pride. For though they were different, in style and in taste, Their goals were the same, no effort to waste. Scrum Bum and Kanban, in their peculiar fight, Proved that in Agile, there’s more than one way to do it right. So let's raise a cheer for this oddball pair, Their epic battle, beyond compare. With Scrum Bum’s picking and Kanban’s curry call, In the end, it’s the teamwork that stands tall.
Definitely the most unique comment I've see on on any of my CZcams videos. :). Did you write that?
AI knocked it out. I have been studying for the PMP and needed a break. It was inspired from PMPs I have worked with though.
Oh Hi Mark
Hi Seth...
I love this video. Been working in agile teams for my whole career but never saw this before. I love how it unpacks all the things agile is not at the beginning.
Thanks! I'm so glad to hear it was useful. If you like that video, you may also like the live lunch and learn I'm giving on 1//16/2024 covering the topic. You can get an invite here: events.agilelnl.com/
this is complete bullshit
How so?
this is much better explanation of big word "Agile".
Thanks! Glad to hear it was useful.
Woah! I saw the title and expected you to try and sell me Scrum... what a pleasant surprise when you did quite the reverse.
I'm not really a big fan of Scrum. If a team feels that following Scrum helps them have more agility, then that's great. But too often teams think they have agility simply because they are doing some of the things Scrum says to do....like having a retrospective or standup meeting. This usually leads to teams that claim to be Agile that have absolutely no agility in the way they work.
How is software quality guaranteed with this approach? I imagine there are scenarios where an application's behavior may be correct, but the quality of the code may still be suboptimal. Are additional practices such as peer reviews needed to prevent long-term problems?
The approach lends itself well to pair programming which is basically real-time peer reviews. But the big benefit you may be overlooking is that when you can quickly prove that the application does what it is supposed to do, developers are much more free to fix things as they go. A good portion of what developers do on existing systems without tests is try to figure out how to make a change with minimal risk of breaking something. Often times the way that has the least risk of breaking something is what pushes toward poorly designed code. When developers have the freedom to refactor, the code tends to stay higher quality.
Awesome, thank you for sharing
Thanks mark 😄
I heard of agile 30 minutes ago while researching what scrum was and in this time I've semi concluded that this entire framework [or rather lack thereof] is decidedly confusing, sounds like it would be a completely unreliable methodology when put into practice in a real world setting given todays prospective talent pools, brings to mind what a huge New York or LA ad agency looked and felt like in the 80's which is probably it's most desirable quality, sounds like something made up by some liberal arts grad student [much like a lot of todays political left wing ideology and verbiage] is somewhat of a fad that's past or dying out due to the disorganized remote work/less work mindset typical of gen Z'ers. Lastly, though the salary range for a scrum master at google is quoted at $190k per year [on google search that is] I honestly cannot fathom that "agile" methodology is in wide use across the corporate landscape in 2023 or would be at all beyond that. It's just too impractical. Cute idea on the surface I suppose but at the end of the day just meaningless buzzwords after one takes a quick deep dive into it. But I've wasted an hour of my life on more ridiculous things than this here and there, so, yeah.
If your take away is that agile is a methodology, are you sure you watched this video? Part of my reason for making the video was to get people to see that it is NOT a methodology.
How you create these cartoon videos, which software do you use?
The videos are made with Vyond.
❤❤❤❤❤❤❤❤
My goodness, bla bla bla bla METHODOLOGY bla bla bla bla... GET TO THE POINT!!!!!!!~!
Sorry it wasn't what you were looking for.
7:37 So it's agile to incur technical debt?
If you mean delivering something that the customer can use with the intention of evolving it in the next piece of functionality you deliver, then yes. If you believe you can never deliver any code to the customer that you will need to change later, then you aren't following Agile. The original usage of the term technical debt was to get people to think about whether they were borrowing for something like a mortgage where the value of being able to use the thing sooner was worth way more than the interest they were paying or if they were borrowing from a loan shark. Too often people start calling everything "technical debt" as an excuse to delay delivering something the customer can use today. When a team is following the Agile principles, they necessarily build in the ability to make changes at low risk and low cost. This allows them to rapidly deliver useful things to the customer that can start earning a return on investment without needing to wait for all the other things that will need to be done later.
Amazing video and analogies with the cake slices and music sheets
Awesome video
Great video and examples
Great. video
thanks
As a customer I find too many suppliers think Agile means "You'll get what you get when you get it, and we can't be held to a deadline or price". Constant change to react to opportunities is fine and dandy, but each change impacts overall cost and delivery time. You say Agile is all about the Customer but it isn't; it's all about the techies doing what they want. It's no surpise to me that so many of them go out of business after a short time
If "techies" just do what they want without trying to deliver what the customer needs, the project will get canceled or they company with go out of business. The value of Agile is getting the customer and the developers collaborating on how to succeed in helping the business make money. If that isn't happening, then they aren't following Agile. That said, you can definitely find people trying to sell what they are doing as "Agile" without any intention or desire to actually follow the Agile principles. It is unfortunate, but just like the "1 Hour Dry Cleaner" that cannot do dry cleaning in less than 24 hours, it doesn't really matter what you call yourself. It matters what you actually do. czcams.com/video/5JN8W_LdF2o/video.html
This is madness, never would have thought that AI will help me with TDD. God bless you team for this awesome video
Nice presentation, the content was narratored concisely and clearly. The animation is of high quality and spot on with the context.
Your videos have been instrumental in my programming journey. Thank you for sharing your expertise!
Great to hear they are useful!
I love how you incorporate real-world examples into your tutorials. It makes learning so much easier!
it was great! thank you so much. if you had explained more about the connection between every increment and sprints, it would have been better.