My question is this; what alternatives are there to agile? I know there is the waterfall method, but from what I understand we as an industry moved to agile because of the weakness of waterfall in the internet era. What other alternatives do you suggest? Where should we look for improvements?
It minimizes the time spent on unnecessary bureaucracy and ceremony, while still giving you the transparency and flexibility behind Agile. Supervisors and such can look at the board and see what the team is working on and what stage they're at. And when emergency things inevitably come up, that's when you pause what you're working on, temporarily put that in the "on hold" column, and work on whatever the new critical priority is before going back to your original work (usually) or else pivoting altogether (which often happens in more top-down orgs).
A Kanban is by nature not prescriptive, but after-the-fact descriptive. It respects people over processes – a fundamental part of the Agile philosophy that too often gets buried in dogma – by respecting each worker's autonomy while also giving the team as a whole flexibility. If you need to change things up, you just send a few messages or do a huddle instead of spending half the day arguing about points and then arguing about them again in the 2-hour retrospective.
In the most dysfunctional orgs I've been a part of, it wasn't really Agile anything or any particular tool that was the problem, it was that they were so middle-management heavy that most of the dev time was spent managing up instead of coding. That isn't a something tooling can in and of itself solve, but I've found that the heaviness of the tooling is often a good proxy for the dysfunction of the management layers. In that case I'd fight to simplify things and make work more efficient, or ask for a transfer to a more efficient team, or just leave the org altogether. When there's that many head chefs in the kitchen, every minor feature becomes a political battleground and no real work will get done, no matter your process.
A team with a good work ethic and some milestone goals to go to and a "Take from the top" mentality, Kanban is perfect for what needs to be done.
Can't take from the top "because of reasons"? Thats a conversation with the people that particular problem involves and things are re-prioritised.
I'll never understand removing a whole day of productivity for ceremonies to plan being more productive.
Async standups via Slack using Geekbot are absolutely fine, A daily simple async retro for teams on a different timezone also help massively for synchronisation, discipline to update tickets with progress and a push regularly mentality all helps with the sync problem if across timezones!
If you need to get more granular than an open Kanban and are time bound, it’s just Kanban that refreshes some interval (2 weeks etc…) with a triaged backlog
Realistically the basic winning set up is:
0: Know what you’re building and why 1. Feature/bug funnel 2. Triage to: Next iteration Kanban, prioritized backlog or deleted as unnecessary in forecast window 3. Deliver with unit testing based on Prioritized Time bound Kanban 4. Move Prioritized backlog into next iteration (go too far ahead at your own risk) 5. cut line: return task to step 2
Every step is critical here actually and breaks without each.
Cloning data is so low cost. Cloning a car is high cost.
It makes sense to tame the complexity and think waterfall vs. this or that but we aint building cars or houses.
I think there will always be some tension between developers who need some undefined and undefinable amount of time to produce work, and managers who need to protect timelines for the business's (and other teams') sake, and the only real solution that I've seen is to underpromise work on purpose, every time.
Maybe you lose a little productivity only aiming for 70%-80% bandwidth to start with, but that's way better than aiming for 100% and then not having any bandwidth left to deal with the inevitable bugs and sudden issues and help requests from other teams. And then suddenly it's the end of a cycle and everything blows up. A steady, slow pace helps prevent that terrible crunch at the end and makes work easier for all your employees and your customers don't get saddled with an explosion of bugs with every release.
---------------
Separately from all that, my current job uses Shape Up and Basecamp (https://basecamp.com/shapeup) instead of Agile or a Kanban, which is a different enough methodology that it's worth considering if you've never looked at it.
Personally I don't really like it that much and wouldn't recommend it (especially Basecamp, which is way over-complicated and slow and not very code-friendly), but the other devs seem to really love it. Perhaps it's worth a look and you can decide for yourself?
We do, but many times customers are paying many thousands of dollars for feature requests and have particular deadlines they want it by. Especially in our industry where there are a handful of competitors fighting to get huge contracts. We sell to insurance companies, so there is a lot of legacy software being replaced.
> and the only real solution that I've seen is to underpromise work on purpose, every time
Yep, we've become much better at underpromising in order to protect ourselves
I suppose it's the same with software features.
What, is "Agile" percieved to be so tightly bound-up in some particular methodologies (or trademarks?) nowadays that your seemingly quite agile methods and tools aren't part of it?
AFAICS Basecamp[1] -- and certainly Kanban! -- is agile.
---
[1]: If I recall correctly what that is.
Some companies will take the Agile philosophy (originally simple and short) and pervert it into a waterfall by adding extreme Scrum ceremonies like endless points poker (https://www.atlassian.com/blog/platform/scrum-poker-for-agil...) and detailed retrospectives (https://echometerapp.com/en/retrospective-tools-online/), sometimes with the help of outside Agile coaches. Unfortunately, this corrupt version of it seems way more popular than the original Agile philosophy (which, yes, a simple Kanban can do).
Scrumfall warps the whole philosophy from small chunks of iterative autonomous work into quarters of pre-planned top down work, just broken down into absurd things like fibonnaci numbers or t-shirt sizes instead of hours. It makes middle management look organized at the expense of decreasing worker productivity, basically by hiding micromanagement behind tooling. Uses a lot of ceremony and jargon to do a waterfall by another name.
----------
Typically that's done in other tools, like Jira plus outside ceremony software (yes, there is an entire SaaS niche for these ceremonies).
Basecamp doesn't do that, to its credit. It is its own workflow (Shape Up).
I dislike it for other reasons, but less so than Scrumfall. Basecamp the software is slow and doesn't format code very well, and is pretty disorganized (multiple projects, kanban boards, chats, message boards, to-dos, check-ins etc lead to many sources of truth, and it's impossible to find anything even a week later). Shape Up the methodology is too vague and abstract IMO and has very slow iterations and lacks a focus on customer needs and wishes. But both are still a huge improvement over Scrumfall.
> It's not so much Basecamp, but Agile mixed with Scrum and then enforced very strictly that's the issue.
Namely, how the scrumsters and other hucksters have taken this "agile mixed with Scrum" and called that Agile-with-a-capital-A. Or, as you seem to be saying, taken Agile-with-a-capital-A and mixed it up with their own shit and saying that that's The Real Thing[TM]. Is there even such a thing as Agile-with-a-capital-A? I wonder, kind of doubt it... The whole idea seems about contemporaneous with the beginnings of the corruption of the original concept, so I suspect it's theirs.
Either way: Don't let them get away with it! Don't even talk about "Agile", with a capital A, because that implies there is a hard-and-fast definition for someone to usurp. And if people think there is such a thing, some such huckster will inevitably usurp it.
When I point out that, done this way, it goes against the entire philosophy of the original Agile Manifesto... I just get shrugs. People don't care what it used to mean; when they say it now, they mean the points and ceremonies and masters and the whole ugly shebang. It's not a battle I have the energy to fight.
When a workflow isn't like that, but is just lean & simple on its own, they don't go out of their way to call it Agile or agile, uppercase or lowercase. It's just "a simple workflow" or something like that, or else some explicit other workflow (like Shape Up). I think a lot of folks have been burnt out by Scrumfall and try to practice alternatives.
I've made a point to start asking potential employers how they handle project management. If they say Agile of any sort, I'll assume the worst and just walk away...
If you can win any concessions over overbearing dogmatic Agile, that's already a pretty big victory, IMO. The tooling is secondary if you like your team and managers and work can proceed without anyone getting frustrated or too annoyed. It's a cultural thing.
I'm not a huge fan of Basecamp, but it's not the worst either, and it makes the rest of the team happy. That makes me enjoy working with them, and it all works out in the end with very little stress or panicking.
My last job had some sort of half-configured, mostly broken Jira put together by some powerful being who's long since left this plane of existence, abandoning his creation to his unloved mortal children. No one really knew why the columns had the particular workflow limitations they did, what our points were supposed to represent, how our work tied into other teams' work, how their points worked, etc. We didn't even have compatible Atlassian instances, so even though we all used Jira and Confluence, nobody could see anyone else's. I tried to point out some of those problems in a detailed report, but they told me to hide it so it doesn't embarrass them, and then hired an Agile consultant to double down on everything that was broken. I quit two weeks later and am much happier now because of it (much poorer too though, lol... can't have it all, I guess).
If you look at all of the processes, tools and ceremonies available to ou from various agile methodologies - you can tailor things to your liking.
I was in teams where scrum actually worked, up to and including the story-pointing and backlog-requiment giving us accurate estimates of how long features will take to develop.
And then we had more ad-hoc/timely work for some quarters and we dropped most of the plan/sprint/refine structure in favor of more simple kanban board.
2. Programmer Anarchy by Fred George on YouTube is an interesting idea.
The original agile manifesto though is still valid. Guiding principles is all you need
He calls this the agile industrial complex and says that anyone using agile with capital A is not referring to the manifesto but the industry and are selling you that.
Agile is Dead - https://www.youtube.com/watch?v=a-BOSpxYJ9M
Read the agile manifesto and tell me what you want to do that isn't in there.
The beauty of PDCA is that it is an adaptive framework. Meaning how it’s applied to my team will be different than your team. That’s a healthy development that relates to the fact that different people will work together differently. (side note: agile is often used as a synonym with pdca and it can confuse thing bc Agile tm is what a lot of people have bad experiences with)
i wrote a bit about my experience using agile: https://hedgerider.substack.com/p/agile-for-anarchists
It's all about communication and hiring. I've found agile to ensure the bottom 10% participate in important discussions (stand-ups, refinement meetings, feedback on process in retros).
If you hire the right people that take initiative and over-communicate, a lot of process suddenly seems unnecessary.
New issues are added to the list based on priority. And only “emergency” issues can pause current work to be paused.
Everything else is done face to face as needed without formal meetings.
It’s simple. It works.
While it took several years to get people on board with Scrum, it finally started to pay off, where everyone was speaking the same language, dependencies were being called out and put into other team's backlogs, and the various ceremonies started to bear fruit, improving how the team was working.
When that playbook went out the window it was chaos, and it's been that way ever since. No one knows what anyone else is doing. Work is being duplicated all over the place. There are no priories... where everything is a priority and it shifts by the hour with new things being added. Everyone is in a firefight and doesn't see a way out.
The "do your own thing" approach probably works great for small teams and organizations, but quickly falls apart in large organizations with dozens or hundreds of teams trying to work together. The new guy who threw the playbook out the window was from a company 1/10th the size of ours. He doesn't understand the scale and that has been very clear.
I'm not advocating for SAFe here, I think that's its own nightmare. But some kind of shared framework so teams can work together and respect the boundaries of other teams is not a bad thing... whatever that framework is.
Within Scrum there is the idea of the retrospective, to adjust things as needed. If a team isn't seeing value in standups, planning poker, etc... don't do them. Things like that really only impacts the internal team, and the larger organizational cooperation can still exist. For example, my team never assigned points as a group, because it didn't make sense to us. The effort involved in a story is dependent on the skill and familiarity of the person working on it.
Second, don't pick a specific process. Develop a process. Select from the broad collection of ideas that go into processes, the components that you want based on their effectiveness or utility.
https://en.wikipedia.org/wiki/Software_development_process
The key things to decide when developing a process:
Feedback loops or no? If you don't like reality, then don't use feedback loops. For the rest of us, reality is what we live and work in so incorporate feedback loops. Don't use hard boundaries between phases with an assumption the previous work was correct. This means likely pushing for automated, regular testing (verification) and regular "customer" (whatever that means in your context) feedback (validation). Use the results to update plans, designs, requirements, and the system itself.
Small batch or big batch? The larger the work you deliver at once, the higher the risk. Delivery is when you get validation (that you built the right thing). If you have a team of 1k people building out your hot new shit and deliver after 2-3 years, you may find you spent a lot to build the wrong thing. Deliver smaller batches incrementally and you'll get validation (and verification, but critically validation) along the way. This also means you have to rollback less if there's an issue, if you have to roll anything back. Deploy a new validated (right thing) service after 2 years but find out you have a critical design flaw so it doesn't handle more than 1k concurrent users, well you may have to eat the scaling costs or rollback the release and fix the design. Smaller increments, better feedback, lower risk.
BDUF or no? Big design up front means committing (it's a design) to a lot of unknowns. Is the design even going to be relevant when you release? Is the time spent on it worthwhile? If you're delivering in smaller batches you get feedback and can adjust the design, but then why spend so much time designing everything? Design just enough between releases, how much is enough? Judgement. You know your team and market, you figure it out.
Waterfall: No feedback loops, big batch, BDUF. It's basically the highest cost, highest risk approach. It's stupid for any project that's going to last more than 6-12 months. (Any project that length or shorter that's not totally novel is likely to succeed or fail regardless of chosen process.)
Incremental (Classic): Waterfall with 6-12 month increments. Fixes the feedback loop and partially addresses batch size problem. Still has BDUF. Reasonable, but not great because you're still spending a lot of time on the design that could be invalidated.
Spiral (Classic): Incremental without BDUF. Some design and requirements at the start, but mostly done at the start of each increment which is still usually in the 6-12 month (maybe shorter) range. Addresses many of the issues of the above.
V-Model: Waterfall with much stronger emphasis on V&V, permitting some feedback as you go through the V&V portion of the work. Pair this with Incremental or Spiral and you actually have a somewhat reasonable model. Stick to V-Model as Waterfall with better V&V, you still have the big batch risks and BDUF problems.
If you look at the actual ideas in Agile and not just Scrum, you'll see that it ranges from somewhere along Spiral (just enough design and requirements to hit an MVP, evolve that toward your final product using feedback along the way) to the more extreme form of Kanban style where you work and deliver very, very small batches (potentially delivering every small change many times a day).
The big things to take away from every one of the models: Feedback loops reduce risk and increase the chance of success. Small batches reduce risk and increase the chance of success. Design up front, but not BDUF, reduces cost and some risks (that you build the wrong thing because the decision was made before it should have been).
Take those three things and then figure out the specific techniques (wherever they come from) that help you out. TDD is basically the tightest feedback loop you can get for software verification. Is it appropriate for everything? Maybe, maybe not. Things of that nature.
NB: Spiral and the various Agile methodologies and techniques work even in critical and safety systems. In aviation for a new aircraft, building a safety-critical LRU the first deliverable might just be a form and fit check that supplies canned messages over the avionics network (this is used in initial integration testing on the ground). The next deliverables will push toward meeting flight safety requirements for the first flight tests. Then the next series will add capabilities required for certification but not for flight test. The final series will be further "quality of life" refinements that the customer wants, or maybe to work with specific variants for specific carriers or nations.
You don't need Waterfall or BDUF for anything.