Monday, 04 July 2011 12:26

Agile is a Fad

Written by 
Rate this item
(6 votes)

July5FeatureAgile is the hottest word in our profession these days. Go to any BA or PM conference and there is at least 1 session dedicated to agile.  Even if the session does not have agile in it, you’ll hear the agile word over and over.  On sites like this one, there are many blogs and articles written about agile.  Here is the article that inspired me to write this post, Four Agile Tips to Eliminate Rework in Application Development .  

The article lists these four tips which are credited to agile methods. 

 

  1. Collaborate – Involve multiple stakeholders in requirements definition
  2. Be lean – Quote from article – “Agile methods teach us that a 400-page document is not required in order for development to begin. In an agile environment, development can start with high-level user stories with perhaps one layer of detail added.”
  3. Iterate – Approach requirements definition in an iterative process
  4. Visualize – requirements do not have to be written in paragraph form.

I agree 100% with all of these tips not because they are agile tips, but because they are smart practices.  Before the Agile Manifesto was developed, I worked on teams that collaborated, were lean, iterated, and visualized. I wrote about this in a blog post last year, My First Agile Project.  I would guess you have been doing this for some time too. This is why the word agile is a fad.  In the near future we will stop having debates of whether you use agile vs traditional approaches.  We’ll just start doing what is appropriate for projects to drive results.

This spring I saw Scott Ambler speak and he said we don’t need repeatable processes we need repeatable results.  What this says to me, is do what is needed to drive results.  Teams need to come together and determine what will work best to give them the best chance to deliver results.  This is just smart.   

The agile movement shook our community and made us all think about how we were running projects.  It made us make sure we are focusing on business value.  Don’t push for agile over waterfall, push for what is right for the project. Push for what is right for the business in the short and long term.  Even though I think the word agile is a fad, the agile movement is definitely a trend.

All the best,

Kupe

Don't forget to leave your comments below. 

Read 25070 times Last modified on Tuesday, 03 April 2012 11:45
Kupe Kupersmith

Kupe Kupersmith, President, B2T Training, possesses over 14 years of experience in the business analysis profession. He has served as the lead Business Analyst and Project Manager on projects in the utility, television and sports management and marketing industries. Kupe is a Certified Business Analysis Professional (CBAP) through the IIBA. Kupe is a trained improvisational actor and performed for years in clubs around Atlanta.  He is a big believer that we can work and learn while having fun. Kupe is a connector and has a goal in life to meet everyone!

Comments  

0 # Natalie 2011-07-05 04:59
Great article. This has been my experience as well re: Agile vs Waterfall vs Whatever. Bottom line is, whatever the methodology, don't lose common sense along the way.
Reply | Reply with quote | Quote
0 # Declan Chellar 2011-07-05 04:59
Thanks for saying it out loud, Kupe! Or at least in writing. Decla n
Reply | Reply with quote | Quote
0 # Manji Sekhon 2011-07-05 04:59
Love the article! I felt like an old timer when i said, "Do what is needed to drive results, set expectations correctly right from the start".......
Reply | Reply with quote | Quote
0 # Glen B Alleman 2011-07-05 05:01
Kupe, All good stuff, once you establish the domain and context in that domain. The suggestion of repeatable results is the customers point of view. The Measure of Effectiveness of the business producing the product in the customers eye (internal or external). But ti suggest that a repeatable process is not needed to produce a repeatable result needs some actual field evidence. How for example can a repeatable result be delivered if the underlying process is changing or does not stay the same from project to project? Scott makes the statement with little or no support of "how" to get the repeatable result. The irony of course is the firm Scott works for (IBM Rational) makes and sells tools that enable repeatable processes. So let's here the actionable suggestions of how to do this before accepting the statement as credible.
Reply | Reply with quote | Quote
+1 # Jim Adcock 2011-07-05 05:06
I know quite a few people who would totally flip out over this article, both against and in favor (the in favor because the Agile community has, in his estimation, become about celebrity and using the buzzword to get business rather than about doing things better). I recently wrote a series on SharePoint governance that got a few people talking about the buzzword-ness of governance. Bu t dismissing agile (or governance, for that matter) as a faddish buzzword is missing a lot. Sure, there are people who use the word(s) in a buzzwordy way, with a shallow understanding or a desire just to hook clients. But beyond these things, there are parctices, learned from experience, about how things can go wrong doing the "right" thing. If you are going to do things in an "agile" way, there are pitfalls and best practices within that way that practitioners should be aware of, just like there are best practices in doing things in a "waterfall" way. Don't throw out the baby with the bathwater. When doing what is best for the project/busines s, use best practices when doing so, instead of ignoring them beacuse the word used to describe them is a "fad".
Reply | Reply with quote | Quote
0 # Rob McMenemy 2011-07-05 05:17
And while we are on the subject, Scrum - is just the team meets that we always regularly had. Functional Teams or Technical teams - work groups getting together regularly to vet where we are - sometime with stakeholder and sometimes not. It's not like I expected that Agile would be able to come up with entirely divergent ways of running a project to, but when somebody asks me about methodology I will or should use for an engagement, I say it does not mater as long it covers the processes defined by PMBOK. The rest is just skills, experience and dedication.
Reply | Reply with quote | Quote
0 # Jim 2011-07-05 05:29
Great article Kupe. Agile is a set of principles and intentions of how to look at solutions. Honestly, how could you go wrong with "early and continuous delivery of valuable software"? I don't think many folks actually look at the AgileManifesto. org web site, for the Manifesto and the Principles behind Agile. It's a set of principles and intentions and not a methodology. S crum is not Agile XP is not Agile RUP is not Agil These are all processes and methodologies that attempt to adhere to the principles and intentions of Agile, but they are not Agile.
Reply | Reply with quote | Quote
0 # Erick 2011-07-05 05:32
I agree, but I think that this agile fad has helped in promoting best practices for software development. Even stakeholders now are aware of how things need to be done because of that new, hot word: AGILE
Reply | Reply with quote | Quote
0 # Bennett 2011-07-05 05:51
I'm reminded of a statement made by a BA speaker. He said that Agile methodology was used in the 70's (although not called that), then gravitated towards waterfall, and now the pendulum has swung back to agile due to the process-heavy nature of waterfall. Rework is expensive says waterfall. Embrace change says Ambler - the user does not know what they want, unless you show them something. So, there's snippets of common sense on both sides of the camp. But the one that makes the most sense to me is - it depends upon the application. If you're working on ' nuclear reactor ' type projects, agile would be the wrong way to go.
Reply | Reply with quote | Quote
0 # Karen S 2011-07-05 05:58
I have seen in many instances where the delivery of a product in short increments, and getting it in front of the end user earlier rather than later, vastly affects the final deliverable. Often what the end user thinks he wants in the beginning is not what he ends up wanting (and needing) in the end. Expecting to get every requirement up front, get it delivered exactly as promised and have it meet all of the end user expectations is, in most cases, unrealistic. Agile/increme ntal delivery is a terrific methodology for getting to the meat of what will work to meet the business requirement, getting it delivered quickly and offering the most satisfaction to all parties involved. I strongly advocate incremental delivery, in whatever label you want to give it, as the way to deliver software now and in the future. Let's hope it is not just a fad.
Reply | Reply with quote | Quote
0 # Kate Shorey 2011-07-05 06:21
Kudos Kupe. A project does not have to be Agile to employ agile techniques. Back int he day when there was enough money and enough time, perhaps we didn't need these techniques. Yet had we then, perhaps we would be in better shape now! I was particularly fond of this piece: [Scott Ambler] said we don’t need repeatable processes we need repeatable results. What this says to me, is do what is needed to drive results. Teams need to come together and determine what will work best to give them the best chance to deliver results. This is just smart. Great post. Kate
Reply | Reply with quote | Quote
0 # Marcos Ferrer, CBAP 2011-07-05 06:35
Concurrence. Smart is smart, and Agile is much abused as people attempt to build Enterprise Strength systems on "tiny code architectures". A better use of "Agile" would be to crank requirements, then architecture, then code - or something like that.
Reply | Reply with quote | Quote
0 # Ed Stahlman 2011-07-05 06:59
I think this article does a great job of focusing on "smart work", not buzz words. The theme of doing "smart work" is what drives new concepts like agile, but the "smart" part is often lost as people try to replace the "work" with a recipe. I think the same thing happened with object-oriented programming/ana lysis (as well as other concepts that became buzz words). The tenents of OOP/A are smart ways of doing business, but it became a buzz word and many poeple stopped thinking about the concepts behind OOP/A resulting in less than expected results. To me, what it boils down to is good analysts with the right skills doing the right thing for the current project.
Reply | Reply with quote | Quote
0 # Jon 2011-07-05 07:17
When time permits I look forward to commenting on this in detail. Although I do believe methodology ideologues tend to paint themselves into a corner... I do not believe the rhetorical statement "Agile is a Fad" is a fair statement.
Reply | Reply with quote | Quote
0 # Bob Wysocki 2011-07-05 07:30
For years I have been saying that project management is nothing more than organized common sense. If you are using a methodology that requires you to do something that doesn't make sense, don't do it! Defend your decision and fix the methodology. My approach is and has always been to assess the characteristics of the project, the environment, the client and the market. Then pick and adapt the best fit set of tools, templates and processes and go for it. Be watchful for any changes that may impact that best fit decision and change your approach accordingly.
Reply | Reply with quote | Quote
0 # Patrick Dooley 2011-07-05 08:42
Great article again Kupe. While Agile is a buzzword, I think the whole Agile movement has been an important one that was necessary to evolve our collective thinking on project and analysis approaches, to give some of our PM colleagues a kickstart that traditional project methodologies should not be followed religiously, and to give new practitioners another framework to learn from. It seems that it's human nature that an 'extreme' polarized view to the status quo is required to find, and land at, the right equilibrium.  I wholeheartedly agree that a 'smart or appropriate' approach is required for every project. It takes years of experience however to make the call on what's 'smart or appropriate'  at the onset of a project and also identifying the signals throughout a project to know when & what changes are required. Those without that experience, we'll continue to need different models/methodol ogies/approache s to learn from, as a place to get started.  Mayb e in years to come BA and PM training will be centered around 'scenario based' learning rather than from 'methodologies' or 'approaches'. I would welcome that and look forward to further debate on the topic of the validity of these methodologies/a pproaches and how they can be used effectively. Thanks again!
Reply | Reply with quote | Quote
0 # Jonathan Babcock 2011-07-05 08:45
Kupe - Nice work as usual, my friend. I like agile as much as the next guy, but there will be a "next big thing" at some point, and your basic premises will still hold. I have seen successful teams in linear development methodologies and in more agile/iterative ones. The common denominators were the common sense principles you mentioned, and solid teamwork (empowered team, and mutual accountability) . I won't copy it all here, but think my recent blog on how "agile" is important to business analysts ( http://practicalanalyst.com/2011/06/21/how-agile-is-important-to-business-analysts/ ) complements this post nicely. The gist is that, for analysts, "agility" means the ability to work smart and effectively in any type of delivery environment.
Reply | Reply with quote | Quote
0 # Angie Perris 2011-07-05 09:19
Kudos to Kupe. I agree. As you (and others) have stated not many would argue with the agile intentions for software development and the simplicity of a process framework, such as Scrum, which encourages people to figure out what is really needed and to do what is right for the project. No more, no less. There are many of us who have been performing business analysis using these guidelines for years!
Reply | Reply with quote | Quote
0 # Andrew Blain 2011-07-05 11:34
Long after the "fad" is finished and people stop talking about Agile at conferences, the innovations arising from the Agile Manifesto and the methodologies which attempt to implement it will remain. I think the statement "In the near future we will stop having debates of whether you use agile vs traditional approaches" would be better written "In the near future we will all have adopted agile approaches in our traditional methodologies but we will long have forgotten the source."
Reply | Reply with quote | Quote
0 # Paula Bell 2011-07-05 11:46
I agree with you Kupe, these are smart practices regardless of what it is called.
Reply | Reply with quote | Quote
0 # Cecilie Hoffman 2011-07-05 11:57
Agile is just the current slick packaging of "rapid iteration" practices used by those programmers who were writing in LISP and Prologue and SmallTalk in the 1980's. Let's hear it for repeatable *and measureable* RESULTS. Let's hope that this fad becomes so mainstream that in another generation no one remembers that it was a fad.
Reply | Reply with quote | Quote
-1 # craig brown 2011-07-05 13:29
You would make a great fisherman Kupe. You know hoe to get a bite. Great comments everyone. @jb next fad is lean. And of course even though they are fads the shift the status quo
Reply | Reply with quote | Quote
0 # Salah 2011-07-05 13:55
Great Article Kupe! I agree with Jim's comment. Agile is not a methodology, it is a set of principles. This just happened to be the name the people who came up with those principles chose to call them. http://agilemanifesto.org/principles.html
Reply | Reply with quote | Quote
0 # Robert Gartner 2011-07-05 14:23
A wrench losens and tightens nuts/bolts. Why are there so many different types? ALL and I mean ALL SDLC's have thier place. I use caution with anyone who tries to sell me with the idea that ONE size fits all. Ambler is a intelligent and good guy. Honestly I'm just not a big fan. If you do your research you'll see he was a big RUP proponent years ago. I get the feeling he is more into marketing these days. Back in the mid ninties, I worked for guys who were using the "Agile" principles under the RUP label. Nothing new here folks except a much better communication and marketing effort. However, just like RUP before it - it is no silver bullet. Learn to right size a project and then use the appropriate development approach. Waterfall. RUP, Agile, Kanbaan, etc all have there place. It's just trying to find the right sized wrench for the job at hand - some wrenches are too large and some are too small. I believe organizations are starting to become more aware that one size does not fit all.
Reply | Reply with quote | Quote
0 # Gabe Margan 2011-07-05 22:28
I agree with a lot of these comments. I was a BA for over 12 years and had to deal with many of these fads, RUP, Waterfall, Agile, etc. At the end of the day it is about common sense. I've been writing requirements in bulleted format since I started, now Agile comes along and tells us not to write requirements in paragraph form. It's reselling old practices/ideas under different brands (Agile, RUP, etc.). It's a way for consulting firms to make money re-packaging and selling old ideas. You have to look at your project and what you're trying to achieve. If you're building a new system then documentation is absolutely critical so that you can maintain or sell that system to other organizations. In my mind the system you've built is a product the organization owns and the requirements and other documentation are just as much a part of that product as the system itself. Without that documentation your system knowledge resides with the people that built it, those people may not be with your organization for the rest of their lives.
Reply | Reply with quote | Quote
0 # Johann Lohrmann 2011-07-05 23:13
Excellent post. My mantra is, 'Does it Work'? This applies to the entire process. A process that is not questioned does nothing but make the person feel safe and good about themselves. I follow a process because it's effective.
Reply | Reply with quote | Quote
0 # Kupe 2011-07-06 00:57
Wow!!! Awesome comments everyone. It seems for the most part we are all on the same page. I do want address the results over process point. I think @Johann hits on my point. I feel a repeatable process is necessary if it yields results. Results should be your focus, not the process. If a repeatable process helps improve results than great. This being said your process needs to be flexible enough to allow teams to make the decisions on the approach that best fits the project. There is no silver bullet.
Reply | Reply with quote | Quote
-1 # Alan Gladman 2011-07-06 01:27
I remember an early Ken Schwaber video talking about the creation of scrum. He said its nothing new, just a logical collection of best practices that has been in use in the software development industry for many years. So the agile industry has long recognised this and doesn't profess to have invented the best thing since sliced bread. Maybe somewhere along the line then, some of the less scrupulous agile consultants have over emphasised the benefits and given it this seemingly unfair reputation of solving world hunger.
Reply | Reply with quote | Quote
0 # Linda 2011-07-06 01:28
I agree so much, Kupe. I have been in IT for many years and have always collaborated, etc., as you stated in your article. Why wouldn't one do so? It only makes good sense.
Reply | Reply with quote | Quote
0 # Kupe 2011-07-06 01:32
@Alan - I agree...well said.
Reply | Reply with quote | Quote
0 # irene 2011-07-06 02:28
perfectly stated and so true
Reply | Reply with quote | Quote
+1 # David Wright 2011-07-06 08:41
Well, I have always said that 'agile' sounds better than 'clumsy'... My concern is about users not knowing what they want; who cares about what they want? Everyone needs to work together (yeah, collaborate) to make sure the organization gets the systems it needs. Users come and go, systems are (almost) for ever...
Reply | Reply with quote | Quote
0 # Rainer 2011-07-06 19:50
Having just read your article, i gathered my thoughts to write some comments in response, but all the above says it, and more, and often more elegantly than i can. The 'agile' word has been abused beyond meaning, i try to avoid it in conversation. Mostly when i hear someone use the word my bullshit radar goes on high alert. 'Nimble ' anyone? ;-) The manifesto and it's associated principles however i consider to be a thing of beauty - distilled common sense - it's relevance goes far beyond software development in my view.
Reply | Reply with quote | Quote
0 # Subhi Bansal 2011-07-06 20:08
Very true..It is all about common sense, logical thinking and what works best for your project.
Reply | Reply with quote | Quote
0 # Paul Taylor 2011-07-06 22:20
Great read, Kupe! My history maps to your own where collaboration was not wrapped in Agile! It was called product development!
Reply | Reply with quote | Quote
0 # Duane Banks 2011-07-06 23:27
Hi Kupe, Yet another good article. I'm 100% onboard with everything you wrote (especially "repeatable results"), except "Agile is a fad." Agile brought agile principles to the mainstream. And when you couple in the fervency of the Agile proponents, look for Agile to linger for quite some time, even upon the arrival of the "next big thing."
Reply | Reply with quote | Quote
0 # Kupe 2011-07-06 23:34
@ Duane, I'm saying the same thing. I just think "agile", the word, is a fad. And comparing agile to traditional is a fad. The manifesto shook the community and the principles are here to stay.
Reply | Reply with quote | Quote
0 # Sharon Burke 2011-07-06 23:53
I read this article with a great deal of interest. Over the years I've been fortunate to have worked with a variety of methodologies, tools and techniques. Each experience has allowed me to add to my personal "tool box". Early in my life as a BA/SA I was introduced to RAD (rapid application development) as well as evolutionary prototyping ... I agree with Andrew Blain's statement that "In the near future we will all have adopted agile approaches in our traditional methodologies but we will long have forgotten the source."
Reply | Reply with quote | Quote
0 # Dave Rooney 2011-07-07 01:32
I absolutely agree that almost 100% of what is considered 'Agile' has been around for decades. I've written about work that I did with a in the early 90's that was arguably quite agile - Google for 'Practical Agility' if you care to read about it. I'm also in 100% agreement with Scott Ambler's assertion that we need repeatable results. I know Scott and have followed his work for a decade. Where I would caution people, though, is when they latch onto Scott's words as a way to keep doing what they have always done believing that there is no way to improve. I was working recently with Craig Larman, co-author of "Practices for Scaling Lean and Agile" and he was able to articulate very well the issue with people choosing to go with "common sense". Using Lean terms, Craig said, "Almost everything you currently think of as 'common sense' is in fact a local optimization." While the term "Agile" is a fad, what it has done is to put the notion that close collaboration and iterative verification of assumptions are crucial to success to any development effort. I will be as happy as anyone when we no longer need to use the term "Agile", and the values and principles from the Manifesto are simply the way that we deliver software.
Reply | Reply with quote | Quote
0 # Josh Milane 2011-07-07 04:38
This is absurd. People were doing all these agile practices before the term was monetized upon. Not just in software, either. It is hardly a fad. It is just branding something that already existed. Josh
Reply | Reply with quote | Quote
0 # Josh Milane 2011-07-07 04:40
If the Manifesto shook you, I would suggest that you get a more stable foundation. Wanted to add that. It is not about the Manifesto. That is a lot of pomp and circumstance. It is about the intent, which is why it does not actually state anything but values on the surface. The manifesto should not shake anyone. What might, I suppose, is the intent of the effort - and that intent is not only to advance software. Thanks, Josh
Reply | Reply with quote | Quote
0 # David J Bland 2011-07-07 04:45
We need to move beyond "agile vs traditional" and instead have conversations about "known vs unknown". If you know the problem and solution, then traditional may be completely appropriate. I f you know the problem, but not the solution, then you'll need short feedback loops baked into the way you work to help guide you in your journey.
Reply | Reply with quote | Quote
0 # Dave Rooney 2011-07-07 04:54
@Josh, "This is absurd. People were doing all these agile practices before the term was monetized upon." They weren't doing Test-Driven Development. Most still aren't, either at the unit or acceptance level.
Reply | Reply with quote | Quote
0 # Dave Rooney 2011-07-07 04:56
@David, "If you know the problem and solution, then traditional may be completely appropriate." You know the solution? Really? How often do rewrites of existing systems go wrong? That would be a situation where the solution is known, right? I would also assert that in almost all the cases where the problem is known, it actually isn't. In this forum especially, how often do we hear that the problem was "unclear requirements". Isn't that a symptom of a problem that was believed to be known, but actually wasn't?
Reply | Reply with quote | Quote
0 # Adrian Wible 2011-07-07 05:01
I think using those 4 tips as a basis to form a conclusion that this is all old stuff leads you down the wrong path, particularly considering the import of the analysis component in an agile project (which I've often referred to as part of the agile "secret sauce"). I think dividing the work into valuable stories (vertical slices) is different from the prevailing practices in the past. I think the approach to decomposing functional requirements into independent, reorderable deliverables is different from the past and helps us eliminate Gantt chart project management in favor of delivering value earlier. I think that planning for changing requirements instead of booking up-front plans and executing on them is much more accepted due to this agile "fad". I think that focusing on defining acceptance criteria - the definition of done - has a front seat now and is at least much more prevalent now than before. I think the concept of measuring delivered software as progress was practically absent before agile ... being 20% done with your project when your architecture document is complete is no longer acceptable evidence of progress in the agile world. I think the concept of doing the simplest thing that could possibly work and then refactoring, rather than writing platforms and libraries (and counting it as progress) before delivering value is much more commonplace in our agile world. Agile has made the concept of evolutionary design more popular. I think the elevation of the role of testing (unit, functional, automated) and the tester has benefited from the agile movement. Mayb e you did all this before "agile". I assure you, it was not all commonplace. Even so, the agile "wrapper" has helped garner attention and spread the ideas much more efficiently than perhaps a movement titled "just use your common sense". I'm sure you were looking for the shock value in your title. But I would have titled it something like "Agile provides a wrapper around a bunch of concepts that have long been known by professional software development practitioners as common sense and adds a few new wrinkles". - Adrian
Reply | Reply with quote | Quote
0 # Paul Boos 2011-07-07 05:04
"This is absurd. People were doing all these agile practices before the term was monetized upon. Not just in software, either. It is hardly a fad. It is just branding something that already existed. " - Josh Milane Then why oh why did central SDLC managers show up and prescribe the ways things had to be done on every project. Projects would fail when they followed the SDLC to the letter. the focus was on the process and not the results. Agile may be a 'brand', but it coalesced the values and principles into something useful that could cut across a variety of different approaches (methodologies if you prefer). So they may have existed, but at least in the software world even a few years back, not widely accepted as wisdom. I'm with Glen Alleman (and we don't often agree), it's about context. Look at what works. The values and principle of the Manifesto give the team power in the organization to define a repeatable process (with the ability to improve/change) baked into it. And that is because they are focused on results. The whole Manifesto is a framework about putting control into the cross-functiona l team who needs it as opposed to some outside group prescribing any process on them in the name of governance. (Incidentally, there may be a need for governance, but that should be focused on results (the product) as well IMHO.) David Bland has the right starting point for this context based on results; how known vs unknown is what you are doing? The more unknown, the more it is a discovery "process" and the more change the "process" will undertake until it stabilizes through rapid improvement driven by feedback on the results. The team is the one to do this. The only thing I agree with on Josh is that several folks have monetized the word 'Agile' and these usually are folks that have really sold things that are non-Agile as Agile. I'll agree with Dave Rooney that when folks apply these values and principles and get repeatable results regularly, then we will no longer need the word. Until then, i'll welcome having the 'brand' to help distinguish the need for close high bandwidth collaboration and rapid verifiable feedback. Kupe , I am not sure I agree fully with how you said everything, but the gist of it is correct. Paul
Reply | Reply with quote | Quote
0 # David J Bland 2011-07-07 05:05
@Dave I'm not arguing that we always fully know the solution, but there is a range to which I feel traditional is appropriate. If the solution is mostly known, then why not use traditional? Y ou could use agile even if the solution is mostly known, but from my perspective that is a matter of taste, not success or failure. I believe you are correct in that we often convince ourselves that we mostly know the solution when we in fact do not. That is a deeper issue from my perspective, and not a reason to blame traditional for all of our missteps.
Reply | Reply with quote | Quote
0 # Paul Boos 2011-07-07 05:31
@Dave cc @David one area traditional (although I'd still plan to deliver incrementally) may be something that is fully "physics" oriented; say missile control software. The physics fuel burn, payload, distance to travel, etc. are known. There is no UI, the user doesn't do anything (that would be the launch control to feed in the target, which may need a more Agile approach as in the 'best' way to develop it). That would be a differentiating context. Same might be with safety software to control shutdown of a nuclear reactor. If X set of parameters occur, then begin shutting down things in the order of 1, 2, 3...). Again the software that a user does to control the reactor on a daily basis may need to be developed in an Agile way though since a user is in the loop. Why do I make the contextual difference? Well if physics is driving your design, then you can know it upfront (presuming it is known physics... otherwise the physics has to be researched up front). I struggle though with using a traditional approach once I put a human in the loop.
Reply | Reply with quote | Quote
0 # Robert C. Martin 2011-07-07 07:12
I think that the use of the word Agile is as much of a fad as the use of the word fad is a fad. As one of the founders of the movement I have my own concerns about the direction that movement is heading, but it (or it's label) being a fad is not one of them. Both the movement and the label are over a decade old at this point, and each year has seen only an increase in popularity and adoption. That is not the signature of a fad. Pardon me for latching on to the word "fad", but the word is often used or perceived as a pejorative. Agile should be criticized for the things that are truly amiss with it. Being a fad is not one of them.
Reply | Reply with quote | Quote
0 # Kupe 2011-07-07 10:17
@Adrian- the editor at BA Times would not let me use a title that long! The issue is the abuse of the word agile. I think we are all on the same page when we say the movement and the principles of the manifesto are helping the community focus on value. But the talk should be focused on implementing the principles rather than teams feeling they can't be successful unless they are "agile". @Paul, we are on the same page. I think teams/companies are excited about agile, but also scared because how it is pitted against traditional methods as being completely different. It is importantbfor everyone to know the principles are just smart practices and companies can start implementing them and evolve. They don't have to co-locate their teams and start 2 week sprints over night. @Robert, the point I made at the end was the agile principles is a trend. That's where the focus needs to continue. Thanks to everyone for adding to the conversation! Thanks everyone for adding to the discussion.
Reply | Reply with quote | Quote
0 # Cameron 2011-07-07 12:51
Iterative development has been around for a long time and has had a decent balance between delivery date and change. Agile tends to be successful where the stakeholder is willing to sacrifice delivery for prototype. By this I mean the final solution will take 3 to 4 times longer, but the stakeholder did not have to make a decision without seeing the product. I have heard of Agile working well IF the stakeholder sits close and can make the final decision. But in over 15 years I have never been on a project with a single stakeholder.
Reply | Reply with quote | Quote
+1 # Godfrey de Zilla 2011-07-08 19:01
The typical ways of identifying a fad as opposed to something more durable say, understanding of Gravity, Calculus etc... is that fads, 1. Never have clear cut definitions leading to endless quasi-religious argument about what is the true meaning of the Fad 2. Never have any clear cut empirical evidence that they work. Anecdotal stories, professions of faith that things were much better because of following the fad are easy enough to produce if there is enough hype and enough true believers but it's much harder to say, the was better because or this is what would have happened otherwise etc.. that should generally be enough to indentify the fad but of course in the end there is the third attribure of fads 3. Thy fade way when either the next fad comes along or if something comes along that doesn't just work but van prove that it works and why it works.
Reply | Reply with quote | Quote
0 # Karan Jain 2011-07-09 18:47
I agree with some of the comments above. Project will always be a project, time, cost, scope and quality. We do have to get creative at solving problems and some in-built mechanics of agile software delivery process help us along. One thing I would add is that how we approach to do the work has changed. As I recently told a group of BA professionals @ BA World that the goal is not be agile, the goal is to get faster, better, cheaper. Agile/lean is one of the tools to get us there, and one should'nt claim to be agile. Rather striving to be more agile.
Reply | Reply with quote | Quote
0 # Becky Sims 2011-07-10 23:15
Great article. I have been using the same techniques for over 30 years. About every 5-7 years or so, a new 'conceptual' name comes into play. New name, same techniques. As stated, you do what is right for th project and the business.
Reply | Reply with quote | Quote
0 # rduboistx 2011-07-11 02:27
Stakeholder management, stakeholder engagement. Common sense, common sense, common sense. Do what's right for the team, the information they need in the form that they need it in order for them to be successful. Thanks Kupe!
Reply | Reply with quote | Quote
0 # Scott 2011-07-12 09:56
Agile is neither a fad nor an iterative project management methodology. It is the (lazy) developers attempt to dis-integrate the BA. "Who needs a bunch of documentation? The next guy can always reverse engineer our code. It has a lot of comments." It also has business working directly with developers with no notion of the "big picture" or the end in mind. Phooey
Reply | Reply with quote | Quote
0 # bill545 2011-07-14 02:27
Scott, respectfully disagree that Agile is some developer's attempt to do anything, as typically it is the PMs/execs who mandate it, not the developers. As for Agile in general, the point I took away from this is that much of what is considered "Agile" isn't exclusive to "Agile methods" (amen)....and as many have said here, common sense should rule the day, not silly buzzwords and trendy "look I'm doing the new cool thing too" sheeple mentalities. And it's not the first time it's been said, but bears repeating, so props for that.
Reply | Reply with quote | Quote
0 # shaker 2011-07-16 19:16
Pretty brave stance to take, but truer words were never spoken! After 30 yrs in IT developing software and consulting I can say that Agile did not/does not discover anything new except a whole bunch of new buzz-words and phrases, diagrams and charts to do what good software developers have practised for years. I remember developing commercial software in 1985 with a team of 7 people talking every morning about what we had to do, evolving the software, demonstrating to my investors every Monday what we had completed. They weren't excited by detailed 500page Functional specs but by working, visible software. Lean! In 2001, I worked with a 5-man team that developed a web-based distributor management portal that would fit right into todays popular scrum/user story/TDD model. We didn't call it Agile and none of the people in the team even knew the word in the context of software development. It was just the best way for us to deliver the desired business goal. I've been officially practising Agile for the last 8 years and I find it really easy, not because its better, but because its what I'm used to. And this goes for a lot of people I've worked with over the years. Getting the cooperation and collaboration within a team has not changed from30 years ago and has nothing to do with Agile or Waterfall. Als o, a reminder - it is the Agile SOFTWARE DEVELOPMENT manifesto - and not the agile PROJECT MANAGEMENT manifesto.
Reply | Reply with quote | Quote
0 # Craig McLean 2011-07-17 15:14
This is a great debate. Ironically, just when we are in danger of reaching consensus, the advent of industrialisati on tools may make this debate redundant. In fact, it could be argued that none of the methods mentioned - Waterfall, RUP or Agile - address the root causes of software development issues: a) users need something tangible in order to validate correctness and completeness and b) coding is slow because it's a manual, intellectual activity. So now that automation and visualisation tools allow a BA to "prefabricate" a working, interactive set of screens, with data, rules and workflow built in, our processes will to change significantly. Well beyond these methods and attitudes. Documentation is replaced with a "working" application which will please the Agilists. However 100% of the requirements are "visualised" before any work is done on databases, interfaces or complex rules so this is more like Waterfall. You can still iterate if you want but now the application evolves on a daily basis. Much of the Architectural concerns are built into the platforms which support this style of development, so early architectural risk mitigation, key to the RUP approach, is out of the game. So where does this leave the "Agile is a fad" debate? Well, when all your analysis work contributes directly to the working system - rather than to documentation - but with significantly faster and more effective validation and sign-off of requirements and zero to minimal rework, it leaves this debate in the dust. As a by-product it also allows the analyst to regain their rightful position as the most influential player in software development. Surely that can't be a bad thing.
Reply | Reply with quote | Quote
0 # David Morris 2011-07-26 05:38
A great opening to what should become an envigorating debate. Not sure about the word 'fad' however the gist being that there is too much concentration on something being agile or not, or even being pure agile, that it smacks of marketing and sales (or worse) and not on a pragmatic approach discussed between practitioners that respect one another's experience. Jim Highsmith said that the Agile Manifesto was mostly about the mushy stuff, "a set of values based on trust and respect for each other"; and remember it wasn't written in stone and brought down from a mountain (well at least it wasn't in stone) - so we should be able to healthily debate this. Let's keep a conversation going about what techniques work and in what context. However hard the delivery team strives to adhere to pure agile practices, if the organisation in which they're working has an old school approach to risk mitigation, the project will fail as surely as an overly plan-driven project in an organisation that wants to get their products to market and are happy with a constant beta approach.
Reply | Reply with quote | Quote
0 # Simon James 2011-07-26 12:25
Agile is for people who don't do detail. Experience has shown this project methodology does not work and in fact creates more work in the long term because nothing is documented. People left supporting the output from an agile project are left scratching their heads and asking "why is it doing that?" I have witnessed the output of an agile project costing in excess of $100M being turned off within 3 years of the project's completion. Agile is a waste of corporate time and money. If you are going to do something, do it right the first time. Don't take the lazy way out.
Reply | Reply with quote | Quote
0 # Horace 2011-07-27 01:09
I completely agree with you. Each project has to be evaluated to determine what needs to be done to deliver a quality product within the given constraints.
Reply | Reply with quote | Quote
0 # Kupe 2011-07-27 01:11
@Simon James - "Agile is for people who don't do detail." Your experience is probably with the people for whom I wrote this post for. I think Agile has been abused and misused. The principles of agile are what people need to focus on more than just saying they are an agile shop. As for documentation. Teams need to determine the right level of documentation needed. documenting for document sake is bound for failure too! Thanks for chiming in.
Reply | Reply with quote | Quote
0 # Kupe 2011-07-27 01:13
yes @Horace - That needs to be the overarching mindset for teams.
Reply | Reply with quote | Quote
0 # swiss IT bridge Facebook Page 2011-07-31 19:18
[...] Is Agile a FAD or not? Convincing arguments by "Kupe" and "Bob"[...] http://www.facebook.com/swissITbridge
Reply | Reply with quote | Quote
0 # sohail 2011-08-18 20:27
Nice artice Kupe, I am totally agreed with your comment that "agile movement is definitely a trend" but this trend getting very popular in the industry. My question is how succesfull Agile in the industry? Than ks, Sohail
Reply | Reply with quote | Quote
0 # Jerry 2011-08-23 07:04
Great article. Anoth er way to look at this, would you want to hire someone who was schooled in all the latest buzz words du jour, or someone who knew how to roll up their sleeves, and use common sense to determine and apply the proper tools (whether they had a cool, trendy name or not) for a specific task. Anything less would be a ScrAgileFallacy . :-)
Reply | Reply with quote | Quote
0 # Kupe 2011-08-23 19:58
@sohail - I am not sure, but I would say pretty successful. Those that really change their philosophy like Bob Galen pointed out in his post "Kupe - Agile is not a Fad" are probably very successful. Those that are saying they are agile, but really just going to code faster without the right collaboration are not successful. Scott Ambler has done some survey's about success, Google his name and you'll find the surveys. @Jerr y - that's a big reason for me getting this conversation started. Thanks for chiming in!
Reply | Reply with quote | Quote
0 # Swish7 2011-08-28 06:28
Great article Kupe, and comments everyone. In the last couple years I've been bloodied by what is essentially an agile/waterfall "war' in my organization. Agile is presented as if it was a silver bullet. Unfortunately it seems to be more about controlling the user engagement, than delivering what would be best for the company in the long term. "Oh, if we can only control the scope to what we can deliver with our limited resources! I often find myself excluded from user meetings because I am neither the user nor the developer. And months later after the developer and user have both quit we're often left with a black box solution. My situation is probably the worst case. Unlike my teammates, I actually have used an agile methodology, scrum. It certainly has its place. Unfortunately, my end users neither have the time to commit to the process for agile to be a success, nor to read my "waterfall" documentation. So, we end in IT going all herky jerky between the two approaches. Like someone mentioned above practitioners do turn it into a quasi-religious argument. It sounds great, but where are the results? It seems to me such a waste of time to have expensive developers in every user meeting. There has to be a common ground. I agree with agile's principles, and the comments here about collaborating and delivering results. The collaboration piece is where my teams do not execute well. They often "collaborate" with the wrong people, people who have a short term interest in the project. I'm curious if anyone has had an experience similar to mine? If so, how did you handle it?
Reply | Reply with quote | Quote
0 # Chas 2011-09-14 06:11
There are two types of software people. Those who write good code and then those that talk about how to write good code. Agile = Snake Oil.
Reply | Reply with quote | Quote
+1 # Johnny 2011-09-15 21:20
I can't really see the point of what you are saying. Nowhere have I read that Agile methods our new or groundbreaking. All of the early pioneers of the Agile movement allude to the fact 'Agile' methods have been used for years before the manifesto. The word Agile is used a blanket term for methods and approaches that address some of the inefficiencies of widely used standardised methodologies. Well done if you were adopting these practices before the term Agile was being used. However I would no more call Agile a fad than the motorcar. Worl d English Dictionary defintion of Fad 1. an intense but short-lived fashion; craze
Reply | Reply with quote | Quote
0 # Kupe 2011-09-15 23:04
My main point is that the word agile is a fad. There is so much talk of traditional vs agile. My feeling is projects should be run using agile principles. Therefore there is no reason to say you are an agile shop or a traditional shop. The principles are definitely not a fad...they are the trend.
Reply | Reply with quote | Quote
0 # John Quincy 2011-10-19 09:44
This video captures it all!!! http://www.youtube.com/watch?v=nvks70PD0Rs John
Reply | Reply with quote | Quote
0 # Claudia Thomas 2012-06-12 13:50
How true it is! Like so many other buzzwords, this one fits that definition. And yes, it does boil down to common sense - I too am in an environment where groups have gone from one extreme (not enough documentation) to another (too much). We find ourselves spending more time creating documentation and checking boxes than actually solving issues, and all of that time gets charged to the customer. Stupid!
Let's be realistic people - hire the right staff, then trust their experience to know what is not enough or too much, and how to avoid past mistakes.
Reply | Reply with quote | Quote
0 # Alan Radau 2012-12-11 18:32
Well said Kupe, actually in the old days we referred to this as common sense. But what is really interesting is the preponderance of software dedicated to Agile and sometimes wonder if it is more about selling a software solution as opposed to a real methodology. To be honest it smacks of pieces of Prototyping.

Best requirements I ever received were need new *** system, the rest was left up to the developers. Oddly enough over the years this grew and morphed, but in the end the system was delivered ahead of schedule, ahead of expectations and below budget(We didn't set the budget).
Reply | Reply with quote | Quote
0 # Dawn Swope 2012-12-13 15:30
Great article Kupe!!
Reply | Reply with quote | Quote

Add comment


Security code
Refresh