Hacker News Reader

Comment by Terretta | Hacker News Reader

It’s a nice looking tool, but the marketing feels oh so very Enterprise Agile(tm) in ethos.

“Run your weekly sprints on time” — as opposed to them taking two weeks?

To achieve predictability, something has to give. It’s usually “learning” which is never on the plan.

The next release will be done when the right top priorities are met well enough. When’s that? You decide by prioritizing how many priorities are in the release and your bar on quality.

Focus on execution? Why not on building the right thing, and building the thing right?

The thing to manage isn’t tasks, requirements, and sprints. The thing to manage is: “Is this team effective, enough to be trusted?”

Meanwhile, a week takes a week.

View on HN

As a manager I follow two principles that help me to prioritise tasks for a weekly sprint.

First, every project has three levers: budget, timeliness, features. Choose two. So it's not about not trusting the development team. It's about understanding the tradeoffs and how the delivery date will be affected.

Second, how well can you predict what you can achieve as a developer in one day vs one hundred days? The estimate for the former is more reliable. Likewise the estimate of what you can achieve is more reliable in a one week sprint than a two week sprint. Being able to break fully deployable commits into smaller chunks (up to three days coding time) is a skill that gets better with practice. But sometimes you just don't know how long something will take because it needs breaking down and investigating. One week sprints are ideal for timeboxing investigations; here the output isn't software but discrete software tasks that fit in a one week sprint.

Ultimately it's not about trust, it's about accountability and predictability. Sprint planning tools when used appropriately don't constrain engineers, but rather highlight the truth of how things are going.

Sorry, teams can't be only devs. That's IT or something, and implies that tech isn't the business.

Team has to include 'the business', as in, voice of customer, features lens, in those tradeoff prioritizations along with what do we engineer, and what's the truth of where we are on the field, for delivering what satisfies the customer and our constraints. // Hat tip Rands in Repose.

As for "Ultimately it's not about trust, it's about accountability and predictability" that's precisely the characterization I reject. Accountability means you earn your keep by being effective. Predictability, well, milestones come and go, the software gets used forever. That's the predictability needed, which goes right back to effectiveness. You won't magic either of those in a Jira.

The team I work in has a product manager, a designer, a cloud infrastructure automation engineer, as well as seven software engineers. Together we collectively advocate for our users and help with those tradeoffs.

> As for "Ultimately it's not about trust, it's about

> accountability and predictability" that's precisely

> the characterization I reject.

How do you know if you're effective? Perhaps it's a difference from one company to another but I don't think it's unfair that my manager (and others dependent on my team's output) want to scrutinse my decisions, and the outcomes of the team.

Likewise, I can scrutinise the choices of engineers with weekly sprints, to ensure the goal is hit i.e. a timely release with flexible features, or a feature complete product that might overrun.

JIRA doesn't magic effectiveness, agreed. It can help show the truth of the decisions taken toward a goal and how work is progressing. I'm not advocating waterfall (any estimate of "this fully specced feature should be finished in two months" is pure fiction) but JIRA or other similar products can work to let managers know ahead of time, "We're not going to finish this by our initial estimated delivery date." That's a useful tool.

> every project has three levers: budget, timeliness, features. Choose two

You forgot about quality. It can blow the other 3 out of the water.

That's non-negotiable to me. You can make a short-term decision e.g. this implementation will only scale for the next month, but automated testing, clean code, other standards must be maintained.

Quality is implied within the feature/scope grouping. Its always a three leg stool trade off for balance. Changing your quality output is just reducing or adding to scope requirements.

Budget = Resuorces / Time = Time / Scope = Quality

Quality could be grouped with features as "usefulness" of the software. Low quality software is unusable, or more expensive to use.

Timeliness has an equally direct impact on software value, but in this planning context it makes sense to distinguish what is delivered and when it is delivered.

...if you consider quality a lever, you're not the kind of person anyone should want to work with!

You agree on quality standards before you begin, and you deliver the quality level that you agreed beforehand, not more, not less (you deliver sooner if it goes better than expected giving the product-owner ability to add features or redirect effort actually using your "superpowers" if any to give the business a real advantage), at a profit or at a loss. Otherwise you're not a professional, you're either an amateur or maliciously dishonest/exploitative!

You could just as easily say that you agree on the feature set beforehand, and you deliver that feature set, not more, not less (you deliver sooner if you finish the features early).

"The quality level you agreed beforehand" is meaningless without some infrastructure and processes in place to verify it. And in practice, those infrastructure and processes are compromised at least as often as the feature set, the budget, or the timeline.

I think I have to agree. I understand the impulse to say that it's implicit, and certainly the desire to build a quality product usually is. But in reality, to actually verify quality before you ship often requires a lot of costly infrastructure and time-consuming work. So in practice, it really is a lever that often gets sacrificed---usually at the alter of the timeline. You could argue that a feature that is broken isn't a feature, but there are many subtle degrees of broken-ness. A bug that happens 1 in 1000 times might be acceptable, or it might not.

> Second, how well can you predict what you can achieve as a developer in one day vs one hundred days? The estimate for the former is more reliable.

I’m not so sure that’s true. I mean, it’s probably not worse but often I find that my gut feel of “it’ll take for weeks” is more accurate than trying to break the feature down beforehand and add up the parts. I’ve always said that the estimation process rests on the hope that if you break a big wild-ass guess into a lot of smaller wild-ass guesses, the errors will cancel out. I don’t think that’s always the case.

I’m starting to be fairly confident that the ‘budget’ lever for a project might as well be disconnected from the feature and timeliness ones. Spending more money doesn’t make things go any faster. Especially adding more people makes things fo slower.

Completely agree on the not going any faster point. The Mythical Man Month demonstrates this exact concept perfectly.

The budget lever is still available in limited forms e.g. do you devote two engineers from the team to project A or three? The point here is that the engineers have to be already up to speed on the codebase and already know how to work with their colleagues; and adding more on project A leaves fewer for project B, C, and D etc.

Also there is monetary budget. Can I solve an engineering inefficiency by throwing larger servers, or buying a licence for a relevant software service?

> "do you devote two engineers"

Maybe one could say that in the beginning of the project, one can use that budget lever, but not in the end (mythical man month)

It is connected... until the project start, eg. in the broad general planning phase, when you press "start" it gets disconnected and stays that way until you ship a usable (±new) version.

Once the wheels are in motion you can only accelerate by breaking off sub-projects/teams... but if you're at a point where this can accelerate you, it means you were already slow-as-hell :|

Reply on news.ycombinator.com