What is Agile?

This short cartoon answers the question “What Is Agile?” and will give you the background to understand the Agile principles and values and how they can help you and your team work together more efficiently. If you’d like a free book on this topic, please see below…


I’ve published a book called “Starting Agile” that is designed to help you start your team’s Agile journey outright. You can buy a copy from Amazon, but I’m giving free copies away to my subscribers from YouTube. You can signup for a copy at the link above.

If you’d like to connect with me on LinkedIn you can find me at the link below. Just send me a message saying hello and that you found me from one of my videos:


24 Comments on “What is Agile?”

  1. very well explained, cleared my very concept. Thank you for this video. Thumbs up!

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

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


  5. What an annoying video format. And that music at the beginning. Watch it at 1.25x, trust me.

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

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

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

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

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

  12. I'm laughing because principle 11 is exactly what my advanced programming professor said. Good programmers have to be lazy. LoL

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

Comments are closed.