This is another of those ideas that seem obvious with hindsight, but in the first couple of years of my career, the majority view really was that we gather the requirements, plan the design, write the code, test the software and then release it - usually on a fixed date we committed to months in advance.
Sounds great, doesn't it? All lovely and simple and predictable (and businesses loooove predictable). There's just one small problem: it's bollocks.
Even on what seemed like relatively straightforward systems, when the software was put in front of customers and end users, we'd get an avalanche of feedback about what was wrong with it. So there'd be a frantic phase of change requests and bug fixes to try and get the software into the ballpark of usable.
And it wasn't unheard of to be so far out of the ballpark that it ended up being abandoned. Just too much work. Quite often design decisions taken months earlier got baked in by all the code we added since.
That final frantic "stabilisation" phase was typically characterised by very frequent user feedback. Okay, we fixed that bug. Waddaya think? Okay, we moved that column. Waddaya think?
It doesn't take a genius to figure out that just maybe we should ask "Waddaya think?" earlier, and more often.
Instead of gathering all the requirements, doing all the design, writing all the code, and then testing all of it, it makes much more sense - for a student of risk - to gather some of the requirements, do some of the design, write some of the code, and then test that to get user feedback, so we can incorporate what we've LEARNED (in capital letters!) in the next cycle.
And it turns out that much - often most - of the value in software isn't in what we planned, but what we LEARNED from what we planned. So we need to LEARN as early and as often as we can. That's where the gold we're panning for usually lies.
The last 30 years I've been doing software development has been characterized by those user feedback loops getting shorter and shorter. In the mid-90s, my teams would tackle a bunch of usage scenarios, getting feedback every couple of weeks.
One common justification for why development teams need managers is that someone needs to see "the bigger picture", remove organisational obstacles, and broker agreements with other teams.
But in my experience, when I've wanted visibility of the bigger picture, or to remove organisational obstacles, or to reach agreements with other teams, it's been the management getting in the way.
It can be a self-fulfilling prophecy. Teams need managers because they need someone with the access and authority necessary to do these things for them.
And teams don't get that access and authority because that's not in the interests of the people they gave it to .
@zl2tod Autonomous teams don't need that, though. They're empowered to say "no", they nurture from within (e.g. mentoring) and engaging with stakeholders outside the team is very much part of The Work 🙂
What I find most interesting isn't the image itself, but that someone selling expert guidance on "prompt engineering" felt it was fine to use it in that context.
On related news, if you know of a place in London for my partner, motorbike and myself in London (from the 30th of June till the 7th of July) I’d highly appreciate it! 🙏🏼