"Writing good specs is important" - it's also really really hard.
It is all too easy for a developer to blame difficulties on poor specs.
But if you're doing agile properly, you shouldn't consider a user story a 'spec' - a user story should be a placeholder for a conversation.
It is unrealistic to expect a non-technical stake holder to deeply and accurately describe anything but the most trivial feature. It needs a developer mindset to poke the idea, see what holds water, see where it falls apart, foresee the consequences.
You can't do that in a spec. It needs to be a conversation.
Agile favours 'Individuals and interactions over processes and tools', and this is too often forgotten when someone is pimping their tool, or blaming their process.
Have a conversation, understand what's needed, build good software.
> "Writing good specs is important" - it's also really really hard.
Yes, this is a very good point. Unfortunately it's also a point that many non-software developers miss. Writing software is hard. Very hard. We, as an industry, should be pointing that out more.
> But if you're doing agile properly, you shouldn't consider a user story a 'spec' - a user story should be a placeholder for a conversation.
I'll submit that there's no way to know whether you are doing agile properly or improperly, unless you move to another company.
> It is unrealistic to expect a non-technical stake holder to deeply and accurately describe anything but the most trivial feature. It needs a developer mindset to poke the idea, see what holds water, see where it falls apart, foresee the consequences.
This smacks of elitism and it is what makes non-developer scoff at us. Developers are not gods, we're not even the smartest people.
We are simply the people that have to crystallize the requirements into a computer that only understands logic. Non-tech stakeholders can completely describe business requirements and also be made to understand the how their requirements fit into the logic of a computer. Non-technical people are not stupid, they just have different interests.
> You can't do that in a spec. It needs to be a conversation.
The spec is the output of the conversation.
> Have a conversation, understand what's needed, build good software.
And this is the most important thing said.
The trick with adhering to your statement is to define the parties involved in each step. Minimize those parties and then implement each step in order as fast as possible without sacrificing quality.
Remove the word "Agile" and the concept of software development, and what you've just described is how work has been completed for thousands of years. I fail to see how Agile comes into play.
> This smacks of elitism and it is what makes non-developer scoff at us. Developers are not gods, we're not even the smartest people.
I don't mean to imply that developers can do this because they are cleverer. Merely that developers have a mindset to understanding software systems that business people often lack.
> The spec is the output of the conversation
As I've said in another comment I don't think there should be a spec (in the traditional sense at all). There should be a story, a conversation, and acceptance criteria (ideally defined in code)
Yes! I think this section of the post could definitely be expanded on:
It’s important to have developer buy-in. Their passion for a feature can be a huge driver for velocity.
This is why I also appreciate PM tools that incorporate discussion threads: that back-and-forth communication really helps clarify what you're building. I also like using the 5 whys after the initial spec has been written: "Why are we building this feature?"
> It is unrealistic to expect a non-technical stake holder to deeply and accurately describe anything but the most trivial feature.
That's why you have a Project Manager / Business Analyst / Whatever Title You Prefer.
Few would consider going out and hiring their own construction crew to build their new house, managing materials deliveries, blockers, scheduling, head-count, etc. That's what a General Contractor is for.
But in software, both (some) business people and (some) developers think they can get away with attempting to go down a well-travelled path (by others) and do it all themselves.
Without that experience and expertise it's more likely than not IME that you'll spend more than you have to, and since you aren't a scheduling wizard and are trying to keep all this stuff in your head, you'll have numerous "stop work"s, conflicts, change-orders for half-baked designs, etc.
If you're building anything beyond the trivial, and you'd like to have a reasonable ball-park for what it's going to cost and how long it's going to take, make sure you're talking to the GC and not the plumber. And run far away from any business that tells you they cut out overhead by removing the GC.
I saw a slide not too long ago depicting a development process. It went something like: Skateboard -> Bicycle -> Scooter -> Car -> Truck.
If I'm the one writing the cheques, I'd be pretty pissed that I paid for four vehicles I didn't need before I got the one I did. Especially when it could have all been easily avoided by asking the right questions.
Agile can favor items on the left over items on the right. That doesn't mean you don't do the items on the right. It doesn't mean you start without a contract. It doesn't mean you don't plan. It doesn't mean you don't document requirements.
There's nothing Agile about having a chat between A and B, sitting at a keyboard, and spending money. That's just cowboy coding. And when it inevitably goes south, best of luck getting the stockholder to fall on their sword for you.
> There's nothing Agile about having a chat between A and B, sitting at a keyboard, and spending money. That's just cowboy coding
Nowhere did I suggest having the conversation was the entire process. I am merely rejecting the notion that a story is a spec. I believe there should be no concept of spec at all. There should be a story, a conversation, and then acceptance criteria (which should ideally be defined in code, not a document)
So you would write functional acceptance tests, and the only thing written down is a Story.
If all goes well, maybe you have a happy client at the end of that. If they're OK with costs and time being potentially an order-of-magnitude off.
Most people outside of the software world aren't.
Most people outside of the software world use specs. I feel like if there were a better, more reliable way to build something, anything, it would be common.
But wether it's a car, a house, a boat, a bridge, a road, a piece of furniture or a motion film, that's not the way it works generally. If you want repeat business anyways. I feel like resounding success without specs is the exception.
At least it's always been that way in my career. The less planning effort, the less success. The correlation is so strong IME that it's basically like saying fire is hot.
As someone whose dealt with independent contractors for house work, it really sucks for a client to not know the what, for how much and when. I've never met a client that objected to nailing those down (within reason) before I started sending over invoices for Developer hours.
> It is unrealistic to expect a non-technical stake holder to deeply and accurately describe anything but the most trivial feature. It needs a developer mindset to poke the idea, see what holds water, see where it falls apart, foresee the consequences.
Lots of developers are pretty bad at this, too; its more of a system analysis than coding skill.
> You can't do that in a spec. It needs to be a conversation.
You need a conversation directed by someone with a clear thought process that can encompass what is important in both the business and technical domains, ideally involving both business and technical experts, to get to a spec. But you absolutely can specify what needs to be done in a spec, and if you don't document the outcome of the conversation in one, its almost always going to be trouble down the road in any significant system. In the best case, its going to result in the technical staff answering lots of questions from business users (often, when neither the original technical nor business folks are in the same role) about what the system is expected to do, rather than actually working on system improvements.
If you replace specs with conversations rather than using conversations to get to specs, then everytime someone would otherwise consult a spec to answer a question later they end up consulting a programmer, instead.
> But if you're doing agile properly, you shouldn't consider a user story a 'spec' - a user story should be a placeholder for a conversation.
Yep. It almost sounded like this article was saying "you're not waterfalling hard enough". Processes are not a substitute for human interaction, they are supposed to enable human interaction.
I've found the hardest part is "build good software". Granted, I'm new, only going off of experiences in four internships. e.g. Now, this company is building a tablet application, except the director is serious about UX and hired actual UX people. But things are constantly changing, on a weekly basis; we'll build out some complex interaction feature, then then have it scrapped a few weeks later. And the codebase has suffered greatly.
If things are changing because requirements are changing, rather than because complexity of requirements is being uncovered, then that is a hard issue to solve.
Yeah, as a dev I would have to get some huge book of specs. It would make things very tedious. And, of course, take a huge amount of time to create and follow.
It is all too easy for a developer to blame difficulties on poor specs.
But if you're doing agile properly, you shouldn't consider a user story a 'spec' - a user story should be a placeholder for a conversation.
It is unrealistic to expect a non-technical stake holder to deeply and accurately describe anything but the most trivial feature. It needs a developer mindset to poke the idea, see what holds water, see where it falls apart, foresee the consequences.
You can't do that in a spec. It needs to be a conversation.
Agile favours 'Individuals and interactions over processes and tools', and this is too often forgotten when someone is pimping their tool, or blaming their process.
Have a conversation, understand what's needed, build good software.