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.
What we did then, and what we do now is what I will term "developer driven development". The developer picks up a task, often themselves, and works on it to completion. If there's a strict deadline, a PM might get involved, usually working directly with the dev(s) on the project. Other than that, the PM's job is largely just to watch over tickets.
I don't get the draw. We've had Agile and Kanban pushed on us before, and it's never stuck. We never got anything positive out of it. It only ever had negative effects on performance.
Is it just to help very poor communicators? People who can't be bothered to talk directly, so they need to waste everyone's time?
We don't do meetings. We don't need them. If someone needs a status update, they ask the person working on it directly.
Building software just isn't as difficult as these workflows try to pretend it is.
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.
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.
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.
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.
The absolute best work organization model I've seen is Basecamp's ShapeUp[0].
The structure it provides in organizing the discovery, design, development, and delivery process made for a very predictable cadence and enough focused time to feel like a dev team wasn't sacrificing (be it work life balance or code quality).
It absolutely works and creates space to do meaningful work, learn, and experiment.
I've delivered many successful software projects on small teams without Agile or any other other formal methodology. At two separate startups this helped grow us large enough to hire new executives who promptly inflicted "Agile" on us. (As in a plethora of tools and processes and roles. Evidently they didn't read the manifesto). Agile sucked all joy out of the profession for me. Both times, development speed slowed, budgets soared, bugs went unfixed, and the teams lost sight of the big picture of what they were building. Yet the executives stood by their decisions because they now had a sense of visibility and control, not realizing the true cost of that.
Does anyone else suspect that agile, whatever its stated intentions, has been coopted as a smokescreen for micromanagement?
20 years ago I worked on a large non-it related project that was slipping and I was tasked to call at the end of each day every team working on the project to ascertain the progress they had been made that day. It made me very unpopular as there was a tacit lack of trust in the process. Back then I feel, it just was not done to make skilled workers explain themselves on a daily basis. I suspect the younger generation have been cowed and normalised to a much higher level of scrutiny leading to creativity and joy being sucked out of the working day.
I hate sprints. Developers are not machines. We don't crunch through work like an assembly line worker. We don't work at a consistent rate. Sometimes, shit happens you couldn't possibly predict. Sometimes, you want to go work on something else for a while. Sometimes we can't accurately say how long something is going to take until we're half way through.
I just don't understand the point of boxing yourself into a set of work for X weeks when you could just use Kanban and pick up/put down work when needed.
Every single person who 1) I take seriously and listen to, and 2) is very into agile methodologies have all been very consistent in that:
1. A work week is 5 days.
2. A work month is 20 days.
3. These are the numbers you plan within.
4. If you work outside those limits that is a process failure.
5. Process failures in an iterative process lead to incorrect/bad feedback into subsequent planning/estimation, baked in over-optimism, burnout, and ultimately failure to deliver a product on time.
6. Don't work weekends.
Doing otherwise and deliberately running your staff hot and into personal time seems pretty damn in violation of the spirit of:
"Individuals and interactions over processes and tools"
I actually quite enjoy the sprint structure. I have a hard time keeping long term focus on my projects, whether side projects, daily drivers, or point of spear. Sprints work well for my planning cycles and keep me hyper focused.
Sprints incentivize both good and bad compromises. Without some time pressure, some developers may go after interesting things that aren't necessarily in the company's best interest. With time pressure, tech debt tends to pile up, and corners get cut, documentation and tests get neglected etc... Personally, I will never again work for a company that does the 2 sprint with daily stand-ups. I am way less productive when I'm being shamed on a daily basis for falling "behind schedule" on some task that ended up being more complex than first glance would suggest. You may say "But that's not scrum!" Of course it isn't, but it is very often how it gets implemented.
What we did then, and what we do now is what I will term "developer driven development". The developer picks up a task, often themselves, and works on it to completion. If there's a strict deadline, a PM might get involved, usually working directly with the dev(s) on the project. Other than that, the PM's job is largely just to watch over tickets.
I don't get the draw. We've had Agile and Kanban pushed on us before, and it's never stuck. We never got anything positive out of it. It only ever had negative effects on performance.
Is it just to help very poor communicators? People who can't be bothered to talk directly, so they need to waste everyone's time?
We don't do meetings. We don't need them. If someone needs a status update, they ask the person working on it directly.
Building software just isn't as difficult as these workflows try to pretend it is.