What is Agile?

Hi I’m Mark. I help organizations write
software more efficiently and often this means helping teams understand what it means to
develop in an Agile way. In this video we are going to answer the question, “What
is Agile?” And just as important we’ll discuss what Agile is not.
Many things get called Agile—especially by people who are selling something. If you
ask the makers of paper products, they will tell you that to be Agile you need to write
user stories on the sticky note cards— that they just happen to sell. If you ask a consultant,
you’ll likely hear that it is a methodology for developing software that your organization
can learn—if you buy their services. And if you talk to the makers of orthopedic shoes,
you’ll be told that the key to being Agile is meetings where everyone stands up. So the
more comfortable your shoes — the more Agile your team.
The actual definition of Agile is found in the Agile Manifesto. The Manifesto makes it
clear that Agile isn’t a methodology. It isn’t a specific way of doing software development.
It isn’t a framework or a process. In fact, most of the things that are marketed as Agile
tend to miss the point of what Agile actually is. Agile is a set of values and principles. Much of the discussion around Agile has to
do with following different practices, using various methodologies, and even developing
with specific tools. While these things might help a team that is trying to follow Agile,
they aren’t Agile in and of themselves. For example, while a team may find that having
a daily standup is helpful, the standup is only “Agile” to the extent that it is
the result of a team following the Agile principles and values.
When you understand this, it is easy to see that Agile is really a collection of beliefs
that teams can use for making decisions about how to do the work of developing software.
While this means the term Agile gets subjected to a great deal of abuse when people claim
that this or that is the way to be Agile, it also means that if you truly understand
what Agile is, it is surprisingly flexible. Agile doesn’t make decisions for you. Instead
it gives a foundation for teams to make decisions that result in better software development. The Agile Manifesto is only 68 words and very
simply says that we can develop software better by valuing the items on the left side of the
list more than the items on the right side. This is the Agile Manifesto says: We are uncovering better ways of developing
software by doing it and helping others do it. Through this work we have come to value:
• Individuals and interactions over processes and tools
• Working software over comprehensive documentation • Customer collaboration over contract negotiation
• Responding to change over following a plan
That is, while there is value in the items on the right, we value the items on the left
more. In addition to the values of the Manifesto
there are 12 principles that support the values. Once again the principles are very general
and are less about telling you what to do than they are about giving you the ability
to make a good decision in a particular situation. The principles are: 1. Our 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 the 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, then tunes and adjusts its behavior accordingly. Since Agile is a collection of values and
principles, it’s really utility is in giving people a common foundation for making decisions
about the best way to develop software. For example, consider a new project that is in
discussion on how to get the requirements from the business owner. The suggested approach
is to require that the business owner write down all the requirements and sign off on
them before beginning the work. A team that is following Agile would say:
“While that might work, isn’t that inconsistent with our belief that we should value customer
collaboration over contract negotiation? And doesn’t it violate our principle that says
the developers should be working with the business owners every day? How can we make
this decision in a way that is consistent with our values and the principles we follow?”
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.” When you have a team that is following Agile
they will be making hundreds of decisions each week in the way described above. That
is what it means to be Agile. Making each decision based on the principles and values
that the team has decided to follow. The decision making process matters. You can’t
try to short circuit things by taking decisions made by another team and just blindly doing
what they decided to do. Another team may make decisions based on the Agile principles
and values and end up with a particular way of doing their work. Simply trying to mimic
another team’s actions and practices won’t make your team Agile.
After World War II Melanesian islanders were observed trying to bring cargo planes and
their supplies from the sky by mimicking the practices they had seen performed during the
war. This included clearing the forest to make a landing strip complete with full size
planes made out of straw. They also created structures that mimicked a control tower out
of bamboo and had someone sit in it wearing headphones fashioned from coconuts.
It is easy to fall into a similar type of cargo cult mentality when it comes to Agile.
The things that are easy to notice in a highly functional Agile team are the practices they
are using. But the practices a team uses is the result of following Agile principles and
values. It is less important what practices a team happens to be using than why they are
using it. In fact, as time goes by, a good Agile team is probably going to change and
refine the practices they use. A team might start with SCRUM and later find
that Kanban is a better fit for delivering value to their customers. A team might begin
standing up in a daily meeting and later decide it works better for everyone to stay sitting
down. Another team might start out using Planning Poker to estimate story size and later do
away with story points and simply split stories to be approximately the same size.
That isn’t to say it is useless to look at practices being used by teams that are
performing well, but you can’t go looking for practices to make you Agile. Your principles
and values are what will make you Agile. You have to look for practices that support your
principles and values. The way you select your practices is what determines whether
you are being Agile or not. If a practice is being selected because it looks like a
good way to follow Agile principles, it is probably a good place to start. The same practice
can work poorly for a team if it is selected for the wrong reason. So what is Agile?
Agile is a set of values and principles. How does a team become Agile?
They make their decisions based on Agile values and principles. The decision making process is how a team
becomes Agile. The values and principles have enough flexibility to allow teams in a wide
variety of organizations to develop software in the ways that work best for their particular
situation while providing enough direction to help a team continually move toward their
full potential.

, , , , , ,

Post navigation

100 thoughts on “What is Agile?

  1. its a stupid terminology that means nothing !!!
    It is a retarded concept with no practical application.
    it is like asking what is air !

  2. 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.

  3. Anyone else getting somewhat tilted by the fact that those gears in the background do not line up perfectly? :/ Its is grinding my gears :O (hehe I just did that)

  4. 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.

  5. Before watching the video I knew nothing about Agile and after watching it I still don't know much. Agile sounds like an imaginary fake solution but maybe I just need to dig deeper. Mark – the content may be informative but you seriously need to develop some energy and speed up the process. I watched it at 1,75 speed and nearly fell asleep anyway 😀

  6. 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.

  7. In my experience here are the two large problems with Agile if you go strictly by these 12 rules:

    1) 1 and 2 come into conflict with 3 and 7.

    If you are building a car and say we will install the engine today, the exhaust and cooling system tomorrow, the brakes and struts two days later that is fine. If the business comes in and says we want ot change out from 6 cylinder engine to an 8 cylinder engine you get a cascade impact. Can the mounts support the larger engine? Can the brakes and struts hold up and what are the wear impacts with a heavier and more powerful engine? Can the exhaust and cooling systems keep the larger engine in safe ranges?

    2) The other problem is documentation is still important. If you go back to modify or fix a business gap you save time and money if it is well documented. Why that decision was made? Why did we choose not to implement that in the design so we don't waste time discussing it again.

  8. 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.

  9. The problem with values and principles, or any set of rules, is that people often get lazy and over reliant on them, and don't bother doing their own thinking.

    Context is important. Not every software project can ever be the same, no project of any kind probably. In different sectors, some of these principles would not invariably have positive effects.

    Infrastructure projects for example require much more planning. The consequence of bad infrastructure can be a dam breaking or a power distribution line built on terrain at risk of landslides.

    Getting software a little bit wrong… is bad, but usually not catastrophic. That's not true for everything though.

    I really like the video though. Very clear.

  10. Finally someone gets it. I am soo anoyed by consultants coming and dogmatically squashing practices calling it a method scrum claiming it agile transformation and wondering why its not working. Mostly 25 yo mba kids with no experience in software whatsoever bullshitting entire companies.

  11. Dude, it is a methodology. The "set of principles" thing just wraps all the Agile into a spiritual cult atmosphere…

  12. Agile is like the guy in the cartoon, half awake, had some pot, you boooo on it would die of hearth attack. Agile is an invented term and freaking methodologies to hide the incompetence, the incapacity to articulate, define, scope, plan, envision, and control a project as a whole from the beginning to the end.

  13. I was in talks with someone about a job.
    I told her I am using a variation of Kanban at my current work-place, evolved to fit our needs and that I value more having a structure that fits our team, more than knowing what that structure is called.
    The talks ended with "We need someone with more background in Agile".
    I suspected she was either an idiot or B.S.-ing me.

  14. Sorry to tell you but this is not Agile, I have been working in Agile last 5 years and this video is to abstract and general.
    There ARE roles, responsibilities, timeframes, principles and metrics. And please no "Yes but…", I'm talking from my own experience not a manifesto 🙂

  15. I have worked with big successful companies and mid sized ok type companies. The former ones do not use Agile while the latter ones do. When I hear from other engineers about their use (or non use) of Agile their company size and status really match my observation. The whole standup thing and sticky notes stuff looks and feels dumb and in some cases even funny. Also in most cases Agile is actually used for micromanaging people. I have never liked working at these small and midsized companies which are usually not very successful. And since these companies experiment with Agile a lot, it makes it very easy to tell them apart. So any young engineers out there can use this info to see if they are applying or working for a successful company or not!

  16. "Agile" is a big pile of marketing bullsh_t, which is endlessly spewed from knuckle-dragging "managers", "pm"'s, and every other know-nothing moron. It is pure garbage.

  17. Who here is an enterprise application developer that has worked on long term agile projects that actually agree with this video.

  18. 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.

  19. If you're going to Agile us into working more efficiently, are you going to also make our pay reflect this increase in efficiency? If you don't, we walk 🙂 any managers reading; remember that.

  20. I've heard modern 'agile' is about overworking your low-level employees until they fucking kill themselves. The way you describe it seems nebulous and useless. I literally learned nothing. You can interpret this crap any number of ways. Agile has wasted enough of my time, please fuck off.

  21. Great and easy to understand video 👍🏼
    Also wanted to ask – how do you create such animated videos with an avatar. Are there any tools we can use?

  22. felicitaciones excelente explicacion al nivel de las mejores universidades solo le pido que por favor le ponga los subtitulos de traduccion al español a sus demas videos. los que somos sud americanos y latinoamericanos le estaremos muy agradecidos.

  23. congratulations excellent explanation at the level of the best universities I only ask you to please put subtitles of translation into Spanish to your other videos. those of us who are South Americans and Latin Americans will be very grateful.

  24. So much mouth noise. Good content but I admittedly couldn't finish watching. Like listening to someone eating with their mouth open. This is an old video, I hope you were able to address this for your other stuff.

  25. Hi Mark, thank you for taking the time and effort to make the video. For most of my career I’ve worked as the conduit between the customer/business and the Developers (Business Analyst (BA) / Pre-Sales Engineer and number of other guises that are essentially the same thing). I’ve always worked in models that are closer to the waterfall model (not necessarily in absolute terms), hence why I’m here to understand the agile principals that effect resulting methodologies based off those principals.

    There are is a lot in this video that directly contradicts my experience, and I was hoping you could help me understand the real world impact of some of these principals which at present I can’t understand how they could work.

    For simplicity purposes I have focused on the 2 examples given in the video. Let’s use an example of a different commenter – that your company operates in a B2B environment, and develops and implements an ERP.

    Examples given in the video:

    1.Consider a new project that is in discussion (get requirements and sign off first ) vs (customer collaboration + developer should work with business owner every day)

    2.Developer that is implementing a feature for a business owner. Developer needs a DB to make the feature work (build out a robust DB layer that will handle the need of the feature and support for other work that will be needed later) vs (Don’t delay delivering valuable software and built just what is necessary to deliver this feature)

    My Take:

    1.Ultimately speaking in designing a contract, it is based off what time and effort it will actually take to design, develop, test and deliver the software (although other factors such as value can come into too). There is clarity on what will be delivered and for how much. By giving scope for the customer to constantly make changes, how can a business expect to make a profit? They will constantly have to make changes which will quickly erode the profit margin – who is paying for these iterations? The customer? Are they really going to pay thousands of euro/dollars just to essentially test new features that may meet their need or not?

    a)It appears this agile principal to me at least (maybe you’ll change my mind on this), is a response to compensate for a poorly thought out solution in the design phase, some examples to how this can occur:

    i.Listening to the customers interpretation of the solution. It is the BAs responsibility to determine what the actual need is and to develop a solution to meet this need. This means there should not be a scenario where you constantly re-design a feature after its release, because it was designed correctly in the first place.

    ii.The solution doesn’t meet the whole business need. It is the responsibility of the BA to understand the need in it’s entirety constantly asking questions to challenge any assumptions made. The discussion should include the end-to-end process and what impact it has on other areas. It is the BAs responsibility to be the technical expert in this area, and to think things all the way though, not the customer's responsibility.

    iii.The customer was expecting something that wasn’t delivered. It is the BAs responsibility to tightly define the specification, such that things aren’t open to interpenetration. All the needs of the customer should be addressed in the design phase, and non-cost effective solutions weeded out.

    2.To design, develop, test and release takes time which ultimately costs money, redesigning solutions cost even more. There are usually implications else where in the project. Who is paying for the design, development and testing of a solution which will be later removed (even more time)? The customer? Are you going to be honest with them and tell them, it will cost a few extra thousand because we thought it would make you happy? Do you honestly think they will be happy? In my view the developer should absolutely work on the “robust DB layer” that will ultimately solve this problem to the deliver the current feature, and support future features that are aligned with the overall project goals. Why? Because it is the most cost effective solution to the overall project. The only scenario in my view where this agile suggestion could work, is if the feature being live earlier adds more value than waiting + the cost involved for delivering and removing a temporary solution. This can only be established though an honest and direct conversation, highlighting the pros, cons and costs involved and getting agreement up front.

    Now I’m not saying features that are complete and don’t effect other areas of the project can’t be released earlier, of course they can. What I am saying is the overall scope of the project should be tightly defined to address the customers actual needs in their entirety, there needs to be transparency on where the time is being spent (directly correlated with what the customer is paying), and efficient and smart design decisions are made to meet the overall project goals in the simplest, quickest and most cost effective manner.
    This may include a phased delivery approach, to allow the customer get value earlier in the process.

    To me it appears that the agile principals don’t encompass the fact that projects have to close, and time and effort costs money, which someone has to pay.
    (although I'm open to changing this view based off your answers.)

    There is a situation I can see where the agile principals could work, that in a B2C environment or even B2B (where you have a business willing to be essentially a test case) where you don’t actually have a product, nor do you know what the product might look like. Instead you constantly send out new features, evaluate if there is an uptake on them and them and keep the ones that work and remove the ones that don’t. I’m thinking of something like bourbon before it became Instagram. For established products, I’m not sure how, these could work. Maybe you can help?

  26. always refuse a Agile&Waterfal PM position

    – because their lack of planning and organization will become your priority everyday of the week

    – because the usual lack of product ownership, will make you the PM AND the Product Owner too

    – because you have no authority over large groups responsible for Product development and testing as a PM

    – the lack of responsibility required by a true Agile organization will make you over responsible and utterly underpaid as a PM & product owner

    – last but no least: while your managers get paid, you don't and … you will wear too many hats with too many responsibilities and complete lack of control/leverage
    – cherry on top: if you don't deliver and just lick waterfall artifacts – you are not Agile. if you deliver and you are Agile, you have not filled in your artifacts

    They want control but with delivery – this is a never ending quest for access while secure. Basically you are painted as a victim and played like a violin.

    Enjoy !

  27. Can someone please help me with the 11th principle of agile? I am having a hard time understanding how maximising work not done is a good thing?

  28. Hey Mark, first off: great video, it's plenty insightful, so thank you!
    I've a question about when you said that a team is Agile when they possess the set of values and principles which then allow them to adopt the right practice.
    What determines if the practice is right? Is it only if the outcome suits the customer or the outcome is a productive one?
    I mean, a team could adopt the wrong practice whilst also being Agile, no? They could have made micro decisions that perhaps they believed to have been driven by Agile principles and values, but ultimately still did not present the desired outcome.
    It all seems a little blurry and open to interpretation to me.
    I'm sorry if I got something wrong here, I'd appreciate any insight on this point. Thanks again!

  29. so…Agile is basically means cooperating and agreeing to work together in the customers best interest? We need a "system" and certification to be considerate?? WTF is wrong with humanity ppl????

  30. Software Agility is an approach to software development ( https://itechcraft.com/outsourcing-software-development-in-ukraine/ ) in which requirements and solutions are developed through the joint efforts of self-organizing and cross-functional teams and their clients . He advocates adaptive planning, evolutionary development, timely implementation and continuous improvement, as well as a quick and flexible response to change.

  31. Agile is a tool for the people to pretend they are doing things in the project but actually they do not know how to do software development, the real developer do not need Agile.

  32. Number 11 is bullshit. Self-organised teams are formed due to friendship biases and not necessarily including the best people for the team.

  33. I can not say that I have been more pleased with a presentation on something that I knew nothing about. Great job… excellent vid.

  34. 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?

  35. In this video explained that agile is not methodology, but why I often see someone said that agile is software development method?

  36. 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 Youtube.

  37. 1. "The Agile Manifesto"
    2. "Agile is a set of beliefs"
    3. "The 12 principles of Agile"

    In other words: all the characteristics of a religion or a cult, where its followers thoughtlessly follow and swallow the gospel.

  38. Very good content, a simple suggestion would be to add a subtle bg music or some kind of beat so as to get rid of that awkward silence at certain points in the video. Amazing explanation keep the good work going!

Leave a Reply

Your email address will not be published. Required fields are marked *