It Doesn’t Matter What You Call It
The great software-development-methodology wars never cease to amaze me. Agile, Waterfall, XP, SCRUM, RUP… so many people are so occupied with convincing everyone around them that their favorite methodology is the ultimate answer to practically any question.
Why is this a problem? Because no one methodology will ever be able to solve all problems. The process of developing software is (like almost anything else in our life) context sensitive. With every new project comes a different set of challenges, constraints and expectations. Each methodology has some great things to offer. No methodology, however, can fit as-is to every project.
In a recent post, Ed Gibbs describes how he was disappointed to realize that the stakeholders of a new project refused to adopt Agile development despite of some successful pilots conducted in his company:
“I just assumed that we’d be using our official Agile methodology on this high profile project. […]
[…] I turned out to be on a different page then the rest of the room. There idea appeared to be that we would run this as a traditional project. Traditional for us means a sort of strange version of waterfall, but waterfall none-the-less.”
Here’s the good news. The methodology wars are 90% psychological. If we would just stop using the names of one methodology or another in our discussions, most of our disagreements will disappear. At the end of the day, it all comes down to common sense.
In his post, Ed was troubled by the risk of spending weeks on writing requirement documents for a two-month project. Ed is right. This is a concern. It does not make sense to spend weeks on writing lengthy documents for such a short project. I bet he will be able to convince the other project’s stakeholders that there is a better way to manage the requirements in this project. I bet he will be able to do that without mentioning the word ‘Agile’.
At the same time, it might make sense to take a different approach when it comes to another aspect of development. Maybe the design of the product should be well-thought of before implementation starts due to the complexity of the product and the risk it imposes. Does this approach contradict Agile development? You know what, I don’t really know. What I do know is that for some projects it makes perfect sense.
You see, it doesn’t matter what you call it. Apart from the pseudo-prestige of saying “we use [your-favorite-methodology]”, the name of the methodology has no meaning.
Every methodology offers certain tools, guidelines and practices. That’s great. You have a great variety to choose from. No one says, however, you have to buy the entire package. You should use whatever tools and practices make sense for your current project. Create a customized process that fits perfectly to your needs and the needs of your stakeholders.
When you manage to do that, don’t be tempted to apply your customized process to a different project as-is. You should carefully analyze whether your process fits the new project, and adapt it as needed.
***
One more thing: please don’t comment on the fact that this article is tagged under ‘Agile’ against my own recommendation. That is, unless you really have to… ;)
May 2nd, 2006 at 6:01 am
I agree with you, I believe methodology picking time is lost time … as long as people involved focus well on product, BUT if team is not so mature I believe it needs a methodology, this is like the religion … if people are a bit lost they embrace all kind of believes searching for answers and support.
If we deal with a mature team with good focus and common goals I think MASTERPEACE is the reward.
May 2nd, 2006 at 8:17 am
My favorite article of all time on methodologies:
http://alistair.cockburn.us/crystal/articles/cpanfocisd/characterizingpeopleasnonlinear.html
May 2nd, 2006 at 8:41 am
I think both the comments above stress the point.
Part of the forces, constraints and challenges in each project is concerned with the human aspect.
Therefore, when you think of the customized process for your project you should take the human aspect into consideration.
Of course, the person(s) conducting this analysis and creating the customized process should be what Alex calls "mature" people. They should be aware of all the project’s constraints and considerations, and also be familiar with the assigned team.
The customized process, with the help of the person leading the project, should be used as the lighthouse (what Alex refers to as "religion") for "lost people".
However, applying an off-the-shelf process to a project involving only "lost people" is a sure recipe for failure.
Lidor
May 2nd, 2006 at 9:22 am
I agree with your observations in general, but you may go a little too far with some statements.
For example, I agree that the substance of how you get things done is far more important than the labels you attach to the process, but when you write “Apart from the pseudo-prestige … the name of the methodology has no meaning” you overlook something - some “standard” or “off-the-shelf” methodologies are excellent baselines for crafting a customized methodology that works for a particular organization and/or for particular types of projects. For example, RUP is a mature and well-proven lean methodology, and XP is a mature and well-proven agile methodology. When you use those terms - RUP or XP - many people get a very good sense of what you mean. It saves a lot of time you might otherwise have to spend explaining things.
For the same reason, I would extend Alex’s comment and suggest that time spent picking a methodology is not necessarily time wasted. If you are looking for a suitable approach to a project based on objective criteria, then choosing the appropriate methodology is an important step. It is just like choosing any of the other tools you will use to build the solution.
May 2nd, 2006 at 12:17 pm
Hi Dave,
From my experience in most cases when you are using the methodology name, people tend to get more emotional. Each of them comes with his preferred methodology, and chances are that he will do what ever he can to promote “it”.
However, when the same people start talking about the essence of things, they suddenly realize that they have more in common than they first thought.
In most cases, when the buzz is set aside, it is easier for people to reach common grounds based on common sense (and experience of course).
Most professional developers will eventually adapt a certain methodology rather than use it as-is. Reducing the emotional aspect (expressed in phrases such as “this and that is the BEST way to…”) will help more developers reach the optimal solution faster.
Don’t get me wrong: names are important for reference. But the minute they become a religion (to use Alex’s term), many people tend to blindly follow them without really considering their options. Having a tool box with a variety of practices and guidelines to choose from based on experience and knowledge is a much better approach.
Lidor
May 2nd, 2006 at 12:33 pm
One more note for Dave:
I don’t mean to flame the methodology war I go against, but something in your comment seem to demonstrate the emotional arguments I am referring to.
You say: "XP is a mature and well-proven agile methodology".
Do you have the statistical data to prove this statement? What kind of projects is XP well-proven for?
XP is made of a set of practices. Some are more widespread, while some are far from being common. To say that XP (as a whole) is mature and well proven without backing it up with data seems more of an emotional argument.
There are numerous flavors of "XP" out there. My guess is that almost none of them is practiced "by the book". If the discussion was about a concrete practice for a concrete project it would have made better sense.
A sentence such as the one cited above is not very usefull when you need to consider your options for the next project.
I am not implying of course that RUP, or any other methodology, is well-proven. I argue that such a claim is not useful when applied to a methodology as a whole and without any reference to a certain type of project. The domain we work in is too context sensitive for such arguments.
Lidor
May 6th, 2006 at 11:17 am
Hi Lidor,
I agree with your statements and reflects my own experience in the last 15 years in the software dev biz.
“What ever you call it” does presume that the process of software development is predictable and repeatable - and we all know that this is not the case in our ever changing world of software development as new tools and languages are introduced seemingly every 6 months. How can you make a process repeatable when the tools used by the process change all of the time?
I work at a professional services shop where our process is entirely based upon what the customer has in the way of time, money, resources and what they want to achieve. The customer is interested in the end result, not how to get there. Our process or the how is entirely based on experience for the given situation. The very first question we ask of ourselves is what can we reuse to get us to the end result given the time and budget constraints and what the customer wants. In fact, that’s our entire process from a macro perspective. Yes, you need some level of requirements, design, code, test, deployment, operations etc., but again, in our scenario, it is all experience driven, not methodology driven, which is maybe the point of your article.
Keep up the good writings.
Mitch
May 10th, 2006 at 3:16 pm
Lidor, thanks for the post. On target as always. :-)
Eugene, thanks for Cockburn’s “people” article again. I reread it and enjoyed it, but was also a bit disturbed. I’ve been around software over 30 years, though I’m no professional programmer. (That word dates me, doesn’t it.)
My Dad gave me a book about the new methodology of his day, Structured Programming, when I was a teenager in high school. I read it and said, “Dad, I don’t understand. This is what we’re learning in English class — outline, modularity, keyhole essay. Why do programmers have to write their own book about it? And give it this funny name?”
In the end, I’m hoping that “software people” will be able to escape from the confines of this software environment, and say it simpler: people make software. Thus whatever is true about people is true about software development.
I would not ask Cockburn’s question — why does the software field have to rediscover the issues every 30 years– but rather, why does software have to rediscover them at all? We should just learn from the rest of life, instead of pretending that software is so different.
May 10th, 2006 at 10:27 pm
Hang on a minute… if you don’t use a named methodology, then you can’t copyright its rituals and charge money for people to be trained in it, nor sell licenses for people to use it… Oh, wait, that’s a good thing… (;P)
December 12th, 2006 at 10:37 pm
You are right about software methodology debates being mostly psychological things . They have lot to with human beings than with software in my opinion. That is why I personally run from such debates . You are one of the few who has written sense on this issue I find.
Don Lapre is a Superstar
webmaster@j-ams.org
www.j-ams.org
August 9th, 2007 at 6:14 pm
EVE Online ISK
EVE Online ISK
EVE ISK
Buy EVE Online ISK
Buy EVE ISK
Cheap EVE Online ISK
EVE Online ISK
EVE ISK
Buy EVE Online ISK
Buy EVE ISK
Cheap EVE Online ISK
EVE Online Guide
EVE Guide
Runescape Gold
Runescape Gold
Runescape Money
Buy Runescape Money
Cheap Runescape Money
RS Gold
RS Money
Buy Runescape Gold
Cheap Runescape Gold
Runescape Gold
Runescape Money
Buy Runescape Money
Cheap Runescape Money
RS Gold
RS Money
Buy Runescape Gold
Cheap Runescape Gold
Free Runescape Money
Free Runescape Gold
Runescape Gold
Runescape Money
Runescape GP
Runescape Guide
Runescape Guides
Runescape Cheats
Runescape Hacks
WoW Gold,World of Warcraft Gold
WoW Gold
Buy WoW Gold
Cheap WoW Gold
World of Warcraft Gold
Warcraft Gold
WoW Gold
Buy WoW Gold
Cheap WoW Gold
World of Warcraft Gold
Warcraft Gold
WoW Guide
WoW Powerlevels
WoW Power level
WoW Powerlevel Guide
WoW Powerleveling Guide
Lineage II adena
Lineage II adena
Lineage 2 adena
Buy Lineage 2 adena
Buy Lineage II adena
Cheap Lineage II adena
Lineage II Gold
Lineage II adena
Lineage 2 adena
Buy Lineage 2 adena
Buy Lineage II adena
Cheap Lineage II adena
Lineage II Gold
Maple Story Mesos
Maple Story Mesos
MapleStory Mesos
Buy Maple Story Mesos
Cheap Maple Story Mesos
Maple Story Mesos
MapleStory Mesos
Buy Maple Story Mesos
Cheap Maple Story Mesos
Maple Story Mesos
MapleStory Mesos
Buy Maple Story Mesos
Cheap Maple Story Mesos
Buying Maple Story Mesos
Maple Story Mesos for sale
Cheaper Maple Story Mesos
Everquest II Plat
Everquest II Plat
Everquest II Gold
Buy Everquest II Gold
Buy Everquest II Plat
Everquest 2 Plat
Everquest 2 Gold
Everquest II Plat
Everquest II Gold
Buy Everquest II Gold
Buy Everquest II Plat
Everquest 2 Plat
Everquest 2 Gold
Gaia Online Gold
Gaia Online Gold
Gaia Gold
Buy Gaia Gold
Buy Gaia Online Gold
Cheap Gaia Gold
Gaia Online Gold
Gaia Gold
Buy Gaia Gold
Buy Gaia Online Gold
Cheap Gaia Gold
Final Fantasy XI Gil
FFXI Gil
Cheap FFXI Gil
Buy FFXI Gil
Final Fantasy XI Gil
FFXI Gil
Cheap FFXI Gil
Buy FFXI Gil
Final Fantasy XI Gil
FFXI Gil Guide
Final Fantasy XI Guide
Cheap FFXI Gil
FFXI Guide
SilkRoad Online Gold
SilkRoad Online Gold
SilkRoad Gold
Buy SilkRoad Gold
Cheap SilkRoad Gold
Buy SilkRoad Online Gold
Cheap SilkRoad Online Gold
SilkRoad Online Gold
SilkRoad Gold
Buy SilkRoad Gold
Cheap SilkRoad Gold
Buy SilkRoad Online Gold
Cheap SilkRoad Online Gold
WoW Powerleveling
WoW Powerleveling
WoW Power leveling
Buy WoW Power leveling
Buy WoW Powerleveling
Buying WoW Powerleveling
Cheap WoW Powerleveling
WoW Powerleveling
WoW Power leveling
Buy WoW Power leveling
Buy WoW Powerleveling
Buying WoW Powerleveling
Cheap WoW Powerleveling
WoW Powerleveling
WoW Power leveling
Buy WoW Powerleveling
a href=”http://www.powerleveling-wow-powerleveling.com”>Cheap WoW Powerleveling
Lotro Gold
Lotro Gold
Lotro Gold for sale
Buy Lotro Gold
Buying Lotro Gold
Cheap Lotro Gold
Lotro Gold
Lotro Gold for sale
Buy Lotro Gold
Buying Lotro Gold
Cheap Lotro Gold
Lotro Guide
Buy Lotro Gold
Lotro Gold
Lotro Powerleveling
Video Game Powerleveling
Runescape Powerleveling
Buy Runescape Powerleveling
Lotro Powerleveling
Buy Lotro Powerleveling
Lineage 2 Powerleveling
LineageII Powerleveling
Runescape Powerleveling
Buy Runescape Powerleveling
Lotro Powerleveling
Buy Lotro Powerleveling
Maple Story Powerleveling
MapleStory Powerleveling
Vanguard saga of heroes Gold
Vanguard saga of heroes Gold
Vanguard Gold
Buy Vanguard Gold
Cheap Vanguard Gold
Vanguard saga of heroes Gold
Vanguard Gold
Buy Vanguard Gold
Cheap Vanguard Gold
MMORPG Games Guide
MMORPG Games
Video Games
Video Games Guide
PC Games
August 23rd, 2007 at 11:58 am
Play powerleveling games Maple story power leveling
August 27th, 2007 at 11:15 am
You should choose a name for this software, it is really useful
June 30th, 2008 at 10:31 pm
no real comment