Business leadership is technical, they create the requirements with technical leaders, those leaders build out the roadmap. I don't believe in 'agile' but I think 4-6week chunks of work broken off and worked on by a small team (2-4 people) works well. I like to see small design doc to ensure open questions are ironed out that gets signed off on by stakeholders - everyone should be committed on the vision and these signoff should happen relatively quickly, ideally comments resolved and go/no-go decision within a week.
The small team should have a lot of support in terms of an infrastructure platform, strong culture and tooling for development/testing, project management set up for them, an escalation path and check-ins where they can raise blockers. There is a template but essentially the small team is left to work how they want to work.
After the 'chunk' is delivered, there is a week of wrap up, and then a week of maintenance where people are allowed to work on whatever they think is the most pressing issue.
Very detailed design documents can also be lovely. I've personally worked at a few organizations where expected behavior was ironed out before we started building it. (Banking, Engineering etc. will be used to decision flows, so this can be common.) The Million Man Month covers the effectiveness of good schematics.
However the technical people needed to work them out with stakeholders can be expensive to have fight with stakeholders for ages, so it tends to be rare. And of course many domains are unknown, so you just keep reiterating until something sticks.
Modern agile sucks, but if you read the old discussions on c2.com of how agile appeared e.g. https://wiki.c2.com/?AgileProcesses there really is a lot of value to find, learn and apply. Of course, the ninjas, blackbelts and cargoculters kill that.
An MS-DOS based program in GWbasic, or Turbo Pascal from the 1980s, or a Visual Basic 6 prototype that someone wrote in the 1990s and still gets the job done, or an excel sheet/google doc that someone does to do the calculations "by hand", are all excellent requirements documents.
They do the work, are executable (so you can test against their behavior), and already account for all the normal error handling, etc. The people who wrote them saved you a few trips over the waterfall, and perhaps a decade of grief and work.
Your closest bet today is to fire up Lazarus anywhere, or VB.NET on a windows box and quickly build the prototype. Once everyone agrees on its behavior, then you're back to the races again. Get buy in on a single quick and dirty prototype, then scale up from there.
They can be a wonderful resource for the validation tests, but a developer needs a model to start. The documentation of existing tools may be a nice requirement document, provided it is exhaustive enough.
By the way, every time I was requested to implement something "exactly like this gizmo here", I proposed to just keep using that gizmo there, and then the discussion became interesting: "No! We want the same, but...."
As soon as the "but" was pronounced, the person in front of me realised the gravity of the situation: they didn't know what they wanted, and by handing me an ancient (despised) tool they were just planning for me to fail and for them to throw me under the bus.
I’ve seen design docs that are vague, and design docs that are so detailed and specific that they can’t be kept up to date. I don’t know that anyone has found a happy medium.
The week of wrap up and the week of maintenance is so important, and has basically never been there at places I have worked.
Managers reading this - if you constantly jump from new features to new features you will ensure that your developers are forced to cut corners, make an unmaintainable mess, increase bugs, development velocity will slow and developers will burn out.
It also causes incentive alignment problems, if I push myself to deliver great quality on-time, and I’m striving and working hard, then I don’t get so much as a “well done” and then an immediate enormous chunk of new work - you’re rewarding hard work and quality with large amounts more work, what’s my incentive to perform? Exhaustion?
I feel the same way, but the countervailing force is significant group of managers and developers alike who really truly hate spending any time without a rigid structure. Having never taken the time to build a proper mental map, they are lost without a detailed literary. They're allergic to open-ended tasks and use process as a crutch for their lack of confidence.
Dealing with ambiguous technical problems is scary; there is a real prospect of failure, or going the wrong direction, or hitting an organizational blocker, or failing to anticipate changes... Some would rather work on an assembly line (and force their colleagues to as well) just so someone else can shoulder the responsibility for the hard problems. And their numbers are large enough to influence how software is developed.
I'm inclined to believe proper agile is a myth. I have never seen it done correctly, and it's always spoken about ideally. All forms of agile I have seen or heard about always breaks down in real businesses environments.
The Agile Industrial Complex is a horror show, but that doesn't mean it's not possible to do agile well.
There absolutely is a way of doing agile well, I've been involved in a number of teams that did. And it worked extremely well. In fact, we did agile way before the agile manifesto came out, and before I was aware of there being a name for the things we were doing. We were just doing them because they make sense, they make us go fast and they let us have fun while doing it. Which is basically what the XP people said when they started writing things down. They never claimed to have invented a brand new way of creating software. No, they were observing that certain teams were very productive, and looked at what those teams were doing. If there was a pattern. Spoiler: there was.
Anyway, I also introduced agile "practices" in a large company. Well, in a small team in a large company. We didn't do a single one of the practices the Agile Industrial Complex proposes and often mandates. The much more important team next to us did. They did all the AIC practices. We did the technical. And interacted closely. Did TDD, worked on trunk, paired when necessary, did stuff alone when not. Did the simplest thing that could possible work. ("Where's your database?" "We'll put it in when we need it". <later> "Oh we're done. I guess we didn't need the database ¯\_(ツ)_/¯" ).
The more important team next to us that was doing Scrum with the standups and whathaveyounot failed. We delivered. Hmm.
And if you can point to the practices being promoted by the AIC as being in direct and obvious conflict with, for example, what's written the Agile Manifesto, and can in fact point to ways of doing it right that are in harmony with the AM and in conflict with the AIC, then it ain't a No True Scotsman fallacy. It's a simple case of the AIC doing it wrong.
I too have seen great agile. However, it required the team to be in control of its own destiny. Namely, we didn’t have deadlines and the goals we reported against were impact. That meant we could run no-weekly sprints while safely fitting delivery into the goal reporting timetable.
In most companies, it seems management is incapable of measuring progress other than “will X be done before Y date”.
maybe the idea of "proper agile" is too vague to even be useful?
"That's not agile"
Has become one of the most annoying arguments I've ever heard. As someone who experienced a corporate takeover of agile "consultants", I can tell you, it is one of the hardest things to try and deal with people who have their own idea about agile.
"Proper agile" is too "team specific" that maybe it shouldn't have been a "manifesto", just call it good "team practices" and maybe it wouldn't have become such a cult
I’m adding that to my list of corporate tech paradoxes
It joins:
- Innovation departments being built the least innovative departments you’ll ever meet
- HR departments being the worst at dealing with people
I always enjoyed the irony of rigid adherence to agile processes. My philosophy has always been to ask "what are our goals" and then figure out how to make our process be in service of those goals. Scrum does provide some useful frameworks for estimation and planning and continual reflection & improvement.
Agile as a noun is a myth. Agile as an adjective is a journey. When I've seen a company being agile and responding to change it's not because they are using some system they learned at a seminar, it's because they trust their engineers to do the technical work, trust their product people to have solid relationships with customers, and empower both groups both in their individual roles and when communicating with each other.
All of this is to say that I agree with you. 'Agile Methodologies' are a crutch for companies that cannot tolerate agility
I'm not sure you have brought that reason. A sample size of 3 where only one did better than "fairly well" would not be my reason to advocate for "Agile" to be the "industry standard."
Across my sample size of about 7, half were maybe better than terrible, but only two were good enough where I would say it helped more than it hurt.
The tech industry I think would do well to more rigorously study "Agile" and do some A/B testing. Unfortunately this problem space feels like trying to A/B test forms of government. The downsides are generally known after the fact, are context specific, and there are few good ways to run a control
same for the legendary "maintainable/evolvable/perfectly encapsulated code". yes, until the team is very skilled, everyone is disciplined and there are tight processes around learning the architecture. 3 bad hires later because "investors want growth!!1" and you're done :D
cool links, thanks for sharing. I also share your feelings, but reality (or burnout) is starting to take its toll on me and I see too much uninterested people working as SWEs nowadays. I mean, tooling is probably part of the problem, but quality is going downhill real fast, with people with 2/3 years on the job not understanding simple things like HexArch or basic patterns (not advocating for anything, just mentioning something that should be common knowledge in 2023).
I'm starting to think that if we want to maintain this "race to the bottom" pace, we need a more industrialized/blue collar approach and be more less about the person and more about the tool. Most jobs in my area are web crud controlling a transaction script. there is no problem to solve.
I mean, tooling is probably part of the problem, but quality is going downhill real fast, with people with 2/3 years on the job not understanding simple things
I agree but I also wonder why we would expect them to.
Many coming into the industry have had little formal education in CS or SE. Employers providing substantial training is mostly a thing of the past because retention and professional development for employees has mostly been deprecated in favour of the rapid job-hopping culture. And for a while now it's been such an employee's market that developers haven't needed to invest their own time and money into professional development in order to progress their careers.
So even for relatively senior devs it's easily possible that they could have little academic education, little professional training provided by any of their employers, and little incentive to spend their own time studying. Their understanding might come from nothing but a few years of experience working on only 2 or 3 different products and - if they're lucky - some ideas they've been exposed to through more experienced mentors, team leads and code reviewers.
I personally believe our industry would be infinitely better if we could get back to the idea that professional development is important and employers should both look for people who've been learning and then support their people's ongoing learning themselves. Maybe we can even do that now that the gold rush is over and job-hopping every five minutes for a pay and title bump is no longer the most reliable way to climb the career ladder.
The key differences from the most common implementation of agile are bigger delivered chunks, multiple sets of smaller self driven teams, no highly prescriptive ways of working, and avoiding constant 'sprinting' with at least two weeks dedicated to bug fixing, maintenance, and retros/self improvement between 'sprints'.
Business leadership being technical cannot be overstated. At my current workplace, we’re not allowed to say the word refactor to management as that freaks them out. My current place also has the most spaghetti code that I’ve ever seen in my life with more spaghetti being produced on a daily basis.
We technically have technical leaders, they used to be engineers eons ago but I don’t think any of them could solve first 3 days of advent of code to save their lives.
It's good to trust your people. You want to foster independence among teams, can do spirit. But most orgs seem totally out of touch with the tech. Too many companies use only business success to discriminate on. And that's just too random, too chaotic to let the work be judged on, to decide how next to operate. There's too much decision making about where to go that needs a deeper level of consideration.
The six week cycle with down time in between chunks can be very effective. The crux is to make sure those blocks are properly scoped to make the best use of everyone's time.
This reminds me of the excellent book 'Shape up' by the team from Basecamp. They also champion upfront 'scoping' to make best use of those six weeks. Highly inspirational book for technically mature organizations.
The small team should have a lot of support in terms of an infrastructure platform, strong culture and tooling for development/testing, project management set up for them, an escalation path and check-ins where they can raise blockers. There is a template but essentially the small team is left to work how they want to work.
After the 'chunk' is delivered, there is a week of wrap up, and then a week of maintenance where people are allowed to work on whatever they think is the most pressing issue.