Data Driver

Blog archive

Is Agile Really a 'Developer Rebellion Against Unwanted Tasks'?

I recently wrote about an analyst firm's report on Agile software development that basically blasted the movement, calling it "a developer rebellion against unwanted tasks" and saying it's "designed to sell services."

Okay, this issue isn't strictly database development-related, but it brings up some interesting questions, so I'd like to get your opinions. Some 25 people had commented on the article as of Monday morning, and it was picked up by Slashdot, where it exploded with more than 477 comments.

As usual, the comments were all over the map. Many agreed with the analysts' premise; many vilified them. But I found a couple things especially intriguing. For one, many people still seem unclear as to what Agile actually is. The analyst firm, Voke Inc., based its definition on the Agile Manifesto and its 12 principles. But the analysts note that commonly used associated term such as Scrum and Extreme Programming aren't even included in the manifesto.

They wrote:

During the course of daily business we frequently encounter people who use the term Agile. We consistently ask for a definition of how the word is being used and defined. Frequently, the first response is a laugh followed by a lengthy response that concludes with a statement that there is no real definition for Agile.

That seemed to be borne out on Slashdot, where one reader defined it as:

Agile is a development methodoloy that radically changes the way software developers work. Instead of the typical role of "manager", "designer", "programmer" and "tester", these are split into "chief", "baker", "garbargeman", "clerk" and "monkey". You can probably imagine what each role is responsible for". Typically you work in subteams of three of these disciplines, unless ofcourse you have three "bakers", in which case a "chief" must be added to the subteam. These subteams are further divided in a "major" and "minor" roles, where the majors are responsible for all typing work and the minors documents progress. Every 2-3 hours these minors meet in a decentralized location and synchronize progress, so all subteams keep working at the same pace. At the end of the day all subteams commit their current state of development to a centralized repository and automated builds compile everything overnight. At the last day of the week, all these daily bugreports are filtered by the minors and relayed back to their majors for fixing. Iterate this for however long it takes to complete the project and you're done.

Yet another wrote:

Agile is a particular process for getting things done, which became trendy in software development in particular about a decade ago. It's main tenet is to do work on short cycles, delivering the result to the customer, and then allowing the customer to define the next priority. The hope is that this continuous delivery model avoid the primary pitfall of longer software development cycles, which is spending months/years developing something, only to discover that the requirements were poorly defined at the start (and that the product therefore doesn't meet the real needs), or that market trends have rendered the result pointless.

Not too helpful. How can we meaningfully discuss the effectiveness of Agile software development if there's so little consensus as to what it really is? There's lots of good debate as to its effectiveness, but are the debaters discussing different things? Does someone need to be in charge here? Or is Agile just a basic framework that companies are customizing for their own needs, so it means whatever each company wants it to mean? If so, aren't developers debating apples vs. oranges?

The analysts, who received more than 100 unique definitions of Agile in their survey of 200 people, eventually interpreted Agile as "doing less faster to get ongoing feedback." Does that definition work for everyone?

Also, the report seemed to take some digs at developers themselves (not just management, who are always easy targets). In a section titled "Agile as an Excuse," they wrote:

Survey participants report that developers use the guise of Agile to avoid planning and to avoid creating documentation required for future maintenance. One participant indicated that negative connotations of both Agile and Waterfall are affecting morale. Some aspects of the Agile movement appear to agitate developers into pushing back on essential tasks that are valued less on the whole by the Agile movement. Based on our survey, unprofessional behavior under the guise of Agile is not going unnoticed. We received some unprecedented scathing and shocking comments about the level of competence, professionalism, and attitudes of some members of the Agile movement.

In another section, they warned:

Be aware that the Agile movement might very well just be either a developer rebellion against unwanted tasks and schedules or just an opportunity to sell Agile services including certification and training.

So who's to blame here? Management for not strictly following Agile precepts, developers making an excuse to do their own thing, or consultants and the like trying to use the movement to sell their own brand of services under the guise of Agile?

I'd love for you data developers to share your own experience with Agile. Please comment here or drop me a line.

Posted by David Ramel on 07/17/2012 at 1:15 PM


comments powered by Disqus

Reader Comments:

Sat, Feb 2, 2013 Braen Purchase Lipitor

The analysts, who received more than 100 unique definitions of Agile in their survey of 200 people, eventually interpreted

Fri, Jan 25, 2013 Klavdia Purchase Lipitor

The analysts, who received more than 100 unique definitions of Agile in their survey of 200 people, eventually interpreted

Mon, Jan 21, 2013 Steve Naidamast New York

Agile Software Development is not true software engineering though many like to claim it is. It is an outgrowth of the XP development paradigm in the late 1990s\early 2000s that was created for the Chrysler C3-Payroll System project team. In the 5th year of the project using XP the entire project collapsed but by then XP had been successfully promoted as the "new way" to develop software. To rectify the "stupidity" of the XP paradigm, the Agile Development paradigm was born and took center stage. However, there was absolutely nothing new about this paradigm in the way most IT organizations implement it, which was merely sugar coat very sloppy development practices to management with the new "buzz words" of Agile Development. Back in the heyday of the mainframe we used to call such development practices, "guerrilla programming", which is to say we did not really design anything we instead just reacted to what our project managers wanted. To be fair however, Agile Development is merely a re-introduction of the original software engineering paradigms of evolutionary or iterative development. However, Agile is always compared in a better light to the original "Waterfall" development approach which is in reality only one of 13 primary development paradigms. However, since most software managers in business organizations have no competence in managing software development in the first place, they often view the discussions around Agile Development in black and white terms in an effort to get away from the original approach of software development that was primarily used at the dawn of commercial business software development since it was correctly found to be highly inefficient for the development if distributed systems. However, any software development paradigm requires good planning and design to support development if quality products are to be produced and it doesn't matter which one is used. Though Agile Development may not specifically attempt to eliminate these vital practices its use by most technical managers in effect lands up doing away with such processes always in the attempt to speed things along... Yet these same people will claim they are using Agile Development practices. I worked with a true Agile team of developers but we actually adhered more to true software engineering practices and produced good software under terrible pressures. Had we followed the standard and accepted regimens of software development that are highly prevalent even in purported Agile environments we would have crashed and burned... Though the Agile paradigm actually reflects solid software engineering implementations that have been known to be highly successful, this paradigm is still at the mercy of corporate cultures which more often than not reflect an acceptance of mediocrity...

Thu, Jan 17, 2013 Himes Buy Zoloft

Most of us are willing to be Scotty and pull that extra 10% of warp core efficiency out of our asses when needed. But if you want our best work you have to be willing to give us yours.

Wed, Aug 1, 2012 Tom Pittsburgh

As an end user to Minnesota Developer - The problem with your comments about better requirements, please understand that to the end user, the requirements are how it looks and how it reacts. Some things that are obvious questions to you are completely opaque to us. Likewise, many of my obvious assumptions are not very obvious once you get down to defining the ruleset in computer language. It is true that the requirements set forth to programmers are rarely complete, and many times the user feels let down because of this. However, remember that communication goes both ways - Many programmers I know take such pride that they refuse to ask when they reach a fork on how something should work. They make a guess assumption that (usually) is the easier to code and go that route. My experience is this is just as often a source of disappointment for the end users who are often very grateful for your skillset that they would otherwise have to do without.

Thu, Jul 26, 2012 Doug Seattle

Agile was developed as a result of the failure of the waterfall method. Spending months specifying every nook and cranny, then more months coding, testing, and debugging, only to find you produced something no one wants. Agile means starting with a vague idea of the end product. Every so often, say 2 weeks, you produce yet another version with more functionality. You take whatever user feedback you get and adjust. Every morning you have a stand-up meeting where you discuss any blocking problems, etc. If it looks like you are going to be finished early (before the 2-weeks is out), the team decides what to do. If you need more time, the team also decides what to do. At every 2-week milestone you re-prioritize the remaining tasks. You also see whether you have been accurate in estimating tasks and based on the remaining tasks, adjust the delivery date as required. If the delivery date is hard-coded and you have more tasks than time, you drop off the less important features. If you have more time than tasks (hey, it happens), you then decide whether to move up the delivery date, or add more features. The major premise is that you get feedback early and often, and adjust sooner rather than later.

Wed, Jul 25, 2012 Ira Clearwater, FL

I did agile development at 3 different companies. In all cases there was a "scrum master". "Sprints" were a week long in all three cases. In all 3 cases the "backlog" was divided up into little tasks and completion times were assigned to each task. "Scrums" or "stand-ups" were daily 30 minute meetings where developers stated their progress or non-progress from one day to the next. Requirements were not documented prior to working on the tasks. No documentation was done in either case. The lists of tasks were in spread sheets or in a task Management application like Rally or something homegrown. Points were assigned to every task. These points were weighted and were subtracted from the total when the task was competed. This was necessary to determine the "burn down" rate. In all cases there were coding standards. Areas of the application where benchmarking or performance analysis was necessary to enhance performance wasn't given any special emphasis like usual. Hence performance became an issue in the final product. Missing a deadline on any task regardless of the reason--was met with contempt. From my personal experience, I call Agile development the pressure cooker. I do not think that developers do their best work under that kind of pressure. Most folks are prone to making more mistakes and overlook important details when working under pressure.

Wed, Jul 25, 2012 Minnesota

As a developer myself, I have some serious hate put towards the various catch phrases and buzz words that float around our industry. In my, not so humble, opinion the following things are needed for software development to be effective and for the end user/customer to be happy: 1. Clear and concise requirements from the outset. Without these how can anyone expect developers to deliver a product that is useful. 2. The end user/customer must know what they want. If they have a vague idea that they want to be able to perform data entry for a database, then they shouldn't be upset when they get a single web page without graphics or "proper" layout but are able to perform the data entry. 3. Realistic expectations. Everyone from the client to the developer to management must have realistic expectations about what the software can and cannot do, how much time things will take and deadline management. Once those things are understood then the developer(s) can go back and determine what can be done and how long they expect it to take. The developer can break down the overall task of creating a piece a software into smaller deliverables that they can then set deadlines for. The client needs to understand that developers will give them what the requirements dictate and more often than not, not much more. This is because management is usually breathing down our necks to get it done and pushed out so we can move on to the next money making venture. I don't know how many times I have heard, "That may be what I said I wanted, but that's not what I meant." Then the developers get blamed for not understanding the requirements correctly. If you ask for something we will take you at your word that is what you want and meant. If there is a breakdown in communication of requirements it's not been my experience that it was the developer who didn't understand the requirements, it was the client who didn't define them enough. Sure some developers are lazy, some are even really lousy at their jobs and should be flipping burgers at Burger King. But, most of us know what we're doing and are proud of what we do. We take pride in what we do and take it personally if the client thinks we have failed them. Most of us are willing to be Scotty and pull that extra 10% of warp core efficiency out of our asses when needed. But if you want our best work you have to be willing to give us yours.

Tue, Jul 24, 2012 JohnnyB Colorado

Agile, unfortunately became a band wagon everyone wanted to jump on because of the advertised benefits. In my experience, most places are "Agile" (at least they say so) yet very few actually adopt the disciplines that make agile work. For example, few places ever designate a product manager to prioritize and manage the product feature requests (backlog) so development can prioritize and deliver what is most valuable and then they wonder why the results are not what they were promised. Other places are not willing to put the time and effort to properly plan a sprint, yet they are "Agile". It sounds good but without the discipline to implement the practice of Agile development, most shops fall way short and many developers and managers are left with a bad taste in there mouth wondering what all the buzz was about.

Tue, Jul 24, 2012 Fred

I agree with the thought that devs using agile as an excuse to avoid documentation and analysis. I've found that if devs have a very strong knowledge of the business then this lazy form of agile can actually work. But heaven help any new devs that get brought onto the team. They will be lost and confused! IMHO, the best agile type project that I worked on that was actually successful was one where we divided up features over 3 QA builds. Our analyst thoroughly documented the requirements for all QABuild1 features; once analysis was complete we started development on QABuild1 features while he began documentation of QABuild2 features. We completed this process until the final ReleaseBuild. This process allowed the business to see progress throughout the entire development cycle. The key to it all working though was having a great analyst and well defined requirements. The guy we worked with came from Boeing and was very thorough and disciplined in his ability to gather requirements. You have to be when peoples lives are at stake. You cannot expect to half-azz you way thru the analysis process and have everything come out all rosy in the end. Management must be held accountable for whether or not they allow a project to be executed without clear documented requirements. Devs love to code but are scared to death of MS Word. So mgmt must be strict in either ensuring that devs do the required analysis and documentation or in ensuring that they have dedicated analsysts to gather requirements. It doesn't matter if you are doing agile or waterfall. Thorough and clear analysis of business requirements is the key to a good project. Cut that out and you will fail everytime regardless of what "methodology" you use.

Tue, Jul 24, 2012 Hero

I'm in my second position that claimed to be using "Agile". My experience is Agile is an excuse to not think things through and not document requirements. My current boss says things like "my ideas are lumps of clay... they are not fully formed". Yeah, thanks a lot Agile for making me do all the design and run around getting feedback from all the stakeholders on how something should actually function. I'm not saying you need to define things down to the smallest detail but a little up front thought and architecture goes a long way toward making better code and better products in the long run.

Sun, Jul 22, 2012 Coderender

First up its the management to be blamed. They take up Agile because a few heads get together in a room and decide to go for it without even bothering about the people who would actually do it! I have seen managers who get carried away by a very rosy picture presented by architects which they brand as Agile and then dump all the hard work on the developers on whom the axe always falls. This is an alarm for everyone in the industry, the programmers, the to-be managers and the managers. We have just started to implement Agile, which btw has been slapped on the team without anyones consent because the head org that we belong to decided to implement it. Now we have white boards, red boards, sticky boards and what not wherein the managers of concerned teams stick notes for backlogs and their job ends there. I asked once a manager from testing team, Who's effort does it take to shift a single sticky note from 'Not Started' list to 'Done' list? He looked at me and gave smile. I don't have to write what that smile meant.

Fri, Jul 20, 2012 Yuri Sokolovski

I am really surprised by the report and lack of consensus among developer crowd. To me its bad news - the level of general ignorance goes up, people simply don't read anything anymore. I will insist that reading a Wikipedia definition is enough to understand on a basic level the difference between agile and non-agile way of developing software. Agile is the result of decades of software development experience by the myriads of programmers. Many of its premises are not new and are proven by hard facts. So the real problem I think is ignorance, inability to change and fear of failure.

Thu, Jul 19, 2012 Brett Toronto

I’ll second Mike’s comments. My last job of 13 years was waterfall, but as the company grew the shortcomings of that methodology were becoming apparent, so management decided to “go Agile”. Of course, going through the nonsense of designating Scrum masters, creating stories, standups, using common tools to track sprint burn downs, was deemed unnecessary. Instead, they just broke down whatever they wanted done into 2 week chunks, dropped it on your lap, and came back 2 weeks later asking to see what you accomplished.

I’m working in an Agile place now, and I’d sum it up this way: Agile is the worst development methodology in the world, except for all the rest.

Wed, Jul 18, 2012 Mike San Diego

Management was to blame at my last gig. They latched onto the buzzword of "Agile" and viewed it as a way to reinvent themselves as "Computer Scientists" when there wasn't a single tech degree amongst them. The team size was inadequate, the expectations unrealistic, and the ignorance was overwhelming. I had a "requirements meeting" that was 40 powerpoint slides, that ended with "when will you be done with this?" We had competition from outside vendors that made promises that they would "do Agile right" and deliver products in days/weeks as opposed to my timelines in months. Management bought off on the projects, 1 year later we still didn't have a functioning product. The vendor lost the job for nondelivery, the rest of us got broomed for making management look bad.

Add Your Comments Now:

Your Name:(optional)
Your Email:(optional)
Your Location:(optional)
Comment:
Please type the letters/numbers you see above

.NET Insight

Sign up for our newsletter.

I agree to this site's Privacy Policy.