What is Agile?
Вставка
- Опубліковано 30 тра 2016
- This short cartoon answers the question "What Is Agile?" and will give you the background to understand the Agile principles and values and how they can help you and your team work together more efficiently. If you'd like a free book on this topic, please see below...
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 outright. You can buy a copy from Amazon, but I'm giving free copies away to my subscribers from UA-cam. You can signup for a copy at the link above.
You can subscribe to my channel with this link:
ua-cam.com/users/markshead?sub...
If you'd like to connect with me on LinkedIn or Twitter you can find me at the link below. Just send me a message saying hello and that you found me from one of my videos:
/ markwshead
/ markshead - Наука та технологія
This is great but I have to say I found it better watching when setting playback speed to x1.25!
x2
great tip. I fell asleep
x2
2.75x * edit, by the end I was at 3.75, just keep speeding it up when I felt it drag.
@@MichaelMantion haha I know right! Btw is this video so active that it got 2 comments on the within an hour? 😅
It's awesome to emphasize that agile is a set of value and principles. Too many people focus on the specific process or tools, and lead the organization less agile than before.
Probably best explanation of Agile. Now I know I don't need agile.
This is spot on. I've been part of teams following agile for years, and this video depicts what agile is, on the ground level.
Agile Principles per Mark
1. Highest Priority is to satisfy the customer through early and continuous delivery of valuable software.
2. Welcome changing requirements, even late in development. Agile processes harness change for customer's competitive advantage.
3. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
4. Business people and developers must work together daily throughout the project.
5. Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
6. The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
7. Working software is the primary measure of progress.
8. Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
9. Continuous attention to technical excellence and good design enhances agility.
10. Simplicity - the art of maximizing the amount of work not done - is essential.
11. The best architectures, requirements, and designs emerge from self-organizing teams.
12. At regular intervals, the team reflects on how to become more effective, the tunes and adjusts its behavior accordingly.
Originally, Agile was an idea for small software development teams to self-organize in such a way that they are more in touch with their customers, determine more accurately what the customers actually need, and deliver it in small increments that leave room for redesign and even complete direction changes. By now, it has mostly degraded into a fad and a buzzword that keeps consultants fed, and is perverted by scores of unimaginative middle managers as another tool to enforce micromanagement, bureaucratic conformity, general averageness, and keeping employees exchangeable and disenfranchised from any meaningful design decisions. If you go on a job interview and they tell you they are agile, you should ask some questions. Is the whole company agile, or will it be just you who has to be agile, picking up on a daily basis whatever management fancies to throw at you? Is there a "project owner"? Who is he, an actual customer or someone from your own corporate hierarchy, in a position to effectively "override" Agile? Are there project leads? How does their role relate to Agile? Are technical decisions made after in depth discussion, or per ordre de mufti? Is there any freedom to pick tasks, or is there a strict order of what you have to work on? Are you given time to develop expertise in any area, or just picking up scraps on a daily basis? Do you do sprints? How long are they? Why are they as long as they are? If they are two weeks long, is there a release to the customer every two weeks? Or do you just sprint for two weeks because management thinks that's a nice pace to keep everybody busy? Is the team always sprinting? Or only when particular goals have to be met? Is there a phase between sprints? How long is it? How does the team deal with technical debt? And so on. If they start to cringe or evade any of these questions - think again before taking the job.
Well said
Amen
Good one! Spot on, thanks.
The video without this comment is gibberish!
omg the video made no sense but your comment did. thank you so much
As a non-English speakers, Thank you for the subs
Hey Mark ... I just came across agile few days ago ...And was looking for simple explanation of what it could be..... I came across lot of technical blogs and videos and got more confused. This video is the best of all. It is very simple and very effective. I understand making this video must have been difficult.All the animation and making it simple ... Thanks a lot for your helping hand in my agile learning process.
Learned this in my software engineering class and found that I already used these principles. It's just about being flexible and finding the easiest way to do something for your given team. When it comes to building projects I might start out in one framework but end up in another; depending on how the team functions and their qualifying skills.
That's great you learned about Agile in school. Most of the programs I've seen don't cover a lot of the practical aspects of actually participating in a team writing software, so I'm glad to hear they are starting to include these topics.
As we are adapting Agile, your lessons is a guidance for all of us to follow. Thank you so much Mark, I am so lucky to find your videos. It gives our team a foundation to do thing right from start. Best of wishes to all that you do and truly grateful to find you.
You are very welcome
When I was studying Agile, my instructor pointed our class to this video, and I found it to be a really helpful introduction and overview of a new topic to me. It looks like this channel is a great place to start for people wanting to learn Agile!
How do you study agile? It's literally just 4 values and 12 principles on a ghetto page
Could not get better than this. Amazing job.
there should be a mix of Agile and a mix of Real Life (contracts, budgets etc). It so easy to fall into the "less planning, more change" or "less problem solving and more delivery", until you have to rewrite code, or your project profit turns negative, or your customer misses the investors meeting with a fully scalable app. Software development in real life is a project and companies need to plan and deliver in order to survive.
"agile" is a word I've been seeing on job ads very often lately. now finally I know what does it mean. Thanks
@cukcan - don’t stop with this explanation of Agile (which is good). It gets far deeper.
Was looking for a refresher on Agile as I move towards starting my career. This seems like the purest overview I can find. One that forgoes talking about the kinds of tools that teams will use and focuses on the ideals that are common to all agile organizations. Really enjoyed this and I'll be watching it on repeat for a while to let it sink in.
Seth M Glad it was useful. I'm posting new Agile videos every month or so. I'd love to get your feedback on the other videos too. If you subscribe you can get notified of new videos as they are posted.
Excellent plug. I most certainly will! Thank you.
LOL I read that last line just as I hit Replay...
Probably the best and the most simply explained video that I have ever seen. Thank You Mark.
"Thank you " is not enough . Very well explained ,I genuinely thank you from my heart for sharing your knowledge Mr. Mark.
Thank you for taking the time to comment!
My Pleasure .
That's great. Thanks for posting this. It will help me talk to potential candidates in a more knowledgeable manner about Agile and Scrum methodologies. Cheers!
agile is a methodology?
Nice video - "Agile is a set of beliefs (values & principles) on how to make decisions ...."
Well done, thanks for sharing.
Perfect Explanation !!!
in love with your voice, it makes me feel comfortable to listen to the content without distracting on something else. , GREAT JOB !!!!
congrats because it is a robot, Sevgi
Not to say I don't sound robotic, but it is really me. That is why other people are complaining about the sound of me swallowing while I'm talking. :)
@@MarkShead they are wrong for sure
@@MarkShead It's a real inspiration, even for our small florist shop.
Thanks for explaining Mark. I see Agile a lot but always saw ambiguous and unclear definitions. I’m understanding now that Agile is a series of principles that values working closely with the customer in implementing continuous updates to best suit the needs of the customer, with added flexibility in the ability to change according to need and accomplished through self-organized teams.
This is a wonderful brief description of Agile Values and Principals. Thanks
Wonderful. Thanks for making the video and sharing your thoughts!
Extremely helpful. Do upload more content :)
By far the best Agile explanation..
I just got clear complete understanding of agile and ended up subscribing to your channel. Thanks for creating such valuable content.
Great explanation. I have to say I can see why devs complain about it.
1) There is no harm in building out only what is needed as long as it does not create more work down the road. Difference between a band-aid and a MVP. If you implement a crappy db layer in the example provided, that may later have to be removed and then transitioned to something more robust, you are not saving time.
2) I question the necessity of daily face to face meetings about everything, but I understand due to the personality and nature of the way a lot of devs like to work, it's better to have unnecessary meetings than to not have necessary ones.
> I can see why devs complain about it.
I've never seen a good developer working on a project that is actually following Agile principles dislike the process.
Explained very clearly. Thank you :-)
Trustworth Video! I love especially the simple title! I now have an overview of how Agile works. Cheers
Excellent Presentation!!! Thank you!!
Best explanation I have ever heard. Nice work!
I believe it’s more than that. There are real corporate life examples and clear explanation that mimicking someone’s practices won’t make it Agile. You won’t find these in Manifesto. Many companies believe that practicing Scrum and naming their teams with Squads and Chapter because Spotify does, will make them Agile. It won’t. It is not about practices. It is about values and principles. So this video is a spot-on, addressing a common misconception.
Scrum Master training available at low cost
facebook.com/groups/518172759211450/?multi_permalinks=518698752492184¬if_id=1621733254176376¬if_t=group_activity&ref=notif
Best explanation of Agile I have seen. Well done!
Thanks. I'm glad you found it useful.
Jennie Ayres js🔝🐶
Oh very! I finally understand what agile is thanks to you Mark, after throwing around the word for a good 3 months(is a job requirement) without a single clue what it truly stood for. xD
Thank you for taking the time to comment. I'm glad it was helpful!
Jennie Ayres Agile Network Short and well detailed presentation ua-cam.com/video/0wNucF6_4Os/v-deo.html
Simply Awesome ...
Thanks :)
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/
So this is what I got - "Make smarter decisions by making smarter decisions." and don't forget "Be flexible enough to change from a less smart decision to a more smart decision." P.S. "Don't micromanage, and use good judgement."
My life will never be the same.
:) I agree that most of the Agile principles are pretty much just common sense. That doesn't mean they are common practice though.
@@MarkShead If that's so then why Agile over any other methodology.
@@elizabethblackwell6242 If Agile principles are pretty much commons sense, then why would you choose to use them over something else? Probably because making common sense common practice brings a lot of value to the process of delivering software. Especially the principles that let you start getting value from your code as it is written rather than needing to wait until everything is complete first.
@@MarkShead I think that's a bit of a facile response. ERPs are so integrated that small packet deliveries are just not helpful. Often ERPs are purchased to support new organisational structures of say new shared services environments which lends itself better to waves or phases of implementations. In this case, Agile creates an unwieldy and costly overhead and makes scope difficult to curate and control.
My objection is to Agile in ERP implementations. It's just not helpful, far from it, it's dangerous.
@@elizabethblackwell6242 I'm not sure what principle or value is driving behavior that you think is dangerous. Working daily with users? Delivering some type of working software on a shorter timescale? Are you sure you are responding to actual principles and values from Agile and not a bunch of practices someone decided to implement whether they made sense for your particular project or not?
Thank you for this informative video.
Pawan Joshi Agile Network Short and well detailed presentation ua-cam.com/video/0wNucF6_4Os/v-deo.html
Thank you, great knowledge given.
Thanks Mark Shead, whew... Thanks really for putting this masterpiece together in clear and detailed concepts
What a terrific presentation, thanks for taking the time to put this together. Im starting my Agile Foundation soon and this is a great introduction before I start. Good job.
Scrum Master training available at low cost
facebook.com/groups/518172759211450/?multi_permalinks=518698752492184¬if_id=1621733254176376¬if_t=group_activity&ref=notif
Agile is another management wrapper for all the decisions developers and IT professionals make(often in real-time) to produce a product. In my experience end users do not have a clue what they want, how technology can help them, how to make things better or how to achieve it. They constantly move the goal posts (mid-project) and ignore integration and future needs. There is always a mismatch between what is possible and what is required. You have to think of it as like asking a child what they really want for Xmas - ultimately the adult (the IT developer) has to impose some sanity on the situation.
Short-cutting final requirements to satisfy a short-term need to show the customer something is literally insane. Allowing management to specify projects in vague non-technical terms (devoid of content) will always ensure that they take the credit for zero input and this will be reflected in their salary and not yours.
Agile says "Make me a starship with warp capability"
Developer (the guy doing the actual work) says "How do I invent a warp engine".
Utter piffle which allows managers (life's bullshitters) to prosper at the expense of people who actually know how to do it.
> In my experience end users do not have a clue what they want,
So you are working with users who aren't clear what the end state of the system needs to be. That isn't unusual, but Agile gives you some ways to work with this reality instead of fighting it.
> Short-cutting final requirements to satisfy a short-term need to show the customer something is literally insane.
Since we established that your users don't know what they need anyway, your requirements are just guesses. Getting the simplest thing that provides the users with business value into production where they can start providing feedback is a very efficient way of moving forward with actual working software.
Yeah that about sums it up !
If you wait for final requirements in a fast moving world, you'll never deliver anything. No product is ever final, it's always just enough.
Geezus. What a pessimist. I enjoy hitting business home runs. I don’t look down on my business partners, I listen to them and coach them. We love what happens next. Try it sometime.
MeTube but basic requirements should be put down and minor changes can be accommodated on the fly. Starting without a basic concrete requirement is nothing but misuse of agile
Thank you for this. This is a great springboard for understanding and implementing agile.
Thank you Mark.Nice presentation!
Mark, this video is excellent! You have the gift of teaching! I'm glad that know I understand what agile is. :)
I didn't know that the agile team should be so independent and I swear I read on the scrum guide that Agile was a framework lol
I can understand why you say Agile is a Framework. But Agile is broken down into more than 50 types beyond Scrum.
"Agile = Ready to accept the changes as per the repeated changes in requirement".
SIMPLE AS THAT.
more like you value
1. Individuals and interactions
2. Working software
3. Customer collaboration
4. Responding to change
as he said in the video. All you said was the last point
Don't fall into a "pentagon wars" type pitfall.
The more functions you're adding up to your program the less useful it becomes.
Adding the bill to the client does not retract agility, right? It's literally more resource spent to deliver result.
@@blahblahblah747 Yes, but how to denote then when you only mean "Ready to accept the changes as per the repeated changes in requirement" without the whole phrase? The thing is, names should be speaking and have fidelity to them. So why would you expect "agile" to mean there is a customer for example? Or software? When agile in other contexts only means something like swift and flexible?
Awesome! Thanks for putting this together Mark.
Hey Mark, You are doing a fabulous job here. The way you present things is simply amazing. Crisp and clear. Thanks for this video.
I swear this can also be the definition of how to run a preschool classroom. I’m assuming Agile stole preschool classroom principles and turned it into something adults do.
I believe there is a book by the title Everything I Needed To Know I Learned In Kindergarten that kind of takes that idea and runs with it.
Agile is a joke. Look for scrum jobs at Big tech like Google, FB, Apple, Uber etc. You wont get much. But there are plenty of scrum master jobs at IBM, banks and HP. Notice the differences between them. One is going up and innovate the latter are sinking ship.
@@editg121 what are the big tech companies are using then? Just trying to decide which way to go...
@@editg121 If you are trying to find jobs at places that follow Agile principles, the fact they mention Scrum in and of itself is NOT a good indication of whether they are striving to follow Agile principles.
Oui mais p
Mark, this is a beautiful, humanist explanation of Agile. Excellent! A+
Careful, your lips will get stuck to his ass.
ha julie you are trippin'
Short and simple explanation - great video
Thank you for sharing!!!
This is the best and most comprehensible explanation of Agile values and principles I've ever seen. Really good work Mark. Thanks!
Thank you. I appreciate the encouragement.
I was an agile developer before agile became a thing :) Back then they called it RAD
I think there are some key differences between agile and RAD.
@@Zack_Taylor of course there would be key differences, Agile had evolved, otherwise, it would still be called RAD today :)
Really? Do you have some docs for it?
Went hand in hand with XP and Rational Rose, iirc.
You should do a video about RAD on compare and contras.
this got me to watch the rest of Mark's training videos and now I subscribed for all Mark's videos. good job Mark!
Glad they were useful!
Mark Shead , I just sent you an LinkedIn invitation. It would be so nice if we can connect via LinkedIn. I hope it is OK with you
Thank you so much for this GREAT explanation
excellent explanation of methodology!
"Agile isn't a methodology"! @1:10 ;)
it isn't a methodology thou :)
Agile is a panacea sold to managers as a cure for their lack of technical insight into the actual skills and tools of the people underneath them. It promises a fix for the current trend of hiring and swapping management into different roles rather than promoting those who are somewhat skilled in the areas their subordinates. Agile...It's better than whatever you're currently using and we'd like to sell you certification (TM).
You can draw all the loops colored boxes and arrows you like. But in the end, a manager must tailor their own process by knowing the work of those underneath them.
I've heard people describe Agile as "the way people who don't write software assume software is written." :)
Much of the certifications seem centered around SCRUM. While SCRUM can work great for some teams, Agile is much more generic/flexible and really comes down to doing things that make sense and letting teams improve things as they go.
PixelOutlaw, you could not be more wrong. NO WHERE in Agile does it encourage the issues you addressed. To the contrary, Agile empowers the teams, and guides the management to support the teams and develop them into better teams. It also helps break down the hierarchical structure to which you seem to be wed, based on your comment. Perhaps that is why you sound resentful of it. Some managers do feel threatened because they think it removes their authority.Steven Jobs said: "It makes no sense that we hire smart people and then tell them what to do. We should hire smart people and have them tell us what to do." Agile principles and values lead to management style that supports teams, rather than try to tell everyone what to do.
I like your response quico, this makes more sense for everybody involved. I do also see how bad experiences in the work place can lead someone to the conclusion that the system is wrong in some way. Honestly from experience its a dice roll when you join work colleagues, many of them have personal issues that bleed into the work place. That's why working in teams with other people is so damn hard.
@MomoTheBellyDancer Amen Brother!
Says a guy with zero history of successful agile experience or the enjoyment of pumping out quality code incrementally and knowing when future deliverables can be expected.
This is awesome. Thanks a lot
This video helps me get an accurate view of agile, thank you from a bottom of my heart.
This is really great for me to start learning about BA and Management ! Nice working!
One of THE BEST explanations I have ever seen. Thanks so much (Y)
What a great video. I went ahead and took a gander at the Manifesto! Pretty cool.
One of the best videos for Agile.
Agile is what we did before they came up with Traditional.
onaturalia Good point. Agile is the way I think most people that don't develop software assume that software development is done.
You mean chaos?
I think this is more suitable for the software consultants as for them, the "speed" at which a working software is delivered, is the most important thing.
Having said that, I mean a piece of software that JUST works!
In my experience, I have seen this approach introducing a certain ad-hoc-ism because every piece of software is designed for JUST the current requirement.
Sure this will result in a quick launch or completion of that requirement but as this particular requirement changes (now or later in time), this piece of software may not be flexible enough to cater the changed requirement or even another requirement which is very much related to it and/or dependent on it.
So for each requirement and for each change in one requirement, the piece of software has to be re-engineered and due to the "time" factor, it would also be a quick fix.
In that way it will soon become a dirty ball of mud. That may sound like a strong statement so let's say instead that at least(and according to what I have seen) it will soon have quite a large technical debt for the software developers who would be working on it in the later stages.
That is exactly what I was looking to understand. Thanks!
Agile is SO not what i thought. Good video. Thanks for the explanation.
Thanks for taking the time to comment. I'm very glad to hear it was helpful!
Agile: the way to develop software that nobody does but everyone says they do.
I agree that people who think Agile is something you do once and then are done are kind of missing the point, but there are teams out there that have done some incredible things by following Agile values and principles in the way they work.
Lol
This sure does sound like some corporate shenanigans
How so?
Beautiful!
At 1:12 is anybody else extremely bothered that the gears to the far left move in a contradicting rotation?
Good point. We have fired our background imagery physics consultant and will try to do better in the future. :)
@@MarkShead this is an under rated comment 😂😂
@@MarkShead Those responsible for sacking the people who have just been sacked have been sacked
I seriously don't get this explanation at all, actually I know less now than before I watched this. So what is agile besides 'values and principals'? Like how do you do it? Anyone else?
I am new but I learned through this video that how a team decides to be Agile is to use practices that support Agile Manifesto values & principles. Thus, it's through a team's decision-making process that a team becomes Agile. Does that help?
Brief and informative, many thanks
What a great video to add more layers of confusion to what is actually a very simple idea.
Simplicity is the art of maximizing the amount of work not done?? What?
Can someone explain
There are often many different ways a particular desired result can be achieved. Choosing the one that results in the least amount of work is the art of simplicity. Of course, that doesn't mean you take a shortcut today just to have to make up for it tomorrow--that isn't maximizing the amount of work not done. You want to look for ways to do exactly what is needed and no more in ways that maintain flexibility for other work that is not yet known.
It means take the least path of resistance towards your goal.
Very well explained, I'm going to share this with my team. I created a few videos using GoAnimate.com, love it.
Thanks to letting me know how to make animated videos... Earlier i used powtoons or scibe but thanks for goanimate...
best video to point out the essence of being agile also the common mistakes most organizations are making today
Thanks for your kind words. I'm glad you found it useful.
I watched the video and have absolutely no better understanding of agile than before.
So basically it's a made up thing that is an excuse for consultants to suck money out of developers by making them believe that this will help them in some undefined way.
No. Not at all. It is a set of values and principles that help teams do a better job of writing software mainly by increasing communication, transparency and making sure everyone is getting feedback quickly. Most projects can really benefit from those things. If those things won't benefit your project that is great, but you are definitely in the minority.
+ Mark Shead: So, you increase your workload in order to appease clients and other non-technical members of the your team whilst answering questions, justifying decisions and potentially making changes to 'interim' stop-gap solutions designed to make people feel better and involved - when really they are not.
+stsr11 If you were on a team that did what you described, they weren't doing Agile as none of that seems to be based on the Agile values and principles. I'm not saying that they didn't call it Agile, but that isn't how teams operate if they are following the principles outlined in this video.
@Daniel Hann
> Thats some spurious logic.
My logic is the logic behind this video. The Agile Manifesto defines a set of values and principles. If you are taking actions that, in your particular situation, cause you to run counter to the values and principles, then you aren't actually following the values and principles. You are doing something different.
Now there are all kinds of people marketing practices and methods that they say will help your organization follow the values and principles, but whether those are or not depends on what you actually do as an organization. If an organization prioritizes frequent releases in a way that makes the workload unsustainable, then they aren't following what the Agile Manifesto is suggesting.
So my logic is this. If A is well defined and you try to achieve A by taking actions B, but in taking those actions you do ¬A, you can't complain that A doesn't define something that is useful. The problem is when people start setting things up to say B → A. And this is what I think is most powerful about the Agile Manifesto is that it doesn't assume that the same thing is going to work for each team. Is it a good idea to use Scrum? Maybe. Maybe not. It depends on what results the team gets. Does it let them do things at a sustainable pace and deliver more frequently than before? Does it help them better follow the other values and principles? If so then it might be a good thing for that particular team at that particular point in time, but it doesn't mean it is the right choice for every team, more does it mean it is always going to be the best thing for that team forever.
I'm not saying anything new here. This is all in the same spirit as Dave Thomas' "Agile is Dead - Long Live Agility" article.
at 7:50 that is so wrong for the dev to make that decision. its the start of the band aid approach for this product.
I believe this is what you are referring to:
[quote from video]
Or consider a developer who is working on implementing a feature for the business owner. The developer realizes he needs a database to make the feature work. The first idea that comes to mind is to stop work on the feature and build out a robust database layer that will handle the needs of the feature and provide support for other development that will be needed later. If the developer believes in the Agile values and is trying to follow Agile principles they would think:
“But building out this layer means I will have to delay delivering what the customer can see as valuable software they can use. If I can find a way to build just what is necessary to deliver this feature, it will better align with my principles.”
[end quote from video]
The approach in the video says that the developer should build just the parts of the database layer that are necessary to give the customer the feature that is being created with the understanding that over time the database layer will evolve as new features are added. This type of approach follows the Agile principle of prioritizing the creation of software that the business owner can actually use. For example, if the developer only needs two objects for the feature, they don't need to try to build out the entire object graph for other features that aren't yet being built.
As stated in the video, the opposite of that approach would be to build parts of the database layer that *aren't* needed for the story to support what the developer *thinks* will be necessary for the future. For example, a developer might try to build out other entities that are not needed for the current feature. Such an approach necessarily prioritizes something other than the creation of usable software and violates the 3rd and 7th Agile principles.
It isn't that you can't create software that works by building out layer by layer, but following Agile principles pushes you to create software feature by feature like slices of cake that cut through all the different layers of the code rather than one layer at a time.
Mark Shead i certainly see your point. but it raises to concerns.
1. if this decision is made by the developer then they may not be aware that the database layer is already under way by a second sprint team and would be doubling up on work.
2. Usually a developer would have access to only building this layer on their own environment and the overall project has the requirement for a thorough implementation for future dependencies which the project manager or architect has already planned for. therefore it becomes its own seperate part of the solution which needs to be reworked at a later stage to be included in the overall relational data layer.
I understand your concerns, but keep in mind we are talking about working on an actual Agile team here that is following Agile principles.
Wouldn't your first concern only occur if you have a team that is violating Agile principles 2, 4, 6 and 11. How would a project that is setup to handle changing requirements, working together face to face every day, and designing the architecture together as a group not know what each other are working on? If that did happen once, wouldn't they adjust and fix it the first time it happened according to principle 12?
In the same way, I don't see how your second concern would be an issue unless you have a team ignoring Agile principles 1, 3, 4, 5, 6, probably 7, 9, 10, and 11. Probably 12 too.
0/10 nice principles but no application IRL
Preston Garno Having recently completed a project that was originally quoted at $50 million but we delivered for $15 million using these principles, my experience is obviously different than yours. Do you usually find that teams are already following these principles so they aren't needed or do you not see any evidence of benefit when a team decides to follow them.
In 10:00 I fully agree but as you know scrum us all or nothing, and loves its rituals. And when it does not work, hire a consultant. I hope they get one like you that still can see clearly. Lovely video.
Great introduction to Agile Mark. Thank you.
Thank you for taking the time to comment! I appreciate hearing that you liked it.
Is Agile ONLY relevant to software?!
Great question! The Agile values and principles specifically talk about delivering software, but it isn't hard to adapt them to other types of work. The idea of delivering something to the customer on a regular basis works with a lot of knowledge type work. It is probably going to look a lot different if you are trying to apply the Agile principles to something like skyscraper construction.
Mark, thanks so much for getting back to me, I am currently studying for the PMP exam, as I need to expand my knowledge as a PM, but I am in NY, and want to apply this to product related items much smaller than skyscrapers (I wish). So for example, for someone who oversees portfolios of programs and projects, will this apply? So far the PMBOK seems to be OK, bit redundant, but I am just wondering if I am wasting my time with PMI? I really appreciate any feedback, it's so hard to get straight answers sometimes!
Agile is an adjective, not a noun.
Excellent job! Very good explanation. Thank you!
A great description of the foundation upon which agile practices rest. Periodic review of this video is recommended :-)
Ramki Krishnan thanks for your kind words.
Hi! This is wrong.
Normally I never found a totally right answer to the question "what is Agile?"
The problem IS the question, agile is not a "what".
I could say this is the best "approach" (great work!) I've seen to understand Agile, and it could be useful for people to get started.
Let me contribute a slightly gap for the readers.
Those who blame Agile as a "smoke selling business" are right. There is a billionaire business of smoke selling under the name of "Agile". Many people thinked that Agile was a Fashion and I always disagreed. Nowadays I agree.
But between all this salat of certification sellers, consultants, sceptics, confused and entusiastics hooligans there is an authentic agilism.
For example: "making each decision based on the principles and values that the team has decided to follow"
1. We should not confuse Meanings with Endings. Agile should not be the End, the goal. In an Agile CULTURE everything trends to be Business Value oriented, not Agile oriented. Decisions should be goal oriented inside the constraints of principles and accordingly to the values.
2. If you are choosing an Agile strategy (is not the only one) for your social development, then the team is not deciding to follow other principles. (Maybe here I'm lost)
3. You approach the decisions level, that's great. And under decision you have still more levels to explore and there you are more near the core of Agile. Behind decisions you have behaviour, believes and philosophy. That's why a Dinosaur-manager finds so hard to adapt to these Agile-post-ice-age era.
At the end: I agree with all of you and I hope to contribute to your comprehension.
Agile regards
Daniel Ceillan
Can I do 100 thumbs up please?
Ha ha! I wish you could. You can do something better though. Please pass the video on to any of your friends who you think might benefit. And don't forget to check out our other videos! Thanks!
Precious! :D Excellent, refreshing and entertaining intro. to the subject. Thank you Mark.
Awesome! Love it. Thank you.
seems kinda culty
Chase Moon Which principles seem "culty" to you?
-it has the word manifesto 😂👌-
Jokes aside, Chase is probably talking about how *highly regarded*, (and misused) "Agile" workflows are in SMEs?? And also, how Agile would only work with the right team, something, something, culture fit, something, something, cookie cutter solution
Cult -
"a person or thing that is popular or fashionable among a particular group or section of society."
Oh I understand how a lot of the ways Agile gets implemented is a total mess, but the purpose of this video was to point out what Agile actually says it is...not what people try to sell it as. The actual principles seem more like common sense of how to get work done efficiently when creating software.
Is SCIENCE a cult? Agile provides basic values and principles that guide an approach to developing software. Science does the same thing. In fact, Agile encourages Empirical Process Control, which is a scientific method. Observe what is happening. Gather data. Formulate a hypothesis about what is happening and how to improve the results. Run an experiment to see if the proposed changes worked. Gather data, analyze, and make further decisions/experiments.Agile does NOT promote adoration of individuals or cult leaders. So your comment is baseless. Thank you for playing, however.
Quico Reed agile is mind control for the average-lousy developers that would ruin your project much faster otherwise
Pick up the pace, man. Great content, but the delivery is very very very... dull. Thanks for the info!
Thanks for the feedback. I tried to speed things up in subsequent videos. How do you feel about the pace of this one: ua-cam.com/video/apOvF9NVguA/v-deo.html
Much better!
People should really stop complaining about slow pacing on UA-cam videos. There is a speed feature built into the UA-cam player for this very reason. Use it!
Arvindh Mani Wrong.
Arvindh Mani well I appreciated the feedback so I can try to improve future videos.
I'm also called Mark, like your character there. I'm also as animated and excited about Agile as he is.
The teeth of the gears do not match and it is driving me crazy!
The whole meaning of a gear illustration is being lost and that makes me angry!
sorry but you won my dislike, the 4° of my life in UA-cam.
Thanks. We have fired our physics consultant for this video so hopefully you'll see improved quality on the newer ones. :)
Sincerely thank you for such a well-put explanation. Personally for me, it has been a great introduction to this topic! I am moving on to the other videos you have shared, thanks!
Liked the video and clarity of presentation and concept, thanks
Excellent work.
Well done. Thank you for this easy to understand explanation of Agile.
Brian Baldos Thank you! I appreciate you taking the time to comment. Please pass the video on to anyone you know who might find it useful.
Well explained! Thank you bro. :)