Agile Up Front Requirements
I have been having a bit of an internal conflict lately. This is a different sort of internal conflict. There is no yelling, there are no strange voices, and there is no heavy sweating while I slump in the corner and mutter to myself. This is an intellectual, professional, theoretical conflict.
I believe in Requirements. I believe in them enough to capitalize the word as though they were divine. I believe in thoughful requirements. I believe in up front requirements. I believe that sometimes you do not capitalize requirements and they are only as good as they are valuable to the particular project.
I also really dig Agile methodology. I dig it enough to capitalize it too - although I suspect it may need to be capitalized anyhow. People own it, or something.
So my conflict was short-lived, but intense: how can I strive for Agility while maintaining that Requirements are, in fact, required?
Agile does not say that Requirements should stay home with the year-long GANTT charts. This is where people can get a little testy, and PMs start clutching MS Project to their chests and getting nervous. No client I have ever worked at will sign a blank check. They all want to know what you are going to build, how much it is going to cost, etc. Obviously, internal project are a bit different. The company I was at before the company I am at now bled money for years on internal projects without ever delivering a clickable link. Was amazing. You really do need deliverables, and therefore requirements, but maybe you dont need 1000 lines of dot notated “The System shall…” declaratives that are the DNA of a project. Maybe scope creep isn’t creep, but evolution. We are not building prefab houses, here. This is software.
You need Barely Good Enough Requirements. See my entry on Barely Good Enough Use Cases for a nice parallel. Clients are different. Some will want BUF (big up front) Requirements and to nail down - HAMMER DOWN - the scope. They will be pleased with the idea of Change Requests and Scope Control. This makes intuitive sense to a lot of business people because software is not overtly that much different from anything else (but we know that it is, don’t we?) and should be able to be priced and described before delivery.
So your Barely Good Enough Requirements will serve to give you an estimate and a rough scope - as rough as you decide is Barely Good Enough. And then you scrum away, allocate from your backlog, and change direction when required like a UFO doing right angle turns in the Arizona sky. I mean, besides the fact that you are probably not an alien. And you aren’t likely to tolerate that kind of pitch without losing your lunch, although I’ve seen a PM lose their lunch over an abrupt change in project direction. It was not pretty.
I like the idea of a Requirements Document that is one giant Context Diagram. I like the idea of it splitting, like a cell, into separate organisms that comprise a larger System. I like organic development and organic growth.
More on this later. I am annoyed with Google and do not feel like writing. It is distracting me.
Take care,
Josh