4 ms·
Methodologies are a trap. The problem with any methodology is they tend to lead people to stop thinking about the context they are operating in. "The methodolo
by kenshi 9y ago
Methodologies are a trap. The problem with any methodology is they tend to lead people to stop thinking about the context they are operating in.
"The methodology says X, we should do X, why oh why aren't we doing X?" is a familiar lament in the development world. I have been there and done that, to be sure.
It really isn't going to matter what the Methodology says, if something or someone in the context means it isn't being adhered to.
If the person ultimately paying for the project isn't convinced by the Methodology, or wants to deviate from it badly enough, guess what? The Methodology will be ignored.
You should always advocate for what the Right Thing To Do(tm) is, but you should ask yourself first: what is the most important criteria that determines what the Right Thing is?
Sometimes writing the quickest, hackiest, throwaway code can be the Right Thing. It can be a horrifying truth for a software developer. Sometimes doing the ballsy re-write is the Right Thing. Sometimes letting a project fail is the Right Thing.
Sometimes last weeks context and decisions no longer apply.
More critical to project (and personal) success than any Methodology is gaining a thorough understanding of the context in which you are working in, as quickly as you can. And then doing all the Right Things that will make you effective within those constraints.
This means there is no Single Truth for software development. No easy answers. But there are a wide variety of principles you can draw from and apply and discard as needed.
Or as Bruce Lee put it: Be like water.
- oldpond 9y agoThe Single Truth about software development is that there is only one deliverable: working software.
- mmcnl 9y agoI would take that one step further and say the only deliverable is satisfied customers.
- zwischenzug 9y agoI would take that further and say the only deliverable is profit. Or more VC :)
- mmcnl 9y agoAlso true.
- kenshi 9y agoTrue story: was once asked by the co-founder of a company to sabotage the project I was working on. "Drive a horse and cart through it" were his precise words. So for my team, the deliverable was working software. The co-founder wanted another deliverable altogether.
- user5994461 9y agoThat still requires to specify what is a "working software".
- jrs95 9y agoWhat’s worked best for me is basically ‘agile’ but without a lot of what I consider to be the bullshit. Project manager and/or team lead prioritize new cards as they come in, and developers just keep working on them. No sprints, just keep pulling work out of the backlog as needed. Stand ups and most meetings can be replaced with quick updates via Slack, otherwise they can be organized as needed (they usually aren’t). We had agreed that estimation was mostly a pointless waste of time, so we stopped doing it.
- mmcnl 9y agoThis could work, but it relies on highly competent autonomous team members who trust eachother. Often not the case.
- jrs95 9y agoIt should be the case though. Competent, autonomous, and trustworthy is a pretty low bar.
- maxxxxx 9y agoI think that's called "Kanban".
- goostavos 9y agoI have never been happier or more productive under any other system than the one you described. We paired the agile stuff down to _just_ stuff we needed. Planning was bucketing things into a super coarse High/Medium/Low priority, and then off we'd go. We'd still give a quick estimation, but that was primarily used as a tool to gauge if anyone had "Thar be dragons" level hesitations about the feature. The opposite end of the spectrum is where I'm at now. Where planning meetings last _hours_ and are mostly an exercise in squabbling over how we're going to get the points to agree with the TPMs completely arbitrary projected view of how things should go which was somehow divined before actually talking to any of the developers.
- TuringNYC 9y agoIn general I agree with you, but that assumes that you have people (and management) with the sufficient big picture thinking. I have found that it is usually safer to follow methodologies even if they aren't perfect because the alternatives are worse when dealing with average or worst teams/management (and by definition that is like...half the world!.) For example, consider the concept of MVP (Minimal Viable Product). I once had a boss who kept re-defining the scope of the MVP until 18months in, we still had not completed the ever-expanding MVP. In light of these experiences, i'd rather follow methodologies to the letter just to avoid extreme abuse. For example, following some silly hard rule driven by methodology X that MVPs must be completed in 3mo would be helpful, even if arbitrary.
- mmcnl 9y ago"The problem with any methodology is they tend to lead people to stop thinking about the context they are operating in." Sometimes (quite often actually) that is precisely what we need. It would be quite bothersome to feel the need to explain the reasoning behind every decision and put everything you're doing in context. How about actually doing any work? Pick a methodology that fits your context, work according to the methodology and regularly evaluate the fit between the context and your methodology. Ofcourse, don't overdo methodology, but don't overdo not-methodology either. Try to find a balance that works. Don't let the means become the goal.
- agentultra 9y agoThis is what I call, development by a dozen managers. If you have every developer on the team on the look out to do The Right Thing then you be sure that you'll start replacing your decision-making strategies with whimsical fancy. A collective fiction, or methodology if you will, isn't supposed to replace individual thought with adherence to the all-powerful methodology. I'm suspicious of sales people with a vested interest in the methodology they're selling. A methodology isn't something you can purchase... the collective fiction metaphor is apt: you have to convince people to believe and adopt it. In my experience a team will adapt a methodology like Agile but the best teams will mold it to the way they do things. Their collective fiction needs to integrate their tribal knowledge, goals, experience, etc. There isn't Agile™ — there's Agile the X way.
- kenshi 9y agoThis is a great point. I don't mean to say everyone should be running around doing whatever they want. I consider the team, and working collectively in an effective way, of critical importance. I think what you call collective fiction, I call operating principles. If you have any pointers to learn more about this, I'd be eager to take a look. Thanks!
- nomoral 9y ago> Or as Bruce Lee put it: Be like water. So you are saying go with Waterfall?
- bayonetz 9y agoTangent: agile, waterfall, and the rest are just individual "methods", not "methodologies". Or at least they should be. Unfortunately it seems our living language is allowing this "-ology" to stop meaning "study of" or "branch of knowledge" and start meaning, well, nothing. If agile, waterfall, etc. are "methodologies", then what do you call the actual research and study of the methods themselves? "Methodologyology"? I get it. I like saying big words instead of small words for effect as much as the next person. For some reason, this one in particular really gets me. I don't know why.