[thackerhacker]

It's a long time since I've had to deal with "strict" Scrummers. But I do remember being utterly baffled as to the insistence on user features being ready by the end of a sprint, even for quite complex, technical components.

Why can't we make some sub-component this sprint then the UI bit the next?

I tried various ways of reframing it such that the developer of the UI be the "user" but it didn't wash.

[ozmbie]

Because that two weeks you spent writing excellent code is mostly useless unless you have a way to get feedback on it. As a customer, you've given me no value.

What if you finally hook up UI to the sub-component and the customer/stakeholder decides they don't like any of it? You could have known about it earlier.

[redler]

The problem with this is that it imposes a membrane on the process that is only permeable to work that contains a shippable piece of user-facing software. It presupposes that all work can be divided into such pieces. And since that's not true, it leads to contorted stories to squeeze necessary work through that membrane.

[ozmbie]

I agree that sprint lengths can be arbitrary and counter-productive to developing good software.

I think it's important to understand that the sprint "membrane" is not designed to help developers. It's designed as a compromise between developers and their managers.

Developers want to work uninterrupted and perfect their work before releasing it, and managers want working software quickly and like to interrupt developers and change courses frequently. Sprints are an attempt to find a middle ground, but it's not always ideal.

[abritinthebay]

> It presupposes that all work can be divided into such pieces.

No, it states the reasonable conclusion that all valuable features can be broken down into such (because otherwise if it adds no value to the product).

There are also Scrum tasks around Research, Tech Debt, etc that are perfectly fine to create and work on but they have an affect on your overall time to build new features and that's ok. Because it needs to be done, so they'll get prioritized accordingly.

[redler]

You italicized "valuable features" and I understand why, but I think the trouble spot is actually the word "all"; your parenthetical about adding no value merely begs the question. I'd argue that, indeed, some valuable features can be organically broken down into two-week user-facing deliverables, but certainly not all and probably not even most. There's nothing magical about being able to partition a deliverable into a sprint's time frame that, by such distinction alone, makes it valuable versus valueless.

Systems like scrum try to wrangle into a manageable bolus a process that -- if we're to make good softare -- necessarily includes creativity, inspiration, and the traveling of paths yet unseen. It's like writing a novel and having two-week deliverables like "complete the arc of the Alice character", versus "write approximately 100 pages". It's not valueless to write 100 pages, despite not finishing the Alice section, and perhaps specifically because we discover that Alice's emerging story turns out to intersect perfectly with what we want to do with the Bob arc later on.

So there's writing and engineering and lines of code versus plotting and architecture and inspiration. We need all of it, right? Does everything that's not a "valuable feature" have to be shunted into the cul de sac of a research spike, doomed to be frowned upon by the management for whom the system otherwise provides the sheen of predictable velocity? Does the critical work of "dreaming" of what to do at both macro and micro levels become a casualty of the banal necessity of marching equal-sized boluses through the development tract?

I'm making a florid point, but to me this feels like the essential tension.

[abritinthebay]

> but certainly not all* and probably not even most.*

Yet to find any that can't. I've yet to hear of any either. Usually that's a problem with the people trying to break things down not being used to modeling things differently - not the process. It's pretty common.

I'd love to hear some examples tbh.

> There's nothing magical about being able to partition a deliverable into a sprint's time frame that, by such distinction alone, makes it valuable versus valueless.

Of course not! The point is not that the time-boxing makes it valuable, I hope I didn't imply that, it's that all features that have value should be specific enough to be able to be broken down. If something is too vague it's not a valuable feature because at that point is just pie in the sky spitballing. That's what requirements and grooming is for - to identify what needs to be broken down, expanded on, or specced out better by the Product Owner.

> It's like writing a novel and having two-week deliverables like "complete the arc of the Alice character", versus "write approximately 100 pages".

That would be awful Scrum process. Also the Product Owner is the Sprint Team in a novel but lets pretend they are two separate people for this: here's how that should work in a Scrum system...

- Story: "complete the arc of the Alice character"

- Feedback: Too vague. What IS the arc? What perspective should it be from? Lots of questions, needs to be broken down.

Next, after the product owner has worked out that we're going to hit these beats in a 3 act structure.

- Story: "complete Alice's arc for Act One, with exposition introducing her and the other characters, ending on the inciting incident for the main plot"

- Feedback: Better, but this is really 3 things - the introduction of Alice, the intro of the other characters, and the inciting incident. You should split those up.

Next, the PO has split this up into those three Stories and presents the first one...

- Story: "We need to introduce Alice so the audience can start to get to know her."

- Feedback: Great, this seems low complexity and simple. We have requirements for her backstory? Ok, great, lets work with that. Seems like a Complexity 2 Story.

Then, when Sprint Planning...

- Scrum Master (not PO): "Ok so we were planning on getting this Alice introduction done this sprint, we still ok with that?"

- Everyone: Yup!

- Scrum Master: Ok, lets break this down into tasks of things we want to cover then.."

And then that part of the story gets written. Obviously it's an odd metaphor, but that's kind of how many (not all, at all) professional authors break down a lot of their writing process anyhow. Some are more freeform of course, but many plan a lot too.

The point is - that just because you have a planning step doesn't remove the creative process, it helps you plan better for work. That's all.

Scrum doesn't magically change how you code or what you code, it's just a planning and change management tool that emphasizes incremental steps.

[TeMPOraL]

That's why I sometimes say at my workplace that we should make our projects in Flash. Faster to make an interactive UI this way and get the approval of the management/customer, no time wasted on useless things like having the program actually work in an efficient, useful and secure way.

[protomyth]

I knew some folks in the 90's that prototyped in Shockwave. They did UI and animated uses cases. I was impressed by how quick people got their blob-type people animated use cases that were basically little cartoons. Seemed like way too much work, but I guess it worked for them.

[TeMPOraL]

I've learned the hard way just how effective such prototyping tools can be if you only care about... prototypes. Or the visual stuff. Seeing a designer whipping up a running example in 15 minutes in Construct2 that was equivalent to what me and two of my friends spent last 8 hours coding has taught me to respect those tools, at least in particular use cases.

And my point is, if we're focusing only on short-term client-recognizable value, we may as well just make shiny prototypes. Who cares about the pesky internals anyway.

[protomyth]

To be fair to them, they were hella good C++ programmers and used Shockwave to prototype and lock down the business requirements. You can do an amazing amount of specification like that. It was basically CRC cards put to animation as people and things interacting.

They provided quite a bit of short and long term value by being better at giving clients an understanding of what they were actually getting. They cared about the internals and making sure their clients understood the logic the internals would use.

If I was skilled in some animation tool like they were I would do the same.

[marpstar]

...Flash?

[TeMPOraL]

Yeah, that thingie in which you draw stuff, sprinkle them with a script or two, and with a few click you get something that can be run or embedded in a webpage. The thing HTML 5 supposedly replaced.

[dozzie]

> As a customer, you've given me no value.

Erm. But it's you who is the customer in this scenario, not him? Or am I missing something?

[thackerhacker]

He's saying that eventually when your feature surfaces as a UI the customer may not like it.

To which I have 2 responses:

1. not all features need a UI to be useful

2. this also demonstrates the infantilising nature of scrum where no developers can be trusted to think deeply, talk to stakeholders and otherwise do the right thing in a fully-rounded way but must just follow the exact instructions expressed

[ozmbie]

I mentioned UI because of the parent comment (about hooking UI up to a sub-component).

The core idea I was trying to get across is that until a feature is working and in front of a customer (or stakeholder), it's essentially in limbo because you don't know if you've built what they wanted. Maybe there was a miscommunication, maybe they find the feature confusing, maybe they've changed their mind. The goal is to get feedback as soon as reasonably possible.

eg: A stakeholder (or customer) requests feature X, and everyone agrees it's a good idea and we should to work on it right away. The dev team could spend 2-4 weeks writing excellent behind-the-scenes code that's not hooked up to anything, or you could spend 2-4 weeks on holiday. Either way, you've given stakeholder the same thing: No new feature.

If you're confident that you know exactly what it is you want to build then you don't need Agile, scrum or sprints. Scrum isn't supposed to be waterfall with arbitrary reviews every 2 weeks.

[dozzie]

But he said:

> As a customer, you've given me no value.

Meaning:

> You, being a customer, have given me no value.

This is what I don't understand.

[jholman]

He said

> As a customer, you've given me no value.

Meaning:

> [From my hypothetical perspective] as a customer, you've given me no value.

Or more concisely:

> [Speaking] as a customer...

[dozzie]

I'm not sure this is how the grammar works...

[bmurphy1976]

Customer is a poor term. It should be stakeholders. Sometimes the stakeholders aren't "customers" per se, they could be other parts of the organisation for example. I'd consider my CTO a stakeholder and I'm pretty sure he's interested in the value of fixes for a security audit or working database backups even though those don't necessarily have a nice demonstrable UI.

[abritinthebay]

> I tried various ways of reframing it such that the developer of the UI be the "user" but it didn't wash.

Are you surprised? The developer isn't the user of the UI, product wise, so no wonder it didn't get very far.

The trick in this case is to break the story down. So the original story isn't do-able in one sprint? Ok, so what is actually the MVP of that Story? What's the first block that builds the overall feature? Take a 5 point Story and make it three 2 point Stories or something. That's what the refinement step is for in Scrum.

Unless you're doing abnormally short sprints there should be some part of that Story that can be abstracted into a smaller Story that fits into a sprint.

[lmm]

> Why can't we make some sub-component this sprint then the UI bit the next?

Because that's how you get bad UI. The user-facing design needs to drive the API interface, not the other way around.

[gmarx]

I disagree. It varies from situation to situation but I would argue in my domain at least (healthcare) this is how you get bad data models

[fsloth]

"The user-facing design needs to drive the API interface, not the other way around."

I don't see how this need would nullify the ability to modularize code.

[lmm]

Modularize by functionality, not by layer. Start with a simple end-to-end path and grow outwards, rather than trying to go top-down or bottom-up, and don't split into distinct layers until you're actually deriving value from doing so. Writing code when you don't have the use case yet is always a bad idea.

[Udik]

Yep. And then at the third sprint into this path you realize that the way the backend has been built during the first two sprints makes it impossible to deliver some essential or just very desirable feature that nobody took in consideration because it was outside the scope of the first two sprints. Seen it happen multiple times.

[lmm]

That's the opposite of my experience. It's always the extra layer that was added for some planned feature that we never actually implemented in the end that gets in the way.

[goalieca]

I disagree. This is how you end up with messy code that needs constant refactoring. Making time to come up with a composable design shouldn't be that difficult. It usually isn't.

[abritinthebay]

All code should be constantly refactored. This way your code gets refactored as the design changes (which... it will) rather than having to shoehorn an architecture that worked great originally into a set or requirements that have moved on.

[tener]

Not true. If you have design ready before the implementation starts (as you should unless it is very simple) then you are free to implementation things separately. Just have the interface well specified.

[beerwulf]

Sounds like you've never worked in a shop where they think "agile" == "no need to plan ahead"

[tener]

This is sad, but my point still holds. Perhaps being honest with oneself about real tasks that need to be done will help. Planning the architecture/feature, doing proof of concept etc. are all valid tasks even if they don't bring immediate business values. If you claim that you can only do business features without doing any exploratory work then you are effectively claiming to have an oracle giving you perfect solutions out of the blue. In which case you should stop whatever you are trying to do and start selling the services of your oracle.

[matthewmacleod]

Speaking from a UI developer perspective, this never works :) But YMMV, I suppose…

[tener]

We always do a brainstorming before implementing any serious feature / change. Once we have the initial design business gets involved (if we can get their attention...). The results usually works without needing any drastic changes, which is still better than no planning at all. It does require involvement from a number of parties though.

[lmm]

Design is better when it's informed by implementation, IME. The only complete specification is working code; if you accept something lower-fidelity then it's very easy to miss ambiguities.

[tener]

Even code have bugs so it's not perfect. Your design can incorporate high level algorithm to be implemented, ins/outs, or whatever else high level constraints are most applicable to your domain.

[st3v3r]

But if you design things ahead of time, then you're not "agile"!

[tener]

See my other comment regarding oracle: https://news.ycombinator.com/item?id=12249897

[xorblurb]

In your church, maybe.

In a country where logic reigns, it depends.

[bighi]

Imaginary countries don't count.

;)

[taneq]

Depends what you're building. Which leads us to the worst (meta-)aspect of Agile/Scrum these days, which is that it's the industry's current favourite hammer and so it gets used to bash every single problem. Now, hammers are quite versatile, but you have to know when to bash, when to use the claw, when to lever or just nudge things instead of swinging.

The moment you start getting dogmatic about your process is the moment your decisions start being driven by something other than your actual needs at hand. And that's the moment when you start to produce a bad product.