Almost every time I found that our clients (external or internal alike) struggled to grasp the idea of what Agile, Scrum and their relatives actually are and what they are not, therefore these decision makers didn’t know which processes/solutions they can replace/change in the company/project and which they cannot. All these ultimately led to decisions that fell into the category of strange and foolish.I have worked with numerous companies that were focusing on either realizing their own ideas, or ideas of their clients, in the form of start-up projects.

It was clearly not because these 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 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.

Good Vocabulary

So let’s see a 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”)

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. (Wikipedia).

It is important to mention here that NOBODY EVER claimed that the pure waterfall model would fit well to software development.

On the contrary, even the first mentions 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 high number of changes during the project. Changes are not exceptions but they rule/drive 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 projects.

Pure waterfall is a myth actually, in practice PMs have always tried to introduce iterations, change management, other practices, 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 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 in good quality, 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 some principles during your development described in the Agile Manifesto.

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, do 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 its principles like “Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.”

Agile Methodologies

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?

Not necessarily…

Why? Simply because most people living on Planet Earth prefer following rules defined by old-and-wise-guys-with-lots-of-experiences (let’s call them politicians?) instead of thinking about how to adhere to the spirit of great principles…
It is why we have 10 commandments in the Bible instead of just one stating: “Be a good man!”. “Thou shalt not kill” is very hard to misinterpret, isn’t it?

For this very reason we have Agile methodologies to guide most of us how to be Agile every day.

• Scrum
• XP (eXtreme Programming)
• DSDM
• FDD
• 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.

Also it is not NOT balanced what areas they cover, and not balanced how deeply they cover these topics either.

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), RUP has a guide of 270 pages.

(Some may argue that RUP is Agile or not, but the new version of RUP has definitely taken over enough Agile principles so that the comparison can be fair enough.)

Lean (software development) and Kanban

You may have noticed that I did not list Kanban as an Agile methodology but included 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, 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, both encourages the same kind of team behavior, project management style, etc., but (IMHO) 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
  • Velocity
  • Burndown/up charts
  • ….
• Continuous Integration
• Pair Programming
• Automated testing
• Retrospectives
• …
• [YOUR PRACTICES GO HERE]

(You can find a great deal 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 a definitive set at all, 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 of the real world.

Also, if you find an Agile practice written somewhere and it does not fit to 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 80’s 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 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!

Scrum (framework)

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 talk about that you should estimate your Stories in Story Points, also does not talk about Continuous Integration, or Automated testing, or how to estimate a project, does not even talk about Stories, Epics and Themes.
These are all Agile tools and practices commonly used to make the framework working in real life.

The source of the confusion is that in trainings Scrum trainers fill the framework with common best practices and tools. While it is a GOOD thing because it 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) letting 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 talkative.  Also, it could be also titled as “Official Agile Checklist”… don’t you think?

from the “Unofficial Scrum Checklist” by Henrik Kniberg

The Big Picture

It is quite hard to depict all these terms in one image but let’s give it a try…

* http://www.agilemanifesto.org/principles.html
** http://www.allaboutagile.com/7-key-principles-of-lean-software-development-2/

Poor Conclusions, Poor Decisions

After understanding the terms it is easy to spot in these real life examples how poor vocabulary could lead us to poor conclusions and eventually to poor decisions.

Real life example	Poor vocabulary	Poor conclusion	Poor decision	What did they misunderstand?
The management of a company introduced Scrum in 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 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 the Scrum had defined (except that 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 part of the framework, isn’t it?	Scrum does not work in practice.Link	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 Scrum to be used in the next project of the company but he had many questions 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 are 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 of the 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 notbe 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 )

Summary

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 one
    1. use well know Agile tools or practices to fill the gaps if your methodology does not cover something you think it should cover
    2. or invent your own Agile tools and practices
  • break the rules of your chosen one ONLY IF
    1. you are absolutely sure why that particular rule was set up originally
    2. you understand its benefits (rest assured it HAS benefits even if you do not understand them) and drawbacks
    3. you are ready to sacrifice its benefits for a greater good
  • Revise your decisions regularly (call it Retrospective, Process Refinement Meeting or whatever you want)
    1. a decision that sounded cool last week may have proven to be silly since then
• 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 project management skills in your project so that it can complete in time, within budget and in good quality!