Agile
The Downside of Agile / Scrum Software Development Methodology

Agile

In software application development, Agile Software Development (ASD) is a methodology for the creative process that anticipates the need for flexibility and applies a level of pragmatism into the delivery of the finished product.  Agile focuses on keeping code simple, testing often, and delivering functional bits of the application as soon as they're ready.  The goal of Agile is to build upon small client-approved parts as the  project progresses, as opposed to delivering one large application at the end of the project.  With Agile, requirements and solutions evolve through collaboration between self-organizing, cross-functional teams.  It promotes adaptive planning, evolutionary development, early delivery, continuous improvement, and encourages rapid and flexible response to change.  The idea is to somehow get to market faster by doing two or three little tasks instead of one big task.  (This may be best represented by the curious equation:  3 * 2 > 1 * 6.)  
 
Waterfall

The waterfall model is a sequential design process, used in software development processes, in which progress is seen as flowing steadily downwards (like a waterfall) through the phases of conception, initiation, analysis, design, construction, testing, production / implementation and maintenance. 

While the waterfall method was popular in the 70s, 80s, and 90s, Agile has really taken hold over the past few years.  Unfortunately, it is being forced upon most software development shops, many of which would do better by sticking to the waterfall method.  I've even heard Agile gurus speak of the "evils" of waterfall, like an evil out-dated empire.  Before we examine the reasons for this, let's learn more how Agile works. 

Sprints

With Agile, small teams attack big problems in little chunks.  A "sprint" is a selected period of time during which a team agrees to produce these software chunks.  The length of the sprint is decided by the organization, but they're usually two-week or three-week periods.  The idea is that the little pieces of development can be demonstrated to the stakeholders at the end of every sprint, showing what the team is doing and making sure they're on the right track.  Often it's for identifying when to shut down development because the product being built isn't what the user wanted after all. 

Fail Fast, and Often

Believe it or not, this is not a typo.  Agile teaches us to fail fast.  You build a piece of a product in two weeks; you demo it for you stakeholders; they tell you that you're full of crap; so you chalk up a failure after only two weeks instead of spending two months on the failed design.  That's good.  It makes sense.  But, fail often?  Really?  Somebody didn't think this through. 

Stories

At the center of Agile development is the "story," the modern word for "requirement."  However, unlike its predecessor, it's short, vague, and loosely define. 

Story Points & Velocity

The "story point" is a way of estimating the effort of a story.  It's a key metric in evaluating the efficiency of teams, where "velocity" indicates how many story points a team can complete during a sprint.  The problem is that NOBODY knows what a story point is. 

Although Agile evangelists don't agree on much, they seem to agree that a story point is "arbitrary."  That's right.  It's something in the air that developers keep grasping at but never can harness.  I've actually heard it described as "unitless," supposedly to stress that it's not supposed to be tied to a period of time.  Furthermore, it is said to "evolve over time." 

Still, I've been on teams that have defined a story point as one hour, other teams that define it as one day (both violating the "time" rule"), and still others that define it according to complexity.  It doesn't seem to matter, as there's always some ambiguity to it.  In other words, it doesn't matter how much actual progress is made during a sprint, but rather how many arbitrary and unitless items get completed.  The idea is for any  particular team to be consistent in the way that it defines story points, so that over time it can measure velocity to determine how many story points it can complete in a sprint. 

However, in my experience, a story point is not only arbitrary and unitless, but also useless.  One reason for this (as if it was not adequately explained above) is that before enough time can pass in order for a team to establish its velocity, something is assured to change--for example, the mission of the team, the leadership, or team members start quitting. 

The truth is that, by definition, a story point must indeed be a measure of time because the sprint is a measure of time, and "velocity" is the number of points in that given period of time.  A story point is inherently a measure of time because two weeks IS a span of "time." 

Documentation

Unfortunately, Agile implies a lack of documenation.  This goes hand-in-hand with Agile theory--requirements and solutions "evolving," "adaptive planning," and "evolutionary development."  Students of Agile are taught to keep requirements and documentation to a minimum.  They even learn special ways of writing requirments--"As a user, I want ..., so that ..."  This keeps the acceptance criteria vague enough so that the testers can't be
too detailed about their expected results.  This way everybody's happy with whatever is delivered, right? 

Agile is particularly rough on QA because most stories aren't ready for test until the last day or two of the sprint, resulting in 16-hour days for the tester for the last couple of days of the sprint. 

Meetings

Now to the meetings!  Oh, the meetings!  Agile gurus, who have trouble defending all of the meeting time, will say that there are only three meetings:  planning meetings, stand-ups, and retrospectives.  What they mean is that there are three "types" of meetings (although there are others such as grooming meetings that they conveniently categorize under planning meetings).  In reality, there are dozens of meetings during each sprint.  A two-week (ten-day) sprint includes the following meetings:  a 2-hour sprint planning meeting; ten 30-minute daily "stand-up" scrum meetings (they're supposed to be 15 minutes, but they usually go over 30 minutes), a one-hour high-level grooming meeting, a one-hour team grooming meeting, and a 2-hour sprint  retrospective / demo meeting.  (I'm not sure, but I think the purpose of the demo is to make sure QA really tested what they said they did.)  

Then consider other meetings such as code reviews, bug triages, and unplanned meetings, as well as the prep time included for all of these meetings such as the time to plan what you're going to say and what you're going to demo.  Then that demo prep leads to a meeting where you discuss what you're actually going to demo.  Then there are meetings to discuss things like, "What's a story point?"  You can safely say that at least 24 hours (three of the ten days) of the sprint are consumed by meetings. 

Agile Meetings

Week Sprint
# Time # Time
Stand-up Meetings 5.0 2.5 hours 10.0 5.0 hours
High Level Grooming 1.0 1.0 hour 2.0 2.0 hours
Team Grooming 1.0 1.0 hour 2.0 2.0 hours
Sprint Planning 0.5 1.0 hour 3.0 2.0 hours
Demo Prep 0.0 1.0 hour 0.0 2.0 hours
Sprint Retro / Demo 0.5 1.0 hour 1.0 2.0 hours
Misc.--Demo, Devops 1.0 1.0 hour 2.0 2.0 hours
Daily Triage 5.0 2.5 hours 10.0 5.0 hours
Code Reviews 1.0 1.0 hour 2.0 2.0 hours
Totals 15.0 12.0 hours 30 24.0 hours (30%)


So, in reality, each person has only seven days instead of ten days to develop software.  With 26 sprints in a year, 624 of my hours, or 78 days, are spent in meetings every year.  That's 30% of my time.  For my current ten-person team, that's 780 person-days spent in meetings, or the equivalent of three person years--three more people (ten, instead of seven) needed to do the same amount of work.  As a member of an Agile team, you are a meeting attender--seemingly your primary role, instead of a software engineer. 

Because of the nature of all of the Agile meetings, software engineers are treated like undisciplined children rather than like adults.  For example: 

Stand-up Meeting Parody

The intimidating daily stand-up meetings take on a format where each member of the team, in turn, is required
to do the following: 

     - Literally, stand up. 
     - Recite what you did yesterday. 
     - Recite what you will do today. 
     - Recite what your roadblocks are. 

This is akin to a kindergarten teacher (the scrummaster) asking a child: 

Scrummaster:  "Johnny, what did you do yesterday?" 

Agile Johnny:  "I went to ..." 

Scrummaster:  "Stand up, Johnny." 

Agile Johnny (proudly):  "I went to ...six meetings." 

Scrummaster:  "Johnny, are you getting smart with me?" 

Agile Johnny:  "No, sir.  I almost finished two or my tasks." 

Scrummaster:  "Well now, that doesn't sound like very much work, does it?  Why didn't you do more?  Why didn't you finish those task?  Didn't I see you looking up something on the internet that was completely unrelated to your tasks?  Furthermore, didn't you call home to check on your sister who stayed home sick today?" 

Agile Johnny:  "Well, I do like my sister.  Umh, oh, I tested and closed four bugs.  But then, if you had just read your e-mail, you'd already know that from the automated messages you received when I documented them." 

Scrummaster:  "Don't get smart, Johnny.  We're Agile, and we don't give a shoeshine spit about documentation. 

So, what are you going to do today?" 

Agile Johnny:  "I'm going to work extra hard on another task, and stay off the inernet." 

Scrummaster:  "OK Johnny, now, what is keeping you from getting your work done?" 

Agile Johnny:  "Meetings like this one?" 

Scrummaster:  "Johnny?" 

Agile Johnny:  "Nothing." 

Scrummaster:  "What, you have no roadblocks?" 

Agile Johnny:  "Well, I had one right after yesterday's meeting, but I discussed it with Billy and we resolved it." 

Scrummaster:  "You what?  You were supposed to save that for the roadblock part of the stand-up meeting. 

That's the most fun time of the whole day--humilation all around." 

Agile Johnny:  "OK, I guess next time I'll sit around on the internet istead of being proactive." 

Scrummaster:  "Don't be a wise-guy, Johnny." 
 
Planning Meeting Parody

Then there are the planning meetings where you all get to play "planning poker."  Each player is dealt six cards showing the first six numbers of the fibonacci sequence--1, 2, 3, 5, 8, and 13.  Then the scrummaster says, "How much effort do you think this story will take?"  Then all team members simultaneously hold up one of their cards to answer the question, indicating how many arbitrary, unitless, and useless story points they think it's worth.  The object of the game is to arrive at the same number through appropriate reasoning and discussion.  (Have we no dignity?)  I usually just try to hurry the game along by being the last one to hold up my card, and agreeing with the majority.  After all, not only is a story point abritrary, unitless, and useless, the QA folks have no freakin' idea about the complexity of the developers' Java code, and the developer mutually has
no clue about the level of manual and automated testing required: 

Scrummaster:  "Johnny, why do you think the effort is only two arbitrary and unitless story points?  Billy thinks that it's three." 

Johnny:  "Because..." 

Scrummaster:  "Because why? 

Johnny:  "... Just because." 

Scrummaster:  "Just because why?" 

Johnny:  "Because it's easy?" 

Scrummaster:  "OK, Billy, why do you think it's three arbitrary and unitless story points?" 

Billy:  "Because it's hard." 

Scrummaster:  "Well Johnny, due to the time that we've already wasted on this, Billy is right--it's three arbitrary, unitless, and useless story points, thanks to you.  Please try to be more accurate with your estimates from now on." 

Retrospective Meeting Parody

Then comes the retrospective meeting when a (grown-up) software engineer is asked to "demo" the results of what he did.  This is a lot like show-and-tell in the first grade when the teacher says: 

Scrummaster:  "Johnny, it's your turn.  Go to the front of the room and tell us about the features and bugs you fixed in your software application." 

Agile Johnny:  "I fixed a typo.  It used to say "The scrubmaster sucks," and I changed it to:  "The scrummaster sucks." 

Scrummaster:  "Nobody cares about that crap, Johnny." 

Agile Johnny:  "Well you told me to show you what I did." 

Scrummaster:  "Get on with it, Johnny.  What else did you do?  Tell us something important this time." 

Agile Johnny:  "Well, I improved performance and enhanced security by refactoring all of our asynchronous calls." 

Scrummaster"  "Yeah, everyone in the room already knows that you already told us during this morning's stand-up meeting.  Stop bragging.  Anything else?" 

Agile Johnny:  "No, I think I've shown enough."

Rules Are Made to be Broken

Agile has many hard and fast rules that are always broken.  For example: 

When a sprint begins, it is "locked down" (like after yard time in prison).  It's unacceptable to add anything to a sprint once the sprint begins, yet its done all the time, without apology.  This is often the result of the team being heavy on developers and light on testers.  So, when one of the developers runs out of work, more stories are added to the sprint for him, which results in too much work for the testers, so it's the QA
guy who's working overtime. 

Then of course there are the stories that need to have their estimates changed. Somehow the project manager finds a way to unlock the lock-down, crank up the estimate, lock it down again, and see how the team reacts to more work than they can do. 

Somtimes they decide to run the sprints from Wednesdays through Tuesdays instead of Mondays through Fridays--Go figure.  I think it's for added frustration. 

Quality

One of the things you learn when you attend your initial full week of training on Agile is what happens when you can't get the work done (which is usually the case in every sprint)--like when you've underestimated the effort required for a story, or you have unexpected production crises or support issues to deal with.  Something's got to give, and you have three choices:  1) Time / deadlines; 2) Content; or 3) Quality.  You
can't allow more time because you're locked into your two-week sprint deadline, and another sprint starts on Monday.  You can't remove content from the deliverable because the development manager has (over-) promised the functionality for the release.  So what else is left?  Quality.  Quality suffers because of inqadequate time for testing, and everybody wonders why the stakeholders aren't satisfied with the product. 

Agile Popularity

Yet, Agile is now used in some 90% of software development shops.  So, why is Agile so prevalent?  I think a lot of it has to do with personality types.  Generally speaking, the Type A personalities like to talk, they like to hear themselves talk, they think that everybody likes to talk, and they like to have a lot of meetings.  By definition, they're also the decision makers in the organization--executives, project managers, and product owners.  So they decide that meetings are the way to go, while the Type B personalities, including the folks who actually write and test the code, don't feel like they have the authority to push back on all the meetings.  Yet I could build a case showing that Agile takes more people and more time (due to 12 extra hours of meetings each week, as well as failing fast and often) to build a product with lower quality than what the waterfall method would produce. 

Lessons Learned

So how do we Type B personalities cope with this?  Well, after about 40 years of experience in this industry, I've found that the answer is to just wait it out.  I've seen top-down programming, structured programming, object-oriented programming, waterfall, and now Agile.  In a couple more years we'll all give up on it too, and start down another "arbitrary" path. 

Video: 

Agile is a software development methodology where, well, meetings take precedence over software development, documentation and productivity.  Because of the nature of all of the Agile meetings, software engineers are treated like undisciplined children rather than like adults. 

Meeting Skits: 

For example, the intimidating daily stand-up meetings take on a format where each member of the team, in turn, is required to literally stand up, recite he did yesterday, recite what he will do today, and recite what his roadblocks are.  It usually goes something like this: 

Stand-up Meeting Skit:

Scrummaster:  "Johnny, what did you do yesterday?" 

Agile Johnny:  "I went to ..." 

Scrummaster:  "Stand up, Johnny.  Remember, All Hail the Agile Gods." 

Agile Johnny:  "All Hail the Agile Gods..." (proudly) "I went to ...six meetings." 

Scrummaster:  "Johnny, are you getting smart with me?" 

Agile Johnny:  "No, sir.  I almost finished two or my tasks." 

Scrummaster:  "Well now, that doesn't sound like very much work, does it?  Why didn't you do more?  Why didn't you finish those task?  Didn't I see you looking up something on the internet that was completely unrelated to your tasks?  Furthermore, didn't you call home to check on your sister who stayed home sick today?" 

Agile Johnny:  "Well, I do like my sister.  Umh, oh, I tested and closed four bugs.  But then, if you had just read your e-mail, you'd already know that from the automated messages you received when I documented them." 

Scrummaster:  "Don't get smart, Johnny.  We're Agile, and we don't give a shoeshine spit about documentation.  So, what are you going to do today?" 

Agile Johnny:  "I'm going to work extra hard on another task, and stay off the inernet." 

Scrummaster:  "OK Johnny, now, what is keeping you from getting your work done?" 

Agile Johnny:  "Meetings, like this one?" 

Scrummaster:  "Johnny?" 

Agile Johnny:  "Nothing." 

Scrummaster:  "What, you have no roadblocks?" 

Agile Johnny:  "Well, I had one right after yesterday's meeting, but I discussed it with Billy and we resolved it." 

Scrummaster:  "You what?  You were supposed to save that for the roadblock part of the stand-up meeting. 

That's the most fun time of the whole day--humilation all around." 

Agile Johnny:  "OK, I guess next time I'll sit around on the internet istead of being proactive." 

Scrummaster:  "Don't be a wise-guy, Johnny." 

Planning Meeting Skit:

Then there are the planning meetings where you all get to play "planning poker."  Each player is dealt six cards showing the first six numbers of the fibonacci sequence--1, 2, 3, 5, 8, and 13.  Then the scrummaster says, "How much effort do you think this story will take?"  Then all team members simultaneously hold up one of their cards to answer the question, indicating how many arbitrary and unitless story points they think it's worth.  The object of the game is to arrive at the same number through appropriate reasoning and discussion:  

Scrummaster:  "Johnny, why do you think the effort is only two arbitrary and unitless story points?  Billy thinks that it's three." 

Agile Johnny:  "Because..." 

Scrummaster:  "Because why? 

Agile Johnny:  "... Just because." 

Scrummaster:  "Just because why?" 

Agile Johnny:  "Because it's easy?" 

Scrummaster:  "OK, Billy, why do you think it's three arbitrary and unitless story points?" 

Agile Billy:  "Because it's hard." 

Scrummaster:  "Well Johnny, due to the time that we've already wasted on this, Billy is right--it's three arbitrary, unitless, and useless story points, thanks to you.  Please try to be more accurate with your estimates from now on." 

Retrospective Meeting Skit:  

Then comes the retrospective meeting when a (grown-up) software engineer is asked to "demo" the results of what he did.  This is a lot like show-and-tell in the first grade: 

Scrummaster:  "Johnny, it's your turn.  Go to the front of the room and tell us about the features and bugs you fixed in your software application." 

Agile Johnny:  "I fixed a typo.  It used to say "The scrubmaster sucks," and I changed it to:  "The scrummaster sucks." 

Scrummaster:  "Nobody cares about that crap, Johnny." 

Agile Johnny:  "Well you told me to show you what I did." 

Scrummaster:  "Get on with it, Johnny.  What else did you do?  Tell us something important this time." 

Agile Johnny:  "Well, I improved performance and enhanced security by refactoring all of our asynchronous calls." 

Scrummaster"  "Yeah, everyone in the room already knows that you already told us during this morning's stand-up meeting.  Stop bragging.  Anything else?" 

Agile Johnny:  "No, I think I've shown enough." 

To read more, go to www.christiandataresources.com/agile.htm.