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.