Hacker News new | past | comments | ask | show | jobs | submit login

The best place I've worked at as a developer essentially had no process. It's also the place I really saw the benefits of having good managers (or a project manager, but here the manager took this role).

Essentially the "process" was:

- Someone gets an idea to do something, e.g. PMs wants to add a feature.

- The manager (maybe with the help of a dev) figures out which teams need to be involved (e.g. dependencies).

- Get a very rough estimate from developer. Are we talking a few days, a few weeks or a few months?

- Manager, PM and other teams get together to figure out priorities, schedules and who's likely to be working on it.

- Based on some discussions, areas of expertise etc, some number of devs gets assigned to work on this feature.

From here the devs know what they're trying to accomplish, what the constraints are and who to go to for questions (PM, design etc). They also know who else from other teams they're collaborating with and they just figure out amongst themselves how to get things done. They'll keep their managers and the PM updated on progress and any blockers.

Every once in a while manager etc have to step in. For example if some big that was previous unknown came up, there is a big risk, priorities need to be adjusted etc. But for the most part things just worked really smoothly.

Sometimes we need to give estimates and really hit it (legal or security issues, big marketing launch etc), but for the most part we were trusted to be doing things as quickly and efficiently as possible. So none of the commits, sprints and burn down charts BS. It's not hard to gauge develop's productivity based on output anyways. If there was something slowing the team down, we communicated the need to the manager and PM, and we worked on fixing it.

So for me, if you have good competent people that communicate well, you don't really need much process.

100% this. For a team of good developers this is by far the best model to get things done. SCRUM only serves to prevent a very bad team from doing even worse then they would do otherwise. However for a team of competent developers SCRUM is painfully stifling.

I think the above can simply be summarised as "real managing and communication".

As opposed to trying to create a couple of metrics because you don't really understand what people around you are doing.

Absolutely. I have nearly identical experience.

We are better off building over-all engineers that know what they are doing, than trying to catch up with the latest shiny thing (Scrum, Agile, Waterfall, Kanban, ...Jesus Christ)

I think the challenge with having no process is this: You have to rely on great chemistry and raw talent.

Look at Spotifys videos on their process. Every team is self-driving, because everyone knows how to do stuff. If you work at a company where there is no process, and not every is able to complete the whole task from A-Z, you end up with deadends and people who get stuck. If the culture doesn't encourage knowledgesharing, people end up making crappy solutions.

But how did you ensure that you udnerstood the requirements if you were potentially just left to it for a few months?

At the end was there ever an instance of the client not using what you produced because it wasnt what they wanted?

You have direct access to the PM and work closely with them. If you weren’t clear on something you ask, if you don’t agree with something you debate it out.

Like anything else there is no silver bullet. Sometimes you got the feature right, other times it misses the mark.

Not saying that this is not a good way to go, but I rarely see this happening in large complex projects, especially those that are on their way to delivering v1.0. v2.0 and beyond have a better chance of these types of "process" to work where the product evolution is not so volatile.

Registration is open for Startup School 2019. Classes start July 22nd.

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact