Agile Dictionary: Misunderstandings Can Be Fatal
Agile Dictionary: Misunderstandings Can Be Fatal
Often times, Agile projects fail because the team or leadership misunderstands just what Agile is. So, we've compiled a list of key terms that help to truly define Agile.
Join the DZone community and get the full member experience.Join For Free
[Latest Guide] Ship faster because you know more, not because you are rushing. Get actionable insights from 7 million commits and 85,000+ software engineers, to increase your team's velocity. Brought to you in partnership with GitPrime.
Quite often, when I work with clients (external or internal) who are struggling to grasp the idea of what Agile, Scrum and their relatives actually are and what they are not, decision makers don't know which processes/solutions they can replace/change in the company/project, and which they cannot. This ultimately leads to decisions that fall into the category of strange and foolish
It was clearly not because they weren't intelligent enough to understand the great truths behind Agile, but because nobody ever explained it to them clearly, or even worse, they had read blogs/articles that gave them only 10% of the whole picture and the rest of it was filled in by their (sometimes false) assumptions.
Agile/Scrum trainers sometimes also present their own set of processes/ideas as "The Agile" or "The Scrum" or "The Kanban" which further confuses our poor decisions makers.
So let's take a look at some Agile vocabulary that everybody who is involved in a project should understand clearly, and be able to use properly.
Waterfall Model (a.k.a. "traditional development model")
In order to offer a standard definition of Waterfall, I here refer to the Wikipedia definition of the process:
"The waterfall development model originates in the manufacturing and construction industries; highly structured physical environments in which after-the-fact changes are prohibited, mostly due to cost restrictions. Since no formal software development methodologies existed at the time, this hardware-oriented model was simply adapted for software development."
It is important to mention here that NOBODY EVER claimed that the pure waterfall model would fit well into software development.
On the contrary, even the earliest adopters stated that in practice prototypes and numerous iterations were necessary to make it a more-or-less working model in software development.
Why? Simply because Software Development in practice ALWAYS involves a high number of changes during the project. Changes are not exceptions, they are the rule that drives the whole project. Therefore a Software Development model/approach must be very well prepared for these changes.
Does it mean that Waterfall is inherently wrong? Yes, I'm afraid so. PURE waterfall is inherently wrong when applied to software development. But I doubt that any sober project manager has ever tried to apply pure Waterfall in any project.
Pure waterfall is a myth actually. In practice, PMs have always tried to introduce iterations, change management, other practices and tools to deal with changes and other challenges that were coming up during a project's life.
My very first job was (10+ years ago) a C++ developer role in a giant German project (500+ people) where the processes were so mature and so refined (including planning, design, BA, and more importantly change management) that this model actually worked. We released new versions with good quality, and the clients were more or less happy. So there was Project Management on Earth before Agile, and there were great Project Managers and projects as well.
Agile (Software Development)
Agile (software development) is a software development approach which means "nothing more" than following the principles described in the Agile Manifesto during your development process.
Are you already following these principles successfully in your current project? (Wait! DID you really READ that Manifesto before answering? Most of the guys I meet have never done that...)
Yes? Fine, your development is already Agile...
Is being Agile your goal?
Well, presumably your goal is to deliver what makes your client happy, deliver in time, and do your best to not exceed your budget and get as much profit as you can.
So being Agile is not a goal, but it is a great approach to reach your goal, with principles like, "Our highest priority is to satisfy the customer through early and continuous delivery of valuable software."
Let's assume you understand and accept all the Agile principles.
Does that mean you know how to plan your project? To track your progress? To ensure quality? Etc.
Does that mean your team members know what, when, and how to do to adhere to these Agile principles?
Why? Simply because most people living on planet Earth prefer following rules defined by old-and-wise-guys-with-lots-of-experiences instead of thinking about how to adhere to the spirit of great principles
For this very reason, we have Agile methodologies to guide most of us on how to be Agile every day.
- XP (eXtreme Programming)
- RUP (Rational Unified Process)
- Do Whatever Agile (any other way how you work which follows Agile principles)
It is VERY important to understand though, that these methodologies DO NOT necessarily COVER everything you have to do during a project's lifecycle.
You may be surprised that, for example, Scrum has only 12 "rules." No more, no less! While Kanban has only 3 and RUP has 120+! And how well defined are these rules? Well, the whole Scrum framework is defined in 16 pages (with Content and Acknowledgments), while RUP has a 270-page guide.
(Some may argue whether RUP is Agile or not, but the new version of RUP has definitely taken over enough Agile principles so that the comparison is fair enough.)
Lean (Software Development) and Kanban
You may have noticed that I did not list Kanban as an Agile methodology but included it in the comparison.
This illustrates the position of Kanban in the Agile world quite well. Lean (software development) itself is NOT an Agile methodology, but instead, just like Agile, it is a set of principles that has been taken from lean manufacturing and applied to software development. Lean and Agile principles, however, are very closely aligned, as they both encourage the same kind of team behavior, project management style, etc., but, in my opinion, Agile is much closer to the western mindset.
I always found Lean and its weird "Eliminate the Waste!" mantra a bit hard to embrace and apply in my daily work.
Kanban is not an Agile methodology either, but it is derived from a Lean production system used at Toyota in Japan, so it is much closer to Lean principles.
Agile Practices and Tools
Agile practices and tools are those... well, practices and tools that support (fit well into) the Agile principles, like:
- Story, Epic, Theme
- Agile Planning
- Product/Iteration(or Sprint in Scrum) Backlog
- Estimation in Story Points
- Planning Poker
- Burndown/up charts
- Continuous Integration
- Pair Programming
- Automated testing
(You can find a number of practices and tools in various books, and a great summary of the 11 best books in one. If you have time to read only one book about Agile you should read that one.)
First of all, this is not at all a definitive set. If you invent a tool/practice in your own company which supports Agile principles (and works well in your environment at least), then there you go, you have an Agile practice. Don't be shy, other Agile practices and tools are created by people like you who wanted to answer questions applicable to the real world.
Also, if you find an Agile practice written somewhere and it does not fit the way you work, it does not necessarily mean that your way is not Agile. Take it for what it is... it just does not fit your company/team/PM style and that's all.
These practices are NOT for Agile only and not even necessary invented for Agile (pair programming worked in the '80s as well).
Some of these tools and practices are defined in or invented/dictated by certain methodologies, some are not. Don't let this fact confuse you.
Pair Programming (praised heavily by XP) is not the property of XP! Want to use it in Scrum? Have you read something in the Scrum Guide against it? I do not think so... so why not?
Want to have Epics in Kanban? Again, why not?
You do not want to estimate Story Points in Scrum? Fine! It's not even mentioned in the Scrum Guide!
Be agile when following Agile!
And here we are, at our beloved and well-known Scrum.
But have you ever realized that Scrum is "just" a framework which helps you obey the principles of Agile?
It is VERY important to understand the framework nature of Scrum!
Pure Scrum is NOTHING more than a set of Roles, Artifacts, and Events written here.
Scrum does not say that you should estimate your Stories in Story Points. It also does not talk about Continuous Integration, or Automated testing, or how to estimate a project. It does not even talk about Stories, Epics, and Themes!
These are all Agile tools and practices commonly used to make the framework work in real life.
The source of the confusion is that in training sessions, Scrum trainers fill the framework with common best practices and tools. While it is a GOOD thing because that is what a framework is for, they often forget to mention that you can replace almost all of these tools and practices if you want.
Why do they do that? Are they inherently evil? Not at all, but it is much easier to sell a training which offers a "complete solution" to companies, and much easier to make the trainees understand the Agile concepts if you keep it simple, offering simple rules to follow, instead of a Lego board with some pre-built walls (Scrum) and a bunch of building blocks (Agile tools and practices) that let you create your own processes.
So most of the guys who hate Scrum actually hate those practices and tools that their trainers tried to sell with Scrum (as mandatory), not Scrum itself.
Scrum is way too little to be hated by anyone...
This excerpt from the "Unofficial Scrum Checklist" is very telling. Also, it could be titled, "Official Agile Checklist," don't you think?
The Big Picture
It is quite hard to depict all these terms in one image, but let's give it a try!
Poor Conclusions, Poor Decisions
After understanding the terms, it is easy to spot how poor vocabulary could lead us to poor conclusions and eventually to poor decisions. Here are some real life examples.
|Real life example||Poor vocabulary||Poor conclusion||Poor decision||What did they misunderstand?|
|The management team of a company introduced Scrum into a project. They had all the meetings, all the roles the Scrum had defined, still, the project was a failure, and everybody hated the new way they had to work.||
Scrum is a brand new complete solution stack for software development that ensures the success of the project if all of its rules are obeyed with rigorous precision.
Artifacts of the "old way" like specification, test plans, and roles like QA manager, project manager, are not necessary anymore.
Agile principles represent the theory, Scrum is the implementation. We should follow it and everything will be Agile and we'll be fine.
|Scrum does not work in practice.||Let's fall back to how we did things before. That was bad, but Scrum is much worse.||Homework. (you can send your answers in comments )|
|The management team of a company introduced Scrum in a project. They had all the meetings (except a few that made no sense for the team when the trainer presented them), all the roles that Scrum had defined (except that the PO participated only in demo meetings because he had no time), still, the project was a failure, and everybody hated the new way they had to work.||Scrum is just a framework. It must be safe to use just some parts of the framework, right?||
Scrum does not work in practice.
|Let's fall back to how we did things before. That was bad, but Scrum is much worse.||Homework. (you can send your answers in comments )|
|A CEO was considering using Scrum in the company's next project, but he had many questions that Scrum had no answers for, like "What to do when the project is failing to meet deadlines?" "How to give a fixed priced quote?" "How to handle risks?"
He had answers for these questions in his current projects (even if he was not completely satisfied with how his projects performed) so he abandoned the idea to introduce Scrum.
|Scrum is a complete replacement for the whole production and management of the company. They have different and better answers/solutions to all the old questions. There is no Project Manager role mentioned in Scrum so the role and the skills of the Project Manager are not needed anymore.||Scrum is not mature enough, they have to evolve to answer "real world" problems.
Scrum is how Agile is done in most companies, so they are more or less the same.
|Let's forget Scrum and Agile (they are more or less the same anyway).||Homework. (you can send your answers in comments )|
|A project that had worked fine according to Scrum needed more frequent releases than the ones happened after the demo meeting.||In Scrum (which is a rulebook you must follow or die) a release must happen after the demo meeting, not sooner, not later.||We have no other choice, Scrum can not be misused.||Let's switch to Kanban (and pay again for the same trainer who trained us how to use Scrum).||Homework. (you can send your answers in comments )|
|http://antiagilemanifesto.com/||Agile is about "Epics, Stories, Sprints, Stand-ups, Iterations, Backlogs, Backlog grooming, Burn-down charts, Velocity..."||"Agile is simply the obfuscation of common sense. "||Let's forget "Agile," use the old terms and common sense!||Homework. (you can send your answers in comments )|
To summarize the messages this article wants to convey, here are some closing thoughts:
- Agile principles are great, it is hard to deny it.
- If you want to follow Agile principles:
- read them, understand them, use them
- choose an Agile methodology of your liking (or just follow those principles if you feel you do not need one).
- follow the rules of your chosen framework
- use well know Agile tools or practices to fill the gaps if your methodology does not cover something you think it should cover.
- or invent your own Agile tools and practices.
- break the rules of your chosen framework ONLY IF
- you are absolutely sure why that particular rule was originally set up.
- you understand its benefits (rest assured it HAS benefits even if you do not understand them) and drawbacks.
- you are ready to sacrifice its benefits for the greater good.
- Revise your decisions regularly (call it Retrospectives, Process Refinement Meetings, or whatever you want).
- a decision that sounded cool last week may have proven silly since.
- Never forget that Agile is just a set of principles, and Agile methodologies (like Scrum) are just a set of rules, practices, and tools.
- You still need people to complete the work, and a PO/PM with project management skills on your team so that the project can be completed on time, within budget, and with good quality!
Published at DZone with permission of Janos Biro . See the original article here.
Opinions expressed by DZone contributors are their own.