Replies: 3 comments 8 replies
-
|
@KysukeX thanks for your time providing the feedback. I like your idea of a specific section of 'Output vs Outcome' in the context of 'Output Done' and 'Outcome Done' could be helpful. |
Beta Was this translation helpful? Give feedback.
-
|
Thank you for bringing this up, @KysukeX |
Beta Was this translation helpful? Give feedback.
-
|
We would like to have a chat with you. We are thinking about having a Zoom call. Nothing beats having a live in person conversation. |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
-
After reviewing the content of this expansion (I really appreciate the effort put into this document), I've identified a few areas where further refinement could enhance clarity and reinforce core agile principles.
My suggestions aim to strengthen the guidance and prevent potential misunderstandings.
"Stakeholder (including but not limited to user/customer)",
While seemingly inclusive, it inadvertently risks diluting the essential focus on customer-centricity. In my experience, this broad framing can sometimes be misinterpreted as an invitation to prioritize other interests over direct customer feedback, leading to a "Highest Paid Person's Opinion" (HiPPO) effect.
While it's crucial to value all stakeholders and weigh their contributions appropriately, the customer/user remains paramount in product development. Proposed alternative phrasing: "Stakeholders (Customers/Users and anyone with a vested interest)."
This phrasing explicitly positions customers and users at the forefront while still acknowledging the importance of other vested interests, thereby maintaining a healthy balance without diminishing the customer's voice.
"Definition of Output Done & Definition of Outcome Done",
Introduces conceptual overlap and conflicting terminology, especially given the widespread adoption of "Definition of Done" (DoD).
An outcome is, by its very nature, an event that has already occurred or is actively happening, making the concept of an "Outcome Done" somewhat redundant.
Furthermore, emphasizing "Output Done" might inadvertently reinforce a "feature factory" mindset, where the focus remains on delivering features rather than achieving valuable results.
I believe that a dedicated section on "Output vs. Outcome" explaining the fundamental difference between Output (what we produce) and Outcome (the value or impact achieved) would clarify the distinction.
This educational component is vital for guiding teams towards value delivery rather than mere production.
Retain DoD : Continue using the established "Definition of Done" to describe the criteria for a completed work or output.
Reduce DoOD to DoO : A dedicated "Definition of Outcome" section would be highly beneficial. This would focus on defining what successful outcomes look like, emphasizing the desired impact and value.
Rethinking "Avoiding Demotivation"
The suggestion that leadership's duty includes "Avoiding demotivation" can be misleading.
True motivation in a professional context, especially within agile environments, is inherently intrinsic.
Focusing on "avoiding demotivation" risks implying that motivation is something to be managed externally.
Based on principles championed by researchers like Daniel Pink (Drive!), intrinsic motivators such as Purpose, Mastery, and Autonomy are fundamental for a healthy and productive work environment.
I recommend a section dedicated to Fostering Intrinsic Motivation. This would guide leadership on creating an environment that naturally cultivates engagement and high performance by focusing intrinsic values. This shift in perspective would align more closely with modern agile leadership principles and empower individuals to be self-driven.
I hope these comments provide valuable insights for refining the expansion pack and further empowering agile practitioners.
Best Regards,
Lamine Haouam
Beta Was this translation helpful? Give feedback.
All reactions