Comment by karaterobot | Hacker News Reader

Comment by karaterobot | Hacker News Reader

The way I see it, Design Thinking is an idea is older than Agile, and has followed a similarly problematic evolution. At the core of both, there are a number of insightful and meaningful observations about how to approach difficult problems, and both offer some useful tools. But once both ideas got into the wild, people just mutated them until they were barely recognizable, made them incomplete and, okay, absurd. Consultants took them over and turned them into products: got a dysfunctional engineering team? Just add Agile. Need creativity? Sprinkle some Design Thinking on it. That's just what people do.

But I work in an organization that is still building its product side, and this stuff is not obvious to them. I talk to a lot of smart people who don't know that you should build small things and iterate on them. I meet a lot of people who don't think to question the assumptions of the problem statement. I assumed all this stuff was natural, because I came here from tech startups, where it's been in the air for twenty or thirty years. But, it turns out it's not all obvious, it has to be taught. I guess that, whatever faults they have, Agile and Design Thinking have nudged a lot of people in the right direction, when nothing else is apparently doing that.

All these frameworks are ways of turning what should be common sense into bureaucratic procedures that can be used without needing to think independently and thus more widely used. "Lean" is another example of this. They serve the dual purpose of sounding better to leadership types who don't like the idea of just studying the problem and coming up with a solution, and requiring less experience and autonomy to execute.

I mean, you're not wrong, but the problem isn't with the frameworks themselves.

The problem is that there is a cottage industry of companies, consultants and individual contributors trying to sell those ideas to everyone else, but common sense doesn't really pay the bills. So they must package "Agile" or "Design Thinking" or whatever into something that actually costs a lot of money and makes them feel important and authoritative.

"Individuals and interactions over processes and tools" doesn’t pay and actually saves money, so things like Agile naturally get lost in the translation.

Don't hate the player, hate the game...

It's difficult for leaders of legacy-built organizations to create space for common sense thinking, and when they see a room full of their employees creating and collaborating in new ways, then they pay to have you come back because for whatever reason they didn't have the time, skill or capacity to make their teams act more creatively and collaboratively on their own. Rarely is it transformative. Sometimes it's completely useless (especially when packaged into buzzword-y platitudes). Most of the time it's somewhere in-between just like any other process/culture/change improvement from leadership.

These leaders hire these companies and consultants because they were resting on their laurels instead of actively building culture while the legacy org was doing fine. Then comes a crisis or paradigm shifting moment and there is no recourse.

With visionary leadership and proactive management toward better culture and talent (which is hard to do consistently), said "cottage industry" would be much smaller.

I call that industry "holistic agile" because it is to agile what holistic medicine is to medicine.

Nah. Common sense isn't common, logical, or innate. It's important to communicate common sense, otherwise people just won't have it.

Those frameworks were created because those specific instances of common sense were exceedingly rare but still important. They were condensed into short lessons so people could read them, think for themselves about gains and loses, and adapt them to where they are needed.

The fact that leadership often can't do any of those 3 things right created an industry of fraudulent education teaching bureaucratic procedures. But that doesn't take anything from the original movements.

Two things consider: First, common sense is merely the accumulated human wisdom available to a group at one time. It's common sense today because Lean and Agile has made it common sense.

Second, we can think about these methodologies as duplo blocks, and smaller practices in concert as lego blocks. You're welcome to make more bespoke blocks, but iterating from first principles every time is just not necessary when we can rely on the common wisdom gained by using more common toolkits. First principles thinking is expensive and doesn't scale.

Planning is not common sense. It's a skill that takes years of practice, just like playing a piano or programming.

And just like programming or playing a piano, you can spend years of doing it and learn nothing because you were doing it wrong.

There are people who apply design patterns without really understanding them and there are people who apply planning methodologies without understanding them. I'd say that it's more common than not.

But we aren't teaching management "planning", we are teaching rigid structured systems for ticket tracking. We are teaching meaningless mumbo jumbo to people with zero experience, seemingly even with toy examples, of solving difficult or complicated problems that require expert input, and managing people.

Every single course I have ever seen on this stuff treats humans as black box cogs that perfectly do anything you define in a ticket, even when you do a terrible job defining something. That's not teaching management to plan, that's teaching management a board game.

Meanwhile my CS class on agile and project management was just managing a real, large, somewhat purposely overwhelming project so we could stress the system and deal with failures. It showed us the value that some structure could bring, and also how you often clearly need to step back from that structure to do actual work.

No different than CS classes dumping design patterns onto students.

I think you just had a good teacher.

Frameworks are created by abstracting a solution from a class of problems. Users adopt frameworks as they provide a solution to a class of their problems. A key benefit frameworks can provide is scale.

Now there is a class of people (framework industrial complex) that do not care about real solutions but see an opportunity to scale themselves leveraging frameworks to push them to unsuspecting victims, uncaring managers and their teams. As long as universal applicability and scale expands faster than bad press in places decision makers frequent the bubble expands and money is made.

Lean manufacturing in Japan has been a thing since the 50s, with a focus on kaizen, flow, pulling, etc, yet lots of companies still do work in batches today, to their detriment and waste.

Great points. Kind of resonated and caused a flood of thoughts - appreciative of it.

The kinship between design sprints and agile sprints can look like a match made in heaven… on the oversimplified views of details yet to be found, and can be useful if the problem and some possible solutions are unknown and need to be understood.

But once unknowns are better understood, it feels better to consider multiple methodologies.

Scrum oddly can feel great pre product launch, but doesn’t always make sense afterwards. It can really help get a lot done in some cases. But, is the team experienced, or not, and self directed or not, and how familiar are they with the domain they are working in.

My product consulting background revealed the value of a hybrid design-agile/waterfall loop that leverages the sweet spot of figuring out the unknowns and executing what was known in a way that the business could understand.

Product continues to teach me that there’s always lots to learn from other. Being too attached to one way instead of learning how the currents of each style can be aligned, or not is becoming a lot of fun for me, and I hope to be able to connect with others feeling similarily.

Except, as a technologist on the product side, being acutely literate and aware of what hardware, networking, and software can, and can't do today and in the next few years can become a bit of an unfair advantage when looking at a pipeline or roadmap, along with business trends or wishes of the business.

Design thinking allows people to come together to understand a problem and some ways to maybe solve it. I think that’s always been the biggest benefit it’s provided me, including letting the team learn together when a hypothesis turned out to be right and when it wasn’t.

What design can have a tough time with is not knowing the capabilities and possibilities where tech is involved to sovle it.

Too often, the outputs of Design sprints are thrown on the laps on tech to figure out, when technologist are human beings as well, are left downstream to pick up the pieces.. too often much to the chagrin to business degrees.

Design Thinking when driven by the business degrees can be a form of keeping more seats than needed at that design / influence / direction table.

I don't advocate for removing or reducing those seats, only increasing the seats for the people who can help give feedback on the feasibility of something in the given timelines and budget.

All to say there's not a better time for tech folks to be able to learn more business than it is the other way around.

This hybrid Technical/Business Analyst or Architect is increasingly here to stay, and you can't fluff your way through it as much.

Reply on news.ycombinator.com