Colleague: All weaknesses can be recast as skills!
Me: Very well. I used to enjoy hunting small animals
Colleague: So, then, what you’re looking at there is drive, ambition, and the ability to think outside the box.
Me: And occasionally skin the box and turn it into stew
This is a strange place to work sometimes
While I was in SF, a metric shitton of new music seems to have come out. I can thoroughly recommend:
That’s in the past. At the moment I’m also looking forward to:
I’ll just stand up and introduce myself; hello, I’m Oliver. I’m 21, and I’ve hated agile development for 3 months. Oh, wrong meeting format? Right then.
Agile
For the uninitiated: Agile development is the name for a cluster of development methodologies – theories and structures for how you should develop software. Agile methodologies are characterised by being (a) lightweight and (b) iterative, with the often-touted catchphrase of “release early, release often”. The idea is that by releasing software often, instead of storing up for One Big Release, lessons learned from individual features and individual releases can inform future releases. In addition it gets the software in the hands of the consumers faster (which is kind of the entire point of programming, y’know) and means that slowdowns and screwups can be compensated for quickly without having to alter one massive timetable.
The methodology we use is Scrum, which was developed by a pair of Japanese guys in the mid 90s. In Scrum, there are two major cycles that matter; the product cycle, which is the timetable for the entire product (or for substantial, standalone chunks of the product), and the sprint cycle – a 2-4 week timetabled set of things to do. The product cycle is divided into sprints, and you start off with one fairly well-defined but loosely timetabled set of product cycles. You then map out all the things you want to program, denoting how difficult or complex they are with a number – say, 1 for the most simple, 8 for the most complex, and estimate how many “points” you can complete in a single 2-4 week sprint. If it’s 20, you pick 20 points’ worth of projects and start work.
Obviously at this stage you have absolutely no real idea how long it’ll take. Sure, you can predict based on previous products, but each piece of software is different. And this is where Scrum and other agile methodologies show their value – because even though you can’t accurately predict how much you can fit into a sprint, the same is true in non-agile processes. Difference is, agile gives you the opportunity to do something about it.
Whichever methodology you pick, agile or non-agile, you inevitably get to a point where you were Wrong. Wrong about the timetable, wrong about how much work you could fit into a sprint, wrong about how easy certain features are to code, whatever. The end result is your initial timetable is junk. If you went for some rigid methodology where you have plotted everything out for six months into the future in meticulous detail, you are fucked and now have to tear up a lot of plans. If you went for scrum, you shrug and go “okay. Next sprint we’ll work on 16 points worth of stuff instead of 20 because now we know our work rate is slower than initially estimated”.
Now, 16 points will also be wrong, but it will be less wrong. And next sprint you’ll adjust to 15, or 17, or whatever, and each time you’ve got smaller error bars. This contrasts with other development cycles, where you will end up with fewer changes and larger error bars unless you want to muck everything up. This also makes my job approximately 300 percent harder.1
My role in Agile
Agile methodologies, particularly Scrum, have dedicated little pidgeonholes to stick the people working on the project in. There’s the ScrumMaster, who keeps the development team ticking over and makes sure they’re actually following Scrum; that’s Ian. There’s the development team itself, which is Kaldari and Benny, and there’s the Product Owner, Fabrice. Then there’s me.
My role doesn’t have a place in “pure” Scrum development, although Chris suggests that “Product Owner” is the nearest analogy; I don’t just represent the stakeholders, I act as a courier of information to and from them, prompt them into giving feedback, assist them in testing what we’ve built. I’m like if a Product Owner, a customer support guy and a PR representative had some hideous should-have-been-aborted baby. An essential part of my job is being able to communicate firm assumptions with the community. We will be finished by This Date. We will be including These Features. Agile generally and Scrum particularly make this almost impossible to do.
Why I hates it
Think back to the explanation of Agile and Scrum. The big distinction, from a stakeholder perspective, is that one rigid and specific timetable and spec with a small number of changes featuring large error bars is replaced by one vague timetable with lots of specific sub-timetables, a large number of changes, and ever-decreasing error bars. This is an issue.
When there’s a rigid spec, I can point people to that spec. When that spec is altering and updating every two weeks or four weeks, it becomes much more difficult to have any degree of certainty in what I’m passing on. When there are a small number of changes, I can report these changes fairly easily; when there’s a large number, it becomes more difficult, because I’m stuck with a choice between not updating people (in which case we lose the one major stackholder-facing advantage of agile) or constantly bombarding people with messages.
Sure, each subsequent message from the first one is going to be more accurate. I get that. It’s really great. And that’s really important to the developers and managers, who need a way of scoping out how long something will take, but completely irrelevant to my role. I need a fixed and small number of changes to the timetable and changes to what we’re developing – otherwise, what am I meant to tell people? Telling them every change risks annoying them through constant, unceasing minutiae. Trying to prune the list down inevitably means leaving things out. And, stuck between these two harsh realities, it’s easy to lapse into a mentality of trying to do nothing unless you’re completely sure of it – which you never are, because, well, it’s agile.
The end result is a serious issue with how I talk to the community. In some ways, that’s my fault, but in some ways, Scrum feeds into and facilitates poor communications with stakeholders. The absence of a firm timetable is great for the people who previously had to rewrite the whole thing once a month, but it’s hell for outsiders trying to understand what the fuck is going on.2
Sleep-deprived yacking with a pair of foundationers has led to the punnish equal rights motto “assertEquality: Because equality is a precondition”
*bows, waits for tomatoes*
This post created solely to fuck with Jorm. I’ve never:
seen
read
listened to
Note that this is “to my knowledge”; I may have heard things and forgotten them, or heard things and not been able to identify them as “by [band]“.
