[HN Gopher] Lean Meets Wicked Problems
___________________________________________________________________
Lean Meets Wicked Problems
Author : sblank
Score : 37 points
Date : 2023-07-27 14:03 UTC (1 days ago)
(HTM) web link (steveblank.com)
(TXT) w3m dump (steveblank.com)
| roenxi wrote:
| > Solving Disinformation/Information Pollution for the BBC
|
| This isn't really a complex problem; it is an intractable
| problem. It is very easy to solve disinformation - have a good
| editor who notes the quality of the evidence clearly.
|
| The _problem_ comes in to play because once there is a reliable
| brand, partisans /corporate suits/do-gooders/hacks see value and
| set around corrupting the brand to extract value from it. It
| doesn't matter how good the solution is, eventually someone will
| decide that reality is pulling in a direction they don't like and
| bam! disinformation and censorship.
|
| The BBC is not in the business of neutrality. They are a
| reputable front for British propaganda. Seems likely that one of
| the reasons the quality is so high is someone is purposefully
| keeping the channel clear so they can nudge the debate more
| effectively. Especially after we discovered what the US agencies
| were doing in social media with the so-called Twitter Files -
| professional government disinformationists embedding in media
| outlets is obviously the done thing.
| mistermann wrote:
| > It is very easy to solve disinformation - have a good editor
| who notes the quality of the evidence clearly.
|
| - how do you identify candidates?
|
| - how do you know that the candidate that is selected is
| actually what the judges think they are?
|
| - how do you know that the candidate is not at least partially
| compromised, on an ongoing basis?
|
| - for any given editorial issue, how do you know that the
| candidate is performing _perfectly_ (or, when you said
| "solve", were you perhaps _joking_ )?
|
| - _is that air you 're breathing right now?_
| j45 wrote:
| Editing every topic manually in the face of automated
| generation of misinformation may not be a solution that scales
| psunavy03 wrote:
| Narrator voice: _it 's not actually very easy to solve
| disinformation._
| cma wrote:
| It turned out that was Taibbi's own invention, changing an
| acronym so that it pointed to a government agency when it
| really didn't:
|
| > Taibbi claimed "the EIP was partnered with the government
| Cybersecurity Infrastructure Agency--CISA--to censor Twitter,"
| but the reporter mixed up the government agency with the
| nonprofit firm Center for Internet Security.
|
| https://www.thedailybeast.com/msnbc-host-mehdi-hasan-makes-m...
| psunavy03 wrote:
| > It is very easy to solve disinformation
|
| I don't know about that, but it is very easy to make statements
| like this which make your credibility go "poof."
| psunavy03 wrote:
| One could argue, according to Cynefin, that "wicked problems" are
| where Lean and Agile diverge. When you're operating in a
| generally-known environment where what's unknown are things like
| product/market fit or codebase behavior, it makes sense to
| operate in short iterations or kanbans with rapid customer
| feedback, while still trying to use Lean to drive efficiencies
| along the way.
|
| But if you _really_ have no idea what 's going on, there's no way
| to know what is "efficient," and so you have to fall back on more
| pure Agile, i.e. Cynefin's recommendations for the unordered
| "chaotic" or "complex" domains: do something small, analyze how
| that affected your environment, learn from that, and
| respond/repeat.
| kitotik wrote:
| > do something small,
|
| > analyze how that affected your environment
|
| > learn from that, and
|
| > respond/repeat.
|
| I could be missing your point, but this is precisely a core
| tenet of Lean - Plan, Do, Check, Act
|
| Agile speaks nothing of these sorts of processes(aside from the
| cargo cult enterprise scrum nonsense of course)
| dragonwriter wrote:
| > Agile speaks nothing of these sorts of processes
|
| Agile is less specific about the how, but is very much
| centered on team-led adaptation of concrete process to
| specific circumstances.
|
| Lean does the same thing, but actually talks about how to
| achieve that.
|
| (Lean and Agile are mostly built on the same ideas, but the
| Lean literature comes at the ideas from an engineering
| mindset, while Agile literature does it from a fuzzier and
| more touchy-feely mindset.)
| evolve2k wrote:
| The pissing match above has at its root a global namespace
| conflict around the term "Lean".
|
| To clarify, the underlying heirachy is:
|
| Shewhart cycle "PDCA" (1939)
|
| Lean manufacturing "Lean" (1988)
|
| Agile Manifesto "Agile" (2001)
|
| The Lean Startup [subset of lean] (2011)
|
| Lean around here often handwaves to mean the Lean startup
| with Lean manufacturing under that. Technically I'd suggest
| Lean on its own is really a reference back to Lean
| manufacturing and the principals of Lean developed by
| Toyota in the 1960-1980's in what they later named "The
| Toyota Way"
| dragonwriter wrote:
| You leave out Lean Software Development (2003-, there are
| several works from the same authors), which is fairly
| directly about applying/adapting Lean manufacturing to
| software development. (And is situated within the Agile
| space, but a lot more focussed on the meta-level process
| of controlling/adapting process than most Agile work,
| which often focusses on specific process that worked
| specific places, and gets easily bent to support the kind
| of adaopting canned process that is anathema to the
| Manifesto.)
| marcosdumay wrote:
| You seem to have missed the point of Agile.
|
| But then, that's normal.
| dragonwriter wrote:
| To be fair, its largely because the Agile literature as a
| whole is vaguely written on the most important points.
| marcosdumay wrote:
| Yes, everything is very unclear. It's also corrupted on
| most communication, either on purpose or by accident.
|
| Corrupting Agile was once a very profitable activity.
| kitotik wrote:
| Did I?
|
| Where does the manifesto talk about a process of any sort?
| It's a set of values. It doesn't mention anything about
| iterations, breaking things down, etc
| dragonwriter wrote:
| PDCA, in more humanities than engineering terms, is
| basically the final Agile Principle "At regular
| intervals, the team reflects on how to become more
| effective, then tunes and adjusts its behavior
| accordingly."
|
| https://agilemanifesto.org/principles.html
| marcosdumay wrote:
| This is PDCA:
|
| > Welcome changing requirements, even late in
| development. Agile processes harness change for the
| customer's competitive advantage.
|
| And the sibling has the one that states PDCA for the
| development process too.
| yencabulator wrote:
| Apparently they're also solving Ukraine's need to provide medical
| care to people wounded in the war, and their primary contribution
| is _to suggest using RFID bracelets_. Even if you fully accept
| that patient tracking is crucial, jumping to RFID seems wholly
| unnecessary. Wartime is exactly when you do NOT mess around with
| fancy tech and hard-to-source materials; there is not even a hint
| here of why barcodes wouldn 't be the solution, just weird
| fetishizing of RFID tech.
|
| https://drive.google.com/file/d/12a2aLdG25YaPUzFwpVlIeO346DU...
| bena wrote:
| This is hilarious, because it misses one of the core issues with
| wicked problems. Wicked problems are wicked because they are
| nearly impossible to theorize about.
|
| You cannot know if a solution is viable unless you actually
| implement the solution. So you won't know if you're right or
| wrong until it is too late.
|
| You can collect all the data, interview all the people, see all
| the things, and still do the wrong thing. And you won't know it
| until you've tried. Sometimes you won't know if you've failed or
| not for years afterwards.
|
| There are no good ways to approach wicked problems in general,
| because each has its own complications.
|
| So while it may feel good to feel like you've done something
| here, I question whether anything was actually done. Because
| there is no way to know if any of these proposed solutions are
| actually viable or effective.
| mistermann wrote:
| > You cannot know if a solution is viable unless you actually
| implement the solution. So you won't know if you're right or
| wrong until it is too late.
|
| It is certainly possible to sometimes know when a given idea
| cannot work.
|
| > There are no good ways to approach wicked problems in
| general, because each has its own complications.
|
| You are guessing, necessarily. That people are generally
| speaking not able to stop guessing, and realizing that they are
| guessing, is a lot bigger of a headwind imho.
| OldGuyInTheClub wrote:
| > I question whether anything was actually done
|
| It sold services. There's a big market for that.
| mrkeen wrote:
| Did you read the article?
|
| It didn't miss any of that. That was the point of the article.
|
| >> Cristobal and I wondered if we could combine the tenets of
| Lean (get out of the building, build MVPs, run experiments,
| move with speed and urgency) with the expanded toolset
| developed by researchers who work on Wicked problems and
| Systems' Thinking.
|
| >> Our goal was to see if we could get students to stop
| admiring problems and work rapidly on solving them.
| bena wrote:
| Yes, but none of the solutions will be implemented. It's
| ultimately navel gazing.
|
| And one of the qualities of a wicked problem is that you
| can't really run experiments. Finding out if (for example) a
| new method of teaching during early education will result in
| more capable college students has no experiment that you can
| run that doesn't involve just doing the thing. And while you
| can implement with "speed and urgency", the fact that this is
| an issue that affects people after many years means after
| you've implemented it, there is no more speed or urgency to
| be had. And you also don't get to know if you've done
| anything until the end. And also with all of the other
| confounding factors that go into the growth and development
| of human beings, you can't even know if what you did was the
| thing that made the difference.
|
| They're hard. Full stop. We need to approach them with
| caution and full realization that we are essentially
| replacing our wings mid-flight. You don't get to be wrong
| without things going very wrong. So whatever you do, you have
| to try and do it in a way that mitigates as much possible
| harm as you can perceive.
|
| And even if they did come up with a solution to one of their
| problems, so what. Because another quality of wicked problems
| is that they're fairly unique. What works for one problem is
| not guaranteed to work for any other problem. So even if
| these techniques solved even one of these problems, it does
| not help.
|
| We don't need tools to solve wicked-class problems, that's
| about as likely as perpetual motion, we need tools to
| identify them.
| OldGuyInTheClub wrote:
| I'm reminded of a recent thread: "The design thinking movement is
| absurd"
|
| https://news.ycombinator.com/item?id=36893635
| contingencies wrote:
| Steve I have read your blog posts sporadically for years and am
| running a startup working on a wicked problem area (fully
| autonomous food preparation, retail and logistics) and would be
| happy to provide a case study in practical approaches we have
| used. Incidentally I will be in CA in the next few months and we
| are raising.
|
| Frankly our best strategies to date have been common ones:
| business-level modeling as a means to ensure strategic validity,
| in-depth study of predecessors and competitors, commitment to
| rapid iteration, brainstorming, first principles thinking,
| breaking down the problem, broad and dynamic base of contributors
| (different professional skillsets and mentalities), extensive
| documentation, looking at the _whole_ problem, investing in
| developing required specialist skills, etc.
|
| After seven years of hard work according to public sources we are
| now the world leader in our space by multiple objective metrics,
| from which I would suggest we have been successful technically as
| well as financially.
|
| IMHO there's no secret sauce. It takes a lot of time and money
| and concerted effort. A lean / startup approach just allows more
| efficient execution.
| tgv wrote:
| The superficiality of the presentations reeks of consultancy. I
| wouldn't be surprised if all students ended up in KPMG-Deloite-
| Young. Even the smallest problem, something design ships
| something, only showed that the students had actually spoken to
| people, but not listened or understood, and it was smothered with
| a bad case of AI, the very thing called out at the start as an
| example of "not wicked."
| BaseballPhysics wrote:
| > The team working on the Mapuche conflict in the Araucania
| region of Chile, flew to Chile from London, interviewed multiple
| stakeholders and were back in time for next week's class.
|
| Jesus, for a _class_? Who are these people?
|
| I question the lesson, here. A wicked problem isn't one you can
| solve by flying into a country for a week, developing some
| incredibly superficial understanding, and then start proposing
| solutions. Step one, here, should be approaching these issues
| with deep humility, and this would seem to be the opposite of
| that.
| vessenes wrote:
| This is pointless armchair quarterbacking, and it's
| counterproductive to spread this sort of thinking.
|
| If you read the presentation from the Mapuche conflict team,
| you might come away appreciating the effort and
| recommendations. You'll note plenty of humility and humbling in
| the takeaway notes from the project. And, you'll also note
| there were Mapuche labeled as 'willing to talk' right in the
| deck.
|
| Especially here at HackerNews, I propose we generally stay
| positive on the idea of leaning in to solving difficult
| problems, and getting working on them rapidly. I believe it's
| better for the world.
| [deleted]
| detourdog wrote:
| It does seem more like satire.
| marcosdumay wrote:
| The entire premise is absurd.
|
| From the title, I imagined it would be a criticism of lean. A
| canvas describing your wicked problem must be an exercise of
| practical comedy, there's no other explanation.
| OldGuyInTheClub wrote:
| > Who are these people?
|
| Future management consultants.
| newprint wrote:
| My exact thought.
| mrkeen wrote:
| > Jesus, for a class? Who are these people?
|
| The people taking the class. Which they flew out for.
|
| > A wicked problem isn't one you can solve by flying into a
| country for a week
|
| A wicked problem is one whose solution can't be seen until
| you've started working on it.
|
| > flying into a country for a week
|
| Meeting the stakeholders.
|
| > then start proposing solutions
|
| That's sprint one.
|
| The alternative to meeting the stakeholders before working the
| problem, is working the problem before meeting the
| stakeholders.
___________________________________________________________________
(page generated 2023-07-28 23:02 UTC)