If Agility is the ability to respond to changes in a meaningful way, a huge part of that consists of the time it takes until this response is in the hands of the customer so that a feedback loop can form.
If that's true, what's the value of Discovery Epics or Stories, Spikes, Dual Track whatever...
@bbak The fastest version of “something small” is to me a prototype. Even a paper one! I LOVE inviting users to a #designsprint. Within a design sprint you can validate several ideas and iterate with just a few days.
@daverooneyca and I are doing a public AMA (ask-me-anything) on all things Agile on May 1 (next week). Bring your questions and get the perspective of two coaches who each have 25+ years of experience.
"Agile" is an adjective. It's not a noun, or a mindset, or a methodology, or a framework. It's just a word that was coined in 2001 by the 17 people who published this website: https://agilemanifesto.org.
@airwhale@davidsabine I don’t mean the inclusive language, which isn’t present in the translations (i.e. DE). I was wondering how the message would differ if the group of authors would have been more diverse, presenting differentiated perspectives.
In general there are lots of valid topics within the manifesto. However, it’s not necessarily covering the entire product mindset to me. We might need a new version, a #productmanifesto.
@airwhale@christianhujer If all roles are involved from the early stage, starting with the discovery the likelihood of surprises should be low. Having different perspectives helps to understand the problem. It also helps to build empathy towards users‘ issue.
I believe the stories should be created in collaboration, instead of being thrown through the fence by the PM. Worth mentioning: #productmanagement is responsible for the WHAT and engineering for the HOW.
Please, do not start your decision making processes or tickets with solutions.
Start your processes describing the problem you want to solve and the expected outcome. Let the team - people who will implement it - define the solution collaboratively.
If you (manager / boss) define the solution and expect the team only to implement it, you are just a #featurefactory and not an empowered, agile team. This is #agile in name only, a superficial one.
Trying to improve the wrong dimension of #UX will only lead to waste. Learn the difference:
Wonky products are confusing; their mental model doesn't match the user's. Janky products are conceptually fine, but buggy or inconsistent.
Jank manifests only at the hi-fi stage of development, and can be solved by UI redesign or backend optimization. However, wonk must be caught at the conceptual stage with lo-fi tools. You will NOT be able to fix it on the #UI layer.
I have to say I am not a fan of the postfix .match { ... } idea. If rust was starting out fresh it would make sense I think, but now it just gives a second way of doing stuff we can already do (similar to how we should not have both is expression and let chains). I don't see what problem it solves. Not needing to introduce a name (which is nicely descriptive) doesn't seem convincing to me and arguably the RFC has some example snippets that I'd question whether people even write that today
@veykril I wholeheartedly agree! I don't see the problem both should solve.
What's more is: Introducing new features to the language will make it harder to introduce very impactful[1] features to the language going forward, because there is always a cost in introducing new features.
One should go broad, not deep, unless it is very meaningful/important.
[1] by "very impactful" I mean features that enable things in Rust that are not possible today
I detest roadmaps. Roadmaps have dates. I never deliver on a date far ahead. I deliver when it is done now and prepare for what is next and later. Pipelines are way more efficient and better suited to prioritize new ideas! #productmanagement#productowner#pm#po#product
It's easy to say #Agile has failed - but it hasn't. Rather, the entire framework of "building good software" has failed. Our leaders consistently set goals like "do Agile" rather than "build good software" because it's a lot easier to set the former goal rather than the latter.
But there is an analogous domain that shows us an example of how to build a better relationship with our tools.
Many people are out here on these streets are making the extraordinary claim that adding glorified chatbots (literal "automated bullshit generators" using the philosophical definition of bullshit *) to every random product, app, website, object, organisation, process, and more will help people better understand the world, know things, and therefore take efficient and effective actions.
While we can assume there is a heavy dose of marketing insincerity and follow-the-crowd-leadership behind most of these claims, like with any grifter-driven hype cycle, at least some people do sincerely seem to believe glorified chatbots are really going to help their victims to access knowledge.
For this last group, I have to wonder if people are aware of and have considered the philosophical definition of what "knowledge" is? Knowledge is a justified true belief, with all three elements being crucial. [🧵 1/2]
Philosopher Harry Frankfurt, in his classic text On Bullshit, explains that the bullshitter “does not reject the authority of truth, as the liar does […] He pays no attention to it at all.”
With a chatbot, if you are credulous enough, you can certainly create beliefs based on the text they vomit up.
If you are lucky, the statements and beliefs you take from your chatbot may even be true - they are true at least some of the time, maybe even slightly more than 50% of the time depending on which self-serving metric is used. Not nearly enough of the time for my comfort, but others seem to not care as much about the built-in error / randomness rate.
What you can never have from a chatbot is the "justified" part - a "GenAI" chatbot is randomly mixing up a large (but still very limited) set of inputs of dubious provenance into a structure that looks enough like the shape of language (or art or whatever output type you've chosen) to fool enough human to make money for the owner.
This process by definition removes any connection to the (stolen) sources, and thus the justifications and evidences, for whether we can consider the "knowledge" generated as "true", and thus whether it makes sense to have a belief.
This short video is a good intro to this philosophy 101 concept that the whole tech industry seems to be obtusely 🙊🙉🙈 pretending doesn't matter: https://www.youtube.com/watch?v=kXhJ3hHK9hQ
We need an equivalent of "this is not financial advice" for design: "this is not based on research."
I've seen countless well-meaning teams say "we will do it this way and then come back to this decision" - and they almost never do. That's because unless you carefully document decision provenance, coming back to the right decisions is impossible.