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.
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.
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.
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!
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.
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.
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.
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.
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.
Literally just began learning about agile. Want to confirm some things. 1) If agile is a set of values and principles, does that mean corporations like Amazon and it's 12 leadership principles, and ByteDance's ByteStyles is considered agile? 2) I'm learning this from marketing class, and agile seems more like stuff for managing a company...so what does that have to do with me?
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
So what is Agile? The set of values and principles. The term agile applies not only for the software development but for all walks of life. Agile is not the one set of methodology. It's not one specific way of doing your work. Agile is all about how flexible you are in your set of values and principles. How do you respond to change? How you produce more and better by following certain principles or guidelines. It's all your internal and it may vary from time to time as there is the margin of improvement in all agile principles.
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.
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
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.
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 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.
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/
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
@@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?
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?
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.
@@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?
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.
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
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.
After COVID-19 pandemic, some of the Agile principles have been changed, no face to face meeting, if really required face to face then face mask must and keep 2-meter distance further principles are in progress so stay tuned!
The principles say that the most effective way to communicate to and within a development team is face-to-face. I don't see any evidence that this is no longer the most effective way to communicate in a way that changes the principle. As always, your current circumstances may dictate how you are able to follow the principle. Many teams have found that good video conferencing lets them get many of the advantages of face-to-face communication even when not everyone can be in the same room. I think unmasked high quality video where everyone can see each other's faces is probably going to be more effective than in person masked communication.
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!
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.
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.
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.
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.
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 set of Values and Principles which is used to deliver a most dynamic software. At the same time agile helps you come across more dynamic ideas which push’s you to implement it for better performance, however this will delay the project delivery. How are we fixing it? How is Agile helping in timely delivery of the project? Is it not the primary concept of Agile? Please help explain?
> this will delay the project delivery When a team starts trying to follow Agile principles and values, you may see delivery slow for a time while everyone figures out how to work together. However, once you have a mature Agile team the velocity at which they can deliver value is much higher than what they would be able to do under a waterfall development process. For example, a recent project I helped coach was a rewrite of an existing system that had been using waterfall. Under the old system, it would take 6 months for a change to be deployed to production where it was providing value. Using Agile values and principles the rewrite ended up with a process that could deploy a change in a matter of hours. One day the business owners found a simple change they wanted to make to the system. It was a very simple change--only a few lines of code. Under the old process, this would have taken 6 months to deploy. With the new process, they had the changes into production within a week and captured $5 million in value that would have been lost waiting for the change to make its way through the old waterfall process. Another important thing to keep in mind is that projects that are actually following Agile should be measuring completion based on getting working software into production. This means they may look like they are going slower at the beginning compared to a project that is saving all of the deployment cost/risk until the end. I've seen waterfall projects look like they were on time until they get to 95% and then be canceled when management finally figured out that despite having created many lines of code, the project was still a very long ways from delivering useful value. Agile can help keep those types of situations from happening. Does that help answer your question?
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
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.
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.
Thanks for your comment. I'd love to get your feedback on these follow on videos: th-cam.com/video/EDT0HMtDwYI/w-d-xo.html th-cam.com/video/apOvF9NVguA/w-d-xo.html
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
Very helpful. My Boss wants us to work agile. This Video is a great introduction and easy to understand. The animations are great and so you don't get bored. Thank you very much!
Could the thumps-down people's comments be filtered to the SORT BY - so that it could be judged for - "what reason" - they gave IT, for a fantastic work.. I think youtube should think of adding enough filters
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 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.
Instead of building out the entire data access layer, an Agile developer would build just the pieces they need for the specific function they are creating. So even if they know they are going to eventually need 100 tables, they would just build the 3 they need for this feature.
Thanks you for the video. I still cannot see Agile clear. As I am coming from LEAN, Green Belt and ITIL Methodologies. For IT SD Management is almost impossible to use Agile. The 8th principle is not totally clear. After the video, i get the idea that Agile is more like a belief. Many of the mentioned points are coming from people and Project management. I cannot see how Agile can be vital to become cross departmental. I can only connect it to Software production.
Well the Agile Manifesto is specifically about how to create software, so it makes sense that it is connected to the production of software. I think of the 8th principle as placing constraints or guidance on the other principles. It says that if you are doing things that are unsustainable, you aren't following Agile. So if you deliver rapidly by making people work 120 hours a week, you aren't actually following the Agile principles.
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 TH-cam.
Thanks for the feedback. I tried to speed things up in subsequent videos. How do you feel about the pace of this one: th-cam.com/video/apOvF9NVguA/w-d-xo.html
People should really stop complaining about slow pacing on TH-cam videos. There is a speed feature built into the TH-cam player for this very reason. Use it!
Principles - 1: The highest priority is to satisfy the customer through fast and continuous software delivery (micro deliveries = micro results) - 2: Changes of requirements are welcomed even at the end of development. Agile processes take advantage of change as a competitive advantage for the customer. - 3: Prioritize weekly or biweekly, or monthly delivery. Prioritize shorter time scales. (set a frequency of deliveries) - 4: Business people and developers should work together daily throughout the project. - 5: Build projects around motivated individuals. Provide the right environment and support your needs, trust them to get the job done. - 6: Prioritize face-to-face communication. - 7: Working software is the main measure of progress. - 8: Agile Manifesto promotes sustainable development - Sponsors, Developers and users should be able to maintain a constant pace at all times - 9: Continuous attention to technical excellence and good design increases agility. - 10: Simplicity - the art of maximizing the amount of work not done - is essential (Less is More) - 11: The best architectures, requirements and projects emerge from self-organised teams. - 12: At regular intervals, the team reflects on how to become more effective, then tunes and adjusts their behavior accordingly. (Retrospective / Behavior adjustment)
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? 😅
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
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.
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.
Probably best explanation of Agile. Now I know I don't need agile.
As a non-English speakers, Thank you for the subs
"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.
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
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.
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
Nice video - "Agile is a set of beliefs (values & principles) on how to make decisions ...."
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.
A term I have struggled to understand, explained so plainly right here..
Best Explanation Ever
I'm glad the video helped. What time were you struggling with?
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.
Thank you for this. This is a great springboard for understanding and implementing agile.
Probably the best and the most simply explained video that I have ever seen. Thank You Mark.
This is a wonderful brief description of Agile Values and Principals. Thanks
"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 .
This video helps me get an accurate view of agile, thank you from a bottom of my heart.
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.
Literally just began learning about agile. Want to confirm some things.
1) If agile is a set of values and principles, does that mean corporations like Amazon and it's 12 leadership principles, and ByteDance's ByteStyles is considered agile?
2) I'm learning this from marketing class, and agile seems more like stuff for managing a company...so what does that have to do with me?
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 th-cam.com/video/0wNucF6_4Os/w-d-xo.html
What a great video to add more layers of confusion to what is actually a very simple idea.
Could not get better than this. Amazing job.
So what is Agile?
The set of values and principles. The term agile applies not only for the software development but for all walks of life.
Agile is not the one set of methodology. It's not one specific way of doing your work.
Agile is all about how flexible you are in your set of values and principles. How do you respond to change? How you produce more and better by following certain principles or guidelines. It's all your internal and it may vary from time to time as there is the margin of improvement in all agile principles.
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
The best video to understand Agile. Keep up the good work.
Thank you. I'm glad you found it useful.
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
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/
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.
Thank you for this useful introduction to the concept of Agile
"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?
Great video, I find it very relatable and so easy to understand. Thanks.
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?
Great videoo....well explained and visualized. Thanks!
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?
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.
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
Brilliant! What a clear and interesting video! Thank you for this!
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.
After COVID-19 pandemic, some of the Agile principles have been changed, no face to face meeting, if really required face to face then face mask must and keep 2-meter distance further principles are in progress so stay tuned!
The principles say that the most effective way to communicate to and within a development team is face-to-face. I don't see any evidence that this is no longer the most effective way to communicate in a way that changes the principle. As always, your current circumstances may dictate how you are able to follow the principle. Many teams have found that good video conferencing lets them get many of the advantages of face-to-face communication even when not everyone can be in the same room. I think unmasked high quality video where everyone can see each other's faces is probably going to be more effective than in person masked communication.
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
Trustworth Video! I love especially the simple title! I now have an overview of how Agile works. Cheers
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.
Great video... not sure why it has 1k of dislikes but I gave it a thumbs up!
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?
One of THE BEST explanations I have ever seen. Thanks so much (Y)
I watched the video and have absolutely no better understanding of agile than before.
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?
What a great video. I went ahead and took a gander at the Manifesto! Pretty cool.
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.
I just got clear complete understanding of agile and ended up subscribing to your channel. Thanks for creating such valuable content.
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.
Is there any place where your cheatsheets are stored? Unfortunately the old links from email's subscriptions aren't working any more :/
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'
You speak really clearly and slowly enough to understand. Thanks for that
Thank you. Many people felt I was speaking too slowly, so it is good to hear it was helpful.
@@MarkShead 😊😊
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.
This is my go to.
Your videos are short, fun and easy to comprehend
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.
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!
Wonderful. Thanks for making the video and sharing your thoughts!
best video of what Agile really is that i've heard so far...good job Mark
Thank you! I'd love to get your feedback on some of my other videos as well.
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 set of Values and Principles which is used to deliver a most dynamic software. At the same time agile helps you come across more dynamic ideas which push’s you to implement it for better performance, however this will delay the project delivery. How are we fixing it? How is Agile helping in timely delivery of the project? Is it not the primary concept of Agile? Please help explain?
> this will delay the project delivery
When a team starts trying to follow Agile principles and values, you may see delivery slow for a time while everyone figures out how to work together. However, once you have a mature Agile team the velocity at which they can deliver value is much higher than what they would be able to do under a waterfall development process. For example, a recent project I helped coach was a rewrite of an existing system that had been using waterfall. Under the old system, it would take 6 months for a change to be deployed to production where it was providing value. Using Agile values and principles the rewrite ended up with a process that could deploy a change in a matter of hours. One day the business owners found a simple change they wanted to make to the system. It was a very simple change--only a few lines of code. Under the old process, this would have taken 6 months to deploy. With the new process, they had the changes into production within a week and captured $5 million in value that would have been lost waiting for the change to make its way through the old waterfall process.
Another important thing to keep in mind is that projects that are actually following Agile should be measuring completion based on getting working software into production. This means they may look like they are going slower at the beginning compared to a project that is saving all of the deployment cost/risk until the end. I've seen waterfall projects look like they were on time until they get to 95% and then be canceled when management finally figured out that despite having created many lines of code, the project was still a very long ways from delivering useful value. Agile can help keep those types of situations from happening.
Does that help answer your question?
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
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...
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.
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.
Extremely helpful. Do upload more content :)
Liked the video and clarity of presentation and concept, thanks
Perfect Explanation !!!
Thank you very much, was really confuse to understand what is it? for what is it?
excellent explanation of methodology!
"Agile isn't a methodology"! @1:10 ;)
it isn't a methodology thou :)
Yes, best way to explain what Agile is!
Thanks for your comment. I'd love to get your feedback on these follow on videos:
th-cam.com/video/EDT0HMtDwYI/w-d-xo.html
th-cam.com/video/apOvF9NVguA/w-d-xo.html
Agile is an adjective, not a noun.
Very interesting video and interesting way of explaining the Agile approach.
Explained very clearly. Thank you :-)
Excellent job! Very good explanation. Thank you!
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
Thanks Mark Shead, whew... Thanks really for putting this masterpiece together in clear and detailed concepts
This is really great for me to start learning about BA and Management ! Nice working!
Very helpful. My Boss wants us to work agile. This Video is a great introduction and easy to understand. The animations are great and so you don't get bored. Thank you very much!
I found this one more helpful and current th-cam.com/video/cCGzddDtQ38/w-d-xo.html&ab_channel=VibhorChandel
Vibhor Chandel has created a whole series on how to pitch Agile to Executives, I love it.
Thank you for this informative video.
Pawan Joshi Agile Network Short and well detailed presentation th-cam.com/video/0wNucF6_4Os/w-d-xo.html
One of the best videos for Agile.
This sure does sound like some corporate shenanigans
How so?
Could the thumps-down people's comments be filtered to the SORT BY - so that it could be judged for - "what reason" - they gave IT, for a fantastic work.. I think youtube should think of adding enough filters
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.
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.
I swear to god i thought agile is a programming tool...
Awesome! Love it. Thank you.
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
So what did the developer use in place of a database? What is the cost of the technical debt?
Instead of building out the entire data access layer, an Agile developer would build just the pieces they need for the specific function they are creating. So even if they know they are going to eventually need 100 tables, they would just build the 3 they need for this feature.
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...
Thanks you for the video. I still cannot see Agile clear. As I am coming from LEAN, Green Belt and ITIL Methodologies. For IT SD Management is almost impossible to use Agile. The 8th principle is not totally clear. After the video, i get the idea that Agile is more like a belief. Many of the mentioned points are coming from people and Project management. I cannot see how Agile can be vital to become cross departmental. I can only connect it to Software production.
Well the Agile Manifesto is specifically about how to create software, so it makes sense that it is connected to the production of software.
I think of the 8th principle as placing constraints or guidance on the other principles. It says that if you are doing things that are unsustainable, you aren't following Agile. So if you deliver rapidly by making people work 120 hours a week, you aren't actually following the Agile principles.
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 TH-cam.
Thanks. We have fired our physics consultant for this video so hopefully you'll see improved quality on the newer ones. :)
Well explained . Subscribed. Agile explanation ;)
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: th-cam.com/video/apOvF9NVguA/w-d-xo.html
Much better!
People should really stop complaining about slow pacing on TH-cam videos. There is a speed feature built into the TH-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.
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.
Principles
- 1: The highest priority is to satisfy the customer through fast and continuous software delivery (micro deliveries = micro results)
- 2: Changes of requirements are welcomed even at the end of development. Agile processes take advantage of change as a competitive advantage for the customer.
- 3: Prioritize weekly or biweekly, or monthly delivery. Prioritize shorter time scales. (set a frequency of deliveries)
- 4: Business people and developers should work together daily throughout the project.
- 5: Build projects around motivated individuals. Provide the right environment and support your needs, trust them to get the job done.
- 6: Prioritize face-to-face communication.
- 7: Working software is the main measure of progress.
- 8: Agile Manifesto promotes sustainable development - Sponsors, Developers and users should be able to maintain a constant pace at all times
- 9: Continuous attention to technical excellence and good design increases agility.
- 10: Simplicity - the art of maximizing the amount of work not done - is essential (Less is More)
- 11: The best architectures, requirements and projects emerge from self-organised teams.
- 12: At regular intervals, the team reflects on how to become more effective, then tunes and adjusts their behavior accordingly. (Retrospective / Behavior adjustment)