Hacker News Reader

Comment by givemeethekeys | Hacker News Reader

Scrum starts at the management level.

Let's say a project is expected to take 4 weeks to complete. Then, it is no longer a Scrum project. It is a waterfall project that is pretending to be a Scrum project.

With Scrum, everyone commits to working on something that will be done within the release cycle (usually 1 week), then re-evaluating based on feedback. This means asking for smaller things more often.

Trouble is that most people don't know how to ask for and build by starting lean and staying lean. They get ahead of themselves (and the team) by assuming more than they should.

View on HN

Scrum is iterative and incremental. While you plan a sprint, you loosely plan an increment and using the estimates and velocity, project where you will land.

It can be useful to know you're not going to make the 6 month project 3 months in. So you can readjust expectations or abandon the project entirely.

People will listen if you have evidence and the team on your side. Arguably this all depends on your project, culture and product.

> While you plan a sprint, you loosely plan an increment and using the estimates and velocity, project where you will land.

That sentence contains four verbs: plan, plan, estimate, and project. If your sprint were a single week, planning two things, estimating all the things, and "projecting" the sum of all the foregoing adds up to... Quite a lot.

You'll spend a large portion of your time doing these... fundamentally non-agile things.

Scrum is basically Waterfall, packaged as a lot of mini-waterfalls and sold as "non-Waterfall".

You can't run a marathon as an endless bunch of sprints; a marathon is fundamentally different from a sprint.

I don't know why you're being downvoted, this is correct. How you make schedules and roadmaps in a scrum world is you track some conversion between difficulty as estimated by each developer to the observed time it takes that developer to complete. Then you write up some cards that you think encapsulate the work you want, have the devs groom them by splitting, recombining, and rating their difficulty. Then you total up the time of the cards, add some buffer, and report that as your estimated completion date.

Then you run the board in priority order like any other backlog tracking how additions, removals, or changes in priority affect the completion date. At all times the work gets done when it gets done, and the devs never have to think about more than the current sprint and the next deliverable. Anything not in the current sprint is subject to change.

Because all of this quickly moph to useless ceremony. Managing a project and doing it are orthogonal. But there’s a relationship between the two that, if managed well, leads to a successfull completion. And that relationship is communication.

At each step of the doing, managing should have feedback so that it’s know how expectations are going. Then decisions are taken that influences further doing. There is no need for all the splitting and grooming.

A project can have a deadline (soft or hard) or not. It can depends on other projects and other projects can depend on it. A project can be planned, cancelled or paused. And their duration can vary. Then you assign the project to a team (can be adhoc). The team then decides how to get it done.

I mean this is absolutely true but the goal of this flow is to take very little dev time to enable the project managers to asynchronously (meaning not bothering the devs because the report can be derived entirely from the board state) give project status updates and updated milestone estimates to the higher ups, and get out ahead of potential issues and blockers (like dependencies on external teams like design).

No company is going to give a project to a team of devs with a deadline and then let them fuck about with no observability into the team's work until the deadline. This is the "team" deciding how to get work done, the person conducting the ceremony should be the direct people/work manager for the team.

The role of the project manager is to provide the observability. I strongly believe there’s no metrics collected at the team level that maters in terms of the business objectives other than progression. Something may be classified at hard, but once it’s got done once, replicating it is easy (assuming resources are available).

Inside the team, it’s another world and that would simply depends on the teams. Maybe it’s a senior with a few juniors and the former is just handing down detailed tasks to the latter leaving the toughest issues for himself. Maybe it’s a collection of experts and it’s a chaotic collection of tiny tasks that everyone takes at random. The project manager just needs to interact with them, measure “progression”, ensuring communication across teams, and updating everyone about priorities.

Handing down the process from high has a high chance of harming the teams.

> the goal of this flow is to take very little dev time to enable the project managers to asynchronously (meaning not bothering the devs because the report can be derived entirely from the board state)

Yeah, sure. The Kanban board.

Then you question the devs ability to predict a unknown piece of softwares complexity 3 months from now and put your own numbers down .

That sounds

1) Like the ideal theoretical Scrum. (I've never actually seen that in practice.)

2) Like a lot of converting, estimating, splitting, recombining, and rating. (So, that's a full-time "Professional Scrum Master" position, then? What happened to "Agile teams manage themselves; 'scrum master' is at most a rotating part-time task"?)

Aren't then all projects waterfall projects? I cannot think of a project that didn't have some hard or soft deadline ever.

Within project management, there are predictive, adaptive, and hybrid approaches to structuring a project. Predictive is waterfall, adaptive is agile, and hybrid is a mix.

Yes, everything has cost, timeline, and quality requirements, but the way they are represented or discussed vary a fair bit.

Yes. All projects essentially follow the same cycle: planning, estimation, execution and QA, delivery. Then, you get some feedback and start all over again.

What makes agile / scrum different from other projects is the constrained timeline. It's 1 week to delivery. Then, you get feedback and plan all over again. The major drawback to this approach is that some projects (including many software projects) are impossible to fit into a short schedule. The big benefit is, when Scrum is possible, the rapid iteration allows for products and services that are truly tailored to the user's / company's needs today, and not their needs six months ago.

The constrained timeline tends to cause a lot of "policy determines mechanism" behaviour though.

I recall having a code-review conversation with a co-worker that ended with him saying roughly "I can see your case for (minor change that dovetails with the change he was working on) but it's already the second Thursday of the sprint."

I've also seen the organization complaining "we want 90-110% predictability of points delivered". I know the intent might be to encourage people to get more accurate estimates, but there are upper bounds on estimate quality, especially for tasks where it's "30 minutes of coding, and between 1 and 62 days of negotiating details with a third party to get signoff."

The takeaway I get is that Scrum basically says the most important thing is to produce a predictable quantity of work, not necessarily that the work is good or fits the actual need. It reeks of the sort of metric Wall Street would love-- I can see someone saying "Story Points/Quarter Line is going up!" ebulliently.

> not necessarily that the work is good or fits the actual need

Producing work that fits the need should be the goal even if it means delivering fewer points of work during a sprint. Of course, like you said, the focus is often the other way around because the policy sucks.

Many projects have a deadline, but managers still enjoy pretending that they are doing Scrum, because it makes them sound enlightened.

"You need to get this project done in 6 weeks, but because we are agile, you can choose which parts you implement during the first 3 weeks, and which parts during the second 3 weeks. Also, I am not really sure about the specification, and some important parts may change halfway, but that's okay because you guys are agile, right?"

Basically, agile was supposed to mean "project deadlines are unpredictable, let's just focus on the tasks we are currently doing (Kanban) or let's focus on one increment at a time (Scrum)", but instead it means "you are responsible for meeting the deadline, but I am not giving you the full specification at the beginning, and instead will just tell you the requirements at random moments when they come to my mind".

EDIT:

Some parts of this article are just triggering to read.

> Cons of Scrum: Resistance to Change Mid-Sprint: Scrum's framework can be rigid within a sprint, and any changes occurring within the sprint could disrupt the team's flow.

Translated to plain English: Some companies change their mind about the product so often that they are literally unable to plan even for the following 2 or 3 weeks.

> Dependence on Stand-Ups and Meetings: Scrum can be meeting-heavy which could potentially lower productivity if not managed correctly.

Stand-up done properly takes 5 minutes. What other heavy meetings are we talking about? The retrospective and planning that happen once in 3 weeks? Any meeting on top of that is a part of your company culture, not Scrum.

> Not Ideal For Solo Workers: If the team is too small or primarily consists of independent workers, Scrum’s benefits may be less noticeable.

Even as a solo worker, to be told what needs to be done during the following 3 weeks, and then to be left alone during those 3 weeks, would probably be a huge improvement for many.

Reply on news.ycombinator.com