No good data? Make it up

A friend of mine just recently came back from an Agile software development conference in Florida. Did you ever find it at least slightly odd that all conferences seem to be held in really nice places? Nobody ever says “come to a conference in Idaho.” Some part of me suspects that people don’t go to conferences to actually learn, but for the sightseeing/vacation opportunity.

Anyway, apparently Alistair Cockburn presented at the conference, and (I’m getting this second hand now) he showed a chart about how Agile improves knowledge gain…

It looked something like this:

Notice that it is unit-less on both axes. The cost axis you could almost forgive, since we have some intrinsic knowledge about what it means for something to cost more. Knowledge on the other hand… I don’t know how you measure that. I don’t think he means IQ in this case. His point was something along the lines of “with Agile, you gain knowledge about your work sooner.” His argument is essentially, with Waterfall you integrate and learn very late that things aren’t working.

The problem is, his chart is garbage. This isn’t scientific. He drew a picture. Anyone can draw a picture. There’s no study behind this. There’s no data about the impact to the customer about “learning late.” Even if his hypothesis was true and backed up by data, it has to have bearing on what your customer experiences to matter. Does late learning mean worse quality? Worse costs? Who knows… Not only is this chart imaginary, so is the impact. I drew a chart too (notice the flat line).

Velocity

Yes, it’s about due time for another anti-Agile post. In this case, it’s a story about velocity. In theory, during the first few iterations the team isn’t that good at estimating. You don’t understand relative size of stories, so you don’t get a whole lot done. Over the iterations you learn more about your team’s capability and your estimating gets better and better… or does it? What does it mean for an estimate to get better?

I think a lot of people believe a good estimate is one with low variance between estimated effort and actual effort. That’s an ok definition, except I don’t think it is what your customers necessarily mean. When I ask, say a home repair person for an estimate, not only do I want the estimate to be accurate (don’t tell me it’ll be $500 and then charge me $2000 at the end), but I also want it to be cheap (don’t tell me $2000 when you could reasonably do it for $1000). A “good” estimate in my mind, isn’t one that’s just right, it’s also one which meets my needs (both in terms of requirements that will be delivered AND what it costs to deliver those requirements).

The former definition (low variance), creates a problem which I observed on a pseudo-agile project we’ve been working on. The team is trying to estimate stories and (like all early estimations) didn’t do so well. We didn’t deliver very much. However, what’s not clear (because we didn’t study it) is what our issue was. Were we really underestimating our work or were we just not working? In fact, most people on the team are part time allocated to the project (I know, bad no-no for Agile projects). Anyway, we got dinged for not delivering, and not knowing what was really wrong, we just decided the (more or less) halve our velocity for the next go-round (or I should say, double our estimates). Again, we’re really not sure what was wrong with our estimates, but adding more time to do work seemed like a reasonable thing to do.

So now, in order to get a story completed, we estimate twice as much work as we once did. And the stories aren’t getting done still. So maybe twice again is the right number? The thing is, that it is very easy for us to just say “oh, we estimated badly, let’s allow more time for this work.” And while at some point we’ll have so much effort allocated to a single story that Parkinson’s Law will take over and make sure our variance between estimates and actuals is low. The work will simply expand to fill the time allotted.

Velocity, just like any form of estimation, does nothing to account for sand-bagging. A happy customer is not one who just has low variance, but good anticipated value from the estimate (read: the estimate has to be cheap enough to be appealing). In this case, like with waterfall projects, the fact that we got called out for missing estimates created an undesirable behavior where we compensated (or I should say over-compensated) in a less than ideal way. Rather than eliciting a work-smarter reaction, it created a make more time to work the same way reaction.

You can’t just change the way you estimate and expect it to solve human nature. Calling it velocity doesn’t eliminate the issue at hand; only changing the way an estimate miss is viewed does. It has to become an opportunity to learn how to work smarter, not an opportunity to ding someone for not delivering.

The End is Near!

Wow, it’s been a thought provoking day for me. I’m on post #3. I’m sure it’ll be a rare occurrence to post this much at once. As a matter of fact, this last post was somewhat motivated by the fact that I can now make new posts to my blog via email and I wanted to try out the feature. I’ve never been much of a fan of going to a site to do one specific task and I like the integrated nature of this. Plus, using Outlook, I get better spell checking capabilities for free.

On to the topic at hand! The End is Nigh!!! No, I’m serious, the Agile iteration that the team I’ve just joined is coming to an end. Surely you recall my less than stellar review of my own first Agile experiences. On the plus side, that entire team I was with was broken up and my misery brought to a prompt end. On the negative side, I just got dropped onto another team also trying pseudo-Agile. This is to say, they do daily meetings and stories and iterations, but no software development to speak of.

Anyway, I got dropped in the middle and we’re apparently about one and a half weeks away from the end of this current iteration. It’s triage time because the owner of this (what do they call it in Agile? Group? Stream?) team (for lack of a better word) realized that they weren’t going to get any of their stories done. So, rather than say “hey, we’ve got a deadline here people and things need to get done” they’re saying “don’t worry, we’ll just move it to the next iteration.”

Ah, the double edged sword. The reason for iterations is so the business doesn’t over ask. They learn to trust development and to have them deliver a small piece of useful functionality rather than requesting the world all at once. In theory, since there will be more iterations in the future, there will be another chance to ask for more features. On the flipside, which seems to be happening on this team, and probably others, the development teams ALSO know that there will be more iterations. And why do today what you can put off until tomorrow?

Sure, the end is near, but on a single-big-realease project, what goes in is what goes in. You get you chance and you need to deliver. With iterations, even if today’s end is near, there’s always tomorrow. I’m not saying this is endemic of Agile, but it is a risk that needs to be addressed. In any methodology, there’s still a need to commit and deliver and having chopped the commitments into smaller blocks should not be an excuse to procrastinate. But it appears to be that way.

Agile not acting LEAN

This is a continuation of my manifesto against big-A Agile software development.  It stems from a training class I was in today regarding LEAN. 

First off, LEAN… Six Sigma, they’re not that different from each other.  Philosophies for continuous process improvement.  LEAN has a bent towards removing NVA work while Six Sigma has a bent towards quality.  But Six Sigma, at least the Six Sigma I was taught, is capable of addressing both problems of product quality and problems of product performance.  Again, it’s not that I’m saying one is better than the other, they’re similar.

Anyway, I digress.  While I see LEAN and Six Sigma as two sides of the same coin, a lot of people in the class were comparing LEAN and Agile software development in the same manner.

I do take exception with this comparison.  In fact, many of the things that some variant of Agile software development proposes are decidely un-lean.  I figured I’d run down a few I thought of while sitting through that dreadful training.  I guess I owe them a thanks because the training effectively freed up 8 hours for me to think about things and may inspire the next few posts.

1. Teams choose process.  This is a people-empowerment thing.  Potentially there’s nothing wrong with it from a LEAN perspective if you have just one team.  Otherwise, it’s counter to standardizing so that you have a basis from which to improve.  You can’t just change the process each iteration because the team would feel better about it.  If the deviation isn’t better, don’t do it, and if it is better, then every other team must also do it until something better yet is found.  But I don’t get the impression that Agile’s “teams choose the process” attitude came from what would be the most lean thing to do, but instead from what would make the team happiest.  Those two things might have the same end result, but you can’t be sure.
2. Fail Fast.  Decidedly better than “fail slow” which is the argument against Waterfall.  But let’s be honest.  Failing is bad!  Failing results in defects which is which of the 7 wastes people?  Rework.  If you know of a low cost way to avoid failing, say peer review, then do that instead.
3. Refactoring.  Um, duh, this is decidedly rework.  Agile considers this an entirely valid way to design and develop software.  Again, it’s better than band-aids when your design doesn’t pan out, but if a little forethought would have avoided refactoring later, then rework is avoided.
4. Daily Scrum.  Waiting, Over-processing, Motion.  Yuk.  If you have an issue, don’t wait 24 hours to deal with it.  Daily Scrums are too infrequent of a way to raise and solve a blockage.  Projects miss deadlines by losing one day at a time.  Over-processing.  It’s clearly NVA.  Meetings DO NOT tranform the product towards the customer specification.  Especially meetings where you say what you did yesterday, what you are doing today, and the possibly one useful piece of information – what’s blocking you.  And Motion… unless you’re having the meeting where you sit, you are wasting processing time by having everyone gather in some location.
5. Pair Programming.  Duplication of effort, thus overprocessing.  If one person can do it, why would you have two people do it?  I know, there’s some claim that pair programming is a form of inspection on the fly so in some way it might be aligned to fail fast, but again, the assumption that failure is going to happen is a problem in my mind.  Code is a very terse language and doesn’t do a great job at expressing ideas, which is why a lean natural-language specification would, in my mind, be better to write and be reviewed.  The cost of changes on paper is cheaper than the cost of changes in code.  Restructuring poor logic flow - painful.  Restructuring a little logic on paper - easy.
6. Test Driven Development.  Rework, but I already covered that in “We’ve Decided to do it the Wasteful Way.”
7. A Product backlog.  Inventory!  Sorry people, but this is unserved customer demand.  It’s inventory of requests that are not being processed.
8. Iterations.  Waiting.  This is a conversion from single-piece flow to batch flow.  One story in your backlog is waiting for a bunch of other stories so that they can be packaged into a release.  How do we get from here to a constant flow of new features making it to production when they are ready to go?

Look, I know what you’re thinking… “bugs are inevitable so we might as well accept that and figure out how to deal with it.”  I, for one, am unwilling to accept that we should allow failures.  Yes, they happen in my world, but we look for ways to pokayoke the development process so people don’t keep making the same mistakes.  So that people don’t have to appraise the system looking for the same stupid error that people always make.  Patterns of behaviors can be changed at the source.

A simple example.  Most IDEs today, when you start typing a built-in function, and sometimes even one of your own defined functions, immediately provide you with the arguments necessary for that function.  Other IDEs, such as Microsoft’s VBA, check syntax validity as you type each line and warn you right then and there.  Other’s automatically beautify.  When I started programming, they didn’t do diddly.  They weren’t any better than a notepad.

This is errorproofing.  This is dealing with the kinds of things that people do every day that are just dumb, avoidable errors that nobody should wait until a compiler has to run to find out.  And if they can think of these things, then I imagine I can think of enhancements which would errorproof other kinds of errors in the development process.

Will we ever get away from appraisal and rework totally?  I don’t foresee that day anytime soon, but we can be further down the line if we wanted to.  So, yes, while many of the things that big-A Agile has done are leaner than the strictest waterfall, they are still an acceptance, nay, an endorsement, of not lean behaviors.  I object.

Why bother iterating if you don’t have to?

Iterative development make sense because it allows you to deploy functionality more often.  It’s that deployment which represents a switch from a continuous stream of work to a batch process.  Once you deploy the new software, gets downloaded en masse.  For that reason, it makes sense to iterate.  Yes, you get more downloads or updates to your software but it also delivers small chunks of functionality quickly.

But should you always iterate?  This isn’t a post in favor of large batch-style development.  This is actually a post in favor of not iterating at all.  One of the things we are working on is a series of improvements to our Quality Assurance process.  There are several teams and each team is responsible for a set of features within an iteration.

For some insane reason, the manager of the project wants to treat this improvement work like an Agile project.  Not only do they have iterations and sprints but they have iteration planning and releases!  This is dumb.  Any remotely frequent reader knows how I feel about the hippie aspects of Agile anyway.  The reason iterative development is better than batch development is that it allows you to deliver small amounts of functionality quickly but feeds nicely into a distribution/update model which are almost always done in batches.

When we upgrade the software of our customers, we don’t want to serve it like McDonalds where each person gets their order in turn.  We want to blast it out there.  With software we can launch it like tossing a million burgers at the crowd all at once.  That’s certainly true for anything we deploy internally, since you don’t want one customer service rep to have the old software while another has the new software.  Installation is always big-bang.

But process work doesn’t have to be that way.  It doesn’t even make sense to do it that way.  Each process improvement, assuming no dependencies, can be rolled out when it is ready.  Creating iterations and releases artificially adds waiting to the process.  If it is ready to go, then just go.

And I’m sure this applies to any centralized system as well.  Why have monthly installs?  If something is ready, roll it.  Why batch it up to install it at the end of the month?  Those features could be waiting 30 days to get out there.  And don’t tell me that ITIL or ISO demands it.  It’s just plain not LEAN to convert from single piece flow to batch processing when you don’t have to.

It’s true for software development and it’s true for process work.  When it is ready, go!

We’ve decided to do it the wasteful way

There are seven (or eight depending) forms of waste that LEAN recognizes:

1. Inventory
2. Overproduction
3. Over processing
4. Motion
5. Transportation
6. Defects
7. Waiting
8. (optional) Intellectual

Today, I learned from a friend of mine that we were going to deliberately introduce #6 as a valid way to behave.  Test Driven Development (TDD) is a development philosophy where you write a test case to fail, then write code until it works, and then execute the test case again to show that it now works.

Practically speaking, I get that we will probably never be able to eliminate all appraisal activities.  After all, unlike a faulty bolt which might cost us a nickle to replace, a faulty line of code could in theory cost us millions.  We appraise because it’s the only way we know how to check for correctness.  However, that doesn’t mean we have to accept appraisal as being necessary.  Far from it!

We know from the great research of Capers Jones and Barry Boehm that appraisal activities, especially testing are only about 40% effective per test type.  By comparison, visual inspection (aka peer review) can be 60-80% effective.  So why would you build a process around an ineffective practice?  And why, dear lord, why, would you run a test case you KNOW is going to fail.  You wrote it because it would fail.  If you’re writing test cases you don’t know will fail, are you paying any attention to what your system can and cannot do?!?!?

Now, one might argue that TDD is simply a manifestation of really solid use cases.  If we wrote adequately detailed use cases, they could in theory serve as the tests to appraise the system.  Fair enough, but that assumes that we are willing to exchange some level of intrinsic knowledge in our developers for complete and perfect specifications from our business.  The business will now tell us exactly how it has to work.  We can also reasonably assume that for TDD to be effective, you can’t just write the positive test case and show that it works.  You must also write all the negative cases, the exception cases where the system should deal with user error.  After all, those things must be specified to fail as well so that you can write code so they won’t fail.

Alas, this methodology is faulty to begin with.  There are known better ways than to appraise than through testing.  Why choose a particularly wasteful way to get your work done?  And if it’s just good use cases, then just call it good use cases not “test driven development.”

Agile, day, uh… well…

Not that long ago I wrote “Agile, Day 1” which was my personal introduction to what being on an Agile software team might be like.  I wasn’t impressed, and I get this funny impression that nobody else, including the boss was either. 

Why do I say that?  Well, other than a brief hour long exercise a couple days later to try and finally get our stories prioritized, nothing has happened on the topic since then.  I, of course, hesitate to bring it up since I really was not a fan of it in the first place.

I’d like to say I wonder what happened, but I have some inkling.  See, not long after Day 1, Bob went to an offsite to hear all about Agile at big companies.  The presenters, Bob tells me in a later phone conversation, explain that as a professional services company they have discovered that Agile doesn’t actually work all that well.  In fact, they themselves have given up on it and use a hybrid approach, something that’s neither really Agile nor strict waterfall.  Having not seen it, but liking to claim victory for my position all along, I’d call it LEAN software development.

In fact, this company went on to say that they’ve had clients who like more documentation or more rigid process.  As the vendor, this company provided services that met their client’s view of how projects should be run.  So, I’m wondering, if they could do pretty much whatever process the client liked and still found the project to be profitable, I’m guessing their original adherence to Agile wasn’t the key difference in their company’s success.

Anyway, I think this all disheartened Bob, who was so convinced that Agile would be the future (by the way, Barry Boehm has long since presented that the Agile fad is over and companies should move to a hybrid approach) that he just couldn’t bear returning to the team and having to share this news with us.  Ok, an unlikely story. 

The sadder, and probably closer to true, story is that Bob probably doesn’t actually care all that much about the process.  OK, listen to what I’m saying… Bob, my boss, the boss of a group of process people, the person who is responsible for an entire organization’s process work, doesn’t have the time to figure out his own team’s process for getting work done!  Hello?  To quote the movie Zoolander, “I feel like I’m taking crazy pills!”

I hate to say it, but Six Sigma or any other process discipline you may like cannot be above the law so to speak.  We are not special!  We are not different than any other disciplined, scientific approach to dealing with a problem.  And yet, if your boss can’t be bothered to enforce a process just mere days ago he believed (for right or wrong, let’s just assume Bob had good reason to believe Agile was worthwhile) would have a significant impact on our productivity, I think that might pretty much sum up the problem.  Of all people who should be striving and obsessed with continuous, measurable improvement, we should be.

Agile, Day 1

Well, I’ve been subjected to my worst of nightmares – having to work on an Agile project.  OK, I should be fair, while I have argued against Agile it isn’t because I think Agile is particularly bad, I just don’t think it’s particularly different.  I’m sure Agile works fine, but it annoys me that those who support the philosophy can see no other way

Anyway, our team’s boss (Bob, hereafter), decided to start us on Agile.  First off, we aren’t a development shop.  The only person who does any development is me.  And I only do it because I need to write queries and scripts to collect measurement data.  Coding isn’t my job, it’s just a means to an end for me.

We begin the day with our first error – we write our own stories.  Stories should be written by the customer.  Why, you ask?  Because you don’t want the developers (oh wait, we aren’t developers) to impose their world view of the solution on the need.  Stories are just like requirements otherwise, except they’re called stories.  The use of natural language is more imprecise, so I guess you could call them high-level requirements.  Call them whatever, customers write requirements, because customers know what they need.

Why are we writing our own stories, you ask?  Well, it really stems from a prior issue, which is we have several customers, none of which have expressed interest in us doing our work in an Agile fashion.  Therefore, we’re acting as a proxy for the customer, and probably not doing that good a job.

That becomes evident when we try to prioritize our stories for our first iteration.  Since we have many customers, none of whom are present, we have to argue amongst ourselves which is more important.  Of course, even if we had customers, we’d have the same issue, because customers are terrible at prioritizing.  I can’t recall how many times I’ve had a backlog of issues for a product and asked the user to prioritize them so we know what order to fix them in.  They just label them all high priority.  So then I ask for force ranking, and of course they tell me they can’t do that.  So I’m not particularly surprised that we can’t prioritize them either.

Anyway, we’re told to write tasks for the stories.  I submit one task per story, since that’s what I know so far.  I ask “how granular does a task need to be?  Is a task ‘figure this out’ or is a task ’set up a meeting with Joe’?”  I’m told tasks can be as granular as I like them to be as long as I can estimate them.  I stick with the ‘figure this out’ level of tasks, since I don’t manage my time in terms of checking off lists of things to do.  While other people are talking, I review the deck one of the scrum masters has given about estimating.  The recommendation is clearly a form of wide-band delphi, wherein several people estimate the task and attempt to converge on an agreed upon result.  The ideas seem ok for a development team, but I wonder about our tasks, since my tasks involve coding and nobody else is a programmer.  Who is going to estimate my tasks besides me?

Having done not so admirably at that, even with 2 scrum masters there to advise us, we turn to protocol.  Specifically, the daily scrum.  We’re a distributed team, so someone is going to have to call in to the daily scrum sometime.  We debate whether we should have all in-person (not possible), all on the phone, or a mix of phone and in person.  We decide that the mix of phone and in person would marginalize people on the phone, but since the scrum is supposed to be just 3 questions – what’d you do yesterday, what are you doing today, do you have any obstacles – that there’s really no need to do it all on the phone to level the playing field.  I ask “what do you do if someone brings up an obstacle” to which one of the scrum masters replies “take it offline.”  Bob gets upset and says “you mean I can’t ask questions?”

“No, the scrum is just for people to answer those three questions.  If there are issues to be dealt with, they should be done outside the meeting.”  Bob frowns.

“So, then the scrum is a peer pressure thing, ” I ask.

“No, it’s meant to share status.  Everyone’s responsible for the team’s success, so if you aren’t getting something done the team would have to pick up the slack, ” replies the scrum master.

“So, it’s a peer pressure thing, ” I ask again.

“Yes, ” he admits.

“Couldn’t we just send a daily email, ” I ask.  After all, I can either listen to a group of people talk at me or I can get the same information by reading a bunch of short emails.  Seems like it’d be about the same to me.

“No, it’s inefficient to read a bunch of emails,” the scrum master tells me.  That seems odd to me, since emails can be sent asynchronously and on a phone call we all have to sit around while another person talks.  I’m pretty sure I could get through a handful of emails in less than 15 minutes.  I do it every day.  I’m pretty sure this is part of the hippie commune mentality… we need to talk and be a team, and hug, and get to love each other.

OK, now that we have that settled, Bob says “well, maybe I need to have multiple scrums each day with each of the work streams.”  I don’t think Bob gets it.  Bob wants a daily status meeting, not a brief peer-pressure meeting.  I hate meetings either way, so the idea of meeting daily with my boss or the whole team sounds unpleasant.

By the end of the iteration planning meeting, I’m feeling pretty unimpressed.  I’d summarize as follows:

1. Stories are high-level requirements and will require more requirements in order to make them come true.  Except since the requirements aren’t written down, it’ll be a bit like prototyping or JAD, both of which are totally acceptable methods of iterative development.  Acceptable, but not new or different.  Couldn’t you guys just call them one of the accepted names like “requirements” or “scenarios”?  I can’t wait until I get to go to a ‘reflection session’… hippies… it’s called a post-mortem.  Renaming stuff doesn’t make it better or different.
2. Scrum meetings are for peer pressure.  On the plus side, they’re not status meetings.  On the minus side I now get both scrums and status meetings since Bob wants status meetings too.  I’m reminded that I got a “needs improvement” in grade school on the “plays well with others.”

I admit, I’m coming in cynical, but putting lipstick on a pig doesn’t make me want to take it out on a date.

Agile for the incompetent?

Barry Boehm laid out a series of factors by which one should decide whether Agile software development is appropriate or not.  One of those factors was experienced developers vs. inexperienced developers.  Given the somewhat free flowing nature of Agile, having experienced developers makes sense.

However, at one time folks were trying to sell Agile as the method of doing software development to our business customers.  The comment about using experienced developers came up as a key point of the agile-or-no-agile decision.  And one of our astute members of the business team pointed out that pretty much any process would work better if you had experienced resources.  Touche’.

For the most part, the rise and fall of Agile at the company I am at has been a quick peak.  The business has dismissed it as nonsense (which in my opinion it mostly is), and without their buy-in, it is effectively dead.  And yet, it crops up again here and there.  And with it the ‘experienced developer’ constraint rears its head yet again.

One conversation I overheard about it was essentially “the great thing about Agile is that it exposes who isn’t getting their work done immediately in the daily scrums.”  And for some reason, the whole “use experienced developers” suddenly made sense.  On the business side of things, figuring out who isn’t contributing and doing it quick is a good thing.  On the people side of things, going to Agile might be a management nightmare.

If you have experienced developers and something isn’t getting done, it is probably due to lack of effort instead of lack of capability.  Now, on one hand it’s a good thing to encourage a sense of urgency to get work done.  After all, if you want to deliver anything to the customer, things have to get complete.  On the other hand, I can totally see myself showing up to a daily scrum and saying “yesterday, I did nothing, I wasn’t in the mood.”  How would that go over?  I digress…

If you have inexperienced developers, however, capability might be an issue.  And frankly, I’m thinking that exposing a person’s capability issues in a public forum on a daily basis might be in extremely poor taste at best.  At worst, you could get yourself into serious HR trouble for singling someone out for public humiliation.  People deserve a fair opportunity to improve their performance and get the attention and training they need.  And if they suddenly stop showing up for scrums because they’re on an action plan and can’t get things done, I’m thinking it’s going to be more out in the open than is appropriate.

While Boehm suggested experienced team members might be better for Agile, I’m starting to think it might not be optional at all.  While I believe in the relentless pursuit of perfection in process, and that may mean helping someone who can’t do the job find something they’re good at, the path to get them out cannot be a public gauntlet.  It’s a strike against scrum, for sure.

Bad me. On using Agile to evade.

I have a confession to make.  I used Agile for evil.  If you’ve read any of my prior posts on Agile, you know that I think it’s a bunch of hooey.  Yes, that’s the technical term for it – hooey.

See, I was in this meeting where some misguided souls had come to our process team for help with their project.  They wanted assistance because (the development team insisted) the users didn’t know what they wanted and if we could help them with some use cases the users would see that they were all confused and finally figure out what they wanted.

Problem was, as far as I could tell, the users knew EXACTLY what they wanted and had asked for it pretty much in no uncertain terms.  If you’ve ever read Tom DeMarco’s “The Deadline” you’ll immediately recognize this.  The users asked for a product they had already seen, but at a much lower price point.  Use cases are lots of fun, but here was an example where they weren’t needed.  You could simply pick up the user manual of the other product and it was all there for you to read.  The users knew what they wanted and they wanted to know if it could be done on the cheap.

Anyway, the development team was insistent that use cases were needed, so we tried to help.  By the way, I’m in the process design business, not the requirements elicitation business, so this was a silly request of our team in the first place.  But we tried, really, we did.  We created a first set of use cases based on the product the users had already seen.  After all, WE (the process design people) already knew what the users wanted, so we had a great guide.

The development team said “no, that’s not what we need.  We need product-level use cases.”  So, we went and got one of the folks from product, who along with us said “what the heck is a ‘product-level’ use case?”  We wrote a different set of use cases, same processes, slightly differently organized to see if that’d make the dev team happy.  Nope.

Finally, we got into another meeting with the development team.  I said “why don’t you go Agile?  Clearly you think the business folks can’t give you requirements, so the best solution would be to start with a handful of stories, figure out what the minimum marketable feature set is, and build the product iteratively.”  Of course, this was BS.  The business people could give very detailed requirements, if only systems would let them.  Me, I just wanted off the project.  These systems people were nuts, and probably subconsciously trying to avoid the project and so were throwing up roadblocks.

Whatever the reason, I finally found a good use for Agile… “requirements are hard, so let’s just not do them.”  But really, it’s an excellent way to evade a hard conversation.  Of course, the conversation will come up later, but at least I can put it off and hopefully they won’t remember me when it comes up again.