Hacker News Reader

The most valuable process I’ve ever instituted as a manager is design review. Absolutely hammering a design has proven to me to be the best way to ensure people have absolute clarity on the end state and have thought through the flow, copy and other-than-happy paths through the software.

“Grooming” is just breaking down things from there. Sprint planning is a formality. Ten-fifteen minutes.

I guess my point is you’re right, the rituals aren’t important in a high context team. The work is really figuring out what you’re building. Like really really figuring it out.

> The most valuable process I’ve ever instituted as a manager is design review. Absolutely hammering a design has proven to me to be the best way to ensure people have absolute clarity on the end state and have thought through the flow, copy and other-than-happy paths through the software.

100% agree.

You can change a design on the whiteboard rapidly and with practice you can really eliminate a lot of problems with a relatively small investment of time.

We just had one where a small group was stretching a bit in what they could take on, they ran into some issues and afterward commented "ok, I see what you're saying, we needed to work through that flow in more detail for a couple hours to avoid that week of pain".

> I'm getting old, I've been doing this for going on 20 years, I've been doing this since before fad workflows were really embedded in the culture. They were around but not nearly as common.

Me too (many decades), and we still manage things the same way I was taught when I started:

Pragmatic and flexible analysis of the project, and mapping out how best to approach this particular project or set of tasks. Projects are not all the same and different methods or approaches are required for different situations (e.g. whs with complex conveyor execution system+multiple app systems that can only go live in a big bang fashion, vs incremental improvements to ordering and order routing processes that can be chipped away at).

Generally it results in breaking it down into some major phases, (e.g. this qtr or year we tackle x,y and z, next qtr or year we tackle x', y' and z' and d,e and f).

Within a phase of work we talk about how to break it down, what needs to be designed up front, what can be handled as we go, which areas are we unfamiliar with and need to do some prototyping, etc.

Then we work, meet regularly, check progress, adjust our plan, adjust design where needed, decide when to divert some attention to going live and things like conversions/training/change mgmt, etc., lather, rinse, repeat.

I normally don't care much about process, because with a good team virtually anything works.

The one time I felt the need to enforce Scrum was when I worked with a very chaotic Product Manager that wasn't able to organize any work ahead of time, so everything was an emergency and micromanagement and rushing ensued.

30+ years here both as a manager and developer.

I usually just maintain a priority list and work on (or assign) whatever is #1 priority. It’s simple. It works.

It means I never say no. I just negotiate where to put it in the priority list. It’s a great way for people to realise the trade offs of what they are proposing.

I do like the spirit of "developer driven development". The developers (and testers and other vital roles) are the endpoints for discovering and solving problems. There should be clear routes and aims of communication so that a problem is known to the right people to investigate and fix it. By Conway's law[0], development is only as effective as the organization of the developers. So there should be structures that clearly facilitate the right amounts and kinds of communication to develop effectively.

[0] https://en.wikipedia.org/wiki/Conway%27s_law

I’m old too and have been doing this just as long.

What’s the most impactful task for the business right now? What’s the feedback from the sales team? What tickets are coming into customer support? What are our competitors doing? What do the marketing team need? You’re across all this? What about the other 250 developers in the business?

At some point it doesn’t scale. So maybe you need someone further up the pipeline identifying opportunities and looking at risks, talking to customers and aggregating the data so that we can be focused on the most important thing.

Maybe you’ve only worked in very small companies over those 20 years but it’s a naive take on things.

> Building software just isn't as difficult as these workflows try to pretend it is.

The only rationale I can see for these frameworks is if you have a workforce that is entirely truly terrible workers.

It doesn't have to be entirely - if any one bottleneck breaks the communication and collaboration (not enough seniors to review? Weird deploy process? Too few/bad pms?) then people tend to reach for these kinds of structures.

It honestly takes a lot of trust AND discipline from the higher up folks to let dev teams work in the self organized, effectively ad hoc ways described in these other comments.

Consistent result of this was unmanageable workload and deadlines. I don't like agile all that much, but it leads to more predictable output and less pressure on developers.