- Culture is more about “The ideas, customs, and social behavior of a particular people or society.”
- When an individual behaves in a particular way, we associate that to be his nature, but when a team or an organization responds, we relate to its culture.
- Culture within the same organization varies across various geographies e.g., UK Culture, or the US Culture, or the Indian Culture, etc.
- When we address the culture exhibited by all the teams in an organization it is referred to as the organization culture.
“Culture of Fear” - fear of getting penalized for a decision going wrong, fear of failure to meet the commitments, fear of poor quality deliverable, fear to be completely honest and transparent, fear to challenge the status-quo, fear of lack of trust and respect among people, etc.
To remove “Culture of Fear” and contribute successful Agile culture adoption:
- Understanding it is the key.
- Management, executives, and team members should support and embrace this change.
- Invest in a few prominent agility attributes like the healthy team dynamics of self-organization teams, continuous improvement, frequent delivery, effective communication, adapting to the changing environment, etc.
- Examine its existing practices with a critical eye, try new way of doing things, create new opportunities, coupled with commitment and nurturing at all levels within an organization.
Organizations with the Agile adoption culture change journey exhibit some of these characters:
- Team members demonstrate values like Trust, Respect, Courage, Openness, Confidence, Synergy, Unity, Affiliation, and Commitment.
- Creativity, Collaboration, Emergence, Rhythm, Empiricism, and Discovery are encouraged organization-wide.
- Embracing Transparency, Inspection, and Adaptation as part of everyday routine.
→ Embedding cultural shift involves a lot of patience, a full top-down support, constant learning, and a bottom-up intelligence.
- Avoid describing a Sprint Backlog as a “commitment” → Use a “plan” or “forecast” of work for meeting a Sprint Goal and remember that team members ought to commit to goals, not to forecasts.
- Avoid language which suggests Story Points are “delivered”, or in some way constitute value or otherwise proxy for value → Story pointing is to help a team forecast how much work it believes it can take on. Value is only to be found in the delivered increment.
- Avoid talking about an “ideal velocity” when making forecasts → Talk about the ideal value which can be released in current and future Sprints. The work done does not consist of story point accountants but innovation accounting.
- Avoid talking about “Sprint Goals” when those supposed goals have not yet been planned and agreed by the team → If they are tentative Sprint Goals, call them that. During refinement, discuss how well they might align to features and Minimum Viable Products.
- Avoid describing stages of work as “Sprints” unless they are time-boxed and produce an increment of functionality → “Special” sprints like “sprint zero”, “integration sprint”, “testing sprint” and so on are coded terms for stages or phases. If stages or phases are to be used, call them so honestly, and avoid devaluing agile terms of reference.
- Avoid describing a Sprint Review as a “Show and Tell” or “Demo” → A demonstration of work might very well form part of a Sprint Review. However, consider the work which has been done and which remains to be done, and to inspect and adapt the Product Backlog.
- Avoid talking about a “Kanban” unless there is evidence of a closed economy of work → If there is merely evidence of a “to-do” list, call it that.
- Avoid describing Acceptance Criteria as the “Definition of Done” → They may represent a certain level of “Done” for certain Product Backlog items, but the Definition of Done, as an assertion of release quality, properly refers to the entire increment.
- Avoid referring to a collection of people as a “team” unless there is evidence of their collaboration and teamwork → If those people are working in silos which are largely independent of each other, then there may instead be evidence of a “workgroup” engaged in craft production.
- Avoid referring to an agile initiative in terms of its supporting tools → Achieving agile practice is not the same thing as “having Jira” or “using TFS” or indeed any other technology.
- Avoid talking about "DevOps" as though it were distinct from agile practice and cultural change → If you are referring to technical practices such as automation or continuous integration and deployment, use those terms instead.
- Avoid talking about “technical debt” when there is no plan to pay the accrued deficit back, or the liability incurred thus far is unmanaged and unknown → If they are in truth unquantified losses, call them that.
- Avoid talking about a “Release Plan” if certain Sprints are not planned to result in a release at all. → What you actually have is a plan for not releasing. In Scrum, each Sprint must yield an increment of value however small it may be. The decision to release or not to release ought to be made on a Just in Time basis. A true Release Plan should outline what is likely to be delivered, to whom and when...not if a release will happen.
- Avoid talking about “bugs” or “defects” as if they are separate from other work which remains to be done → They must still be accounted for as work remaining, and planned and budgeted for. The urgency of the repair and the speed with which it is expedited does not obviate the need for this quality of transparency.
- Avoid talking about “fixed scope” when a Product Backlog is subject to ongoing refinement, and distinct options might yet emerge → Instead, talk about each Sprint as the opportunity to deliver something of value from which useful things can be learned.
- Avoid language such as “push to test” which suggests that anything other than a pull-driven flow of work is expected → Agile and lean practice is founded on pull, including the timely and efficient handling of work in response to clear demand signals.
- Avoid referring to “distributed” teams → A team which is not co-located is a dislocated team. Call it that, and be transparent and open about the challenges and inefficiencies concerning teamwork which are likely to arise from such a model.
- Avoid using the expression “being agile” as a euphemism for “being reactive” or doing work “faster and cheaper” → An agile team exhibits full control over its work in progress and the work it chooses to take on. Any economies will be found in the team's ability to inspect and adapt, to evaluate outcomes empirically, and to reduce waste.
- Avoid talking about “agile scaling” → the de-scaling of enterprise functions will be needed before even one team can achieve an agile way of working.
- Avoid dehumanizing employees as “resources” or “work packages” → If you contextualize people as inanimate objects, you will get less than the person has to offer. Employees are human beings with creative and innovative potential. Value them accordingly.
- Better teams not make more mistakes, but are open to discuss about them and get to the bottom of it and resolve the problems.
Tips:
- Frame the work as a learning problem, not execution problem.
- Recognize that there are enormous uncertainty ahead and interdependence.
- Acknowledge your own fallibility.
- Model curiosity by asking a lot of questions.
Psychological safety vs Motivation & Accountability
-
Is the belief that no one will be punished or humiliated for speaking up with ideas, questions, concerns or mistakes.
-
Is a group-level construct, meaning that is something experienced by the entire group.
-
Each individual perceives that the group will give them the benefit of the doubt when they take a risk.
-
Basically making a 1-1 economic risk assessment trying to figure out how a certain action will impact my position in a group.
-
Trust is a “conscious calculation of advantages, a calculation that in turn is based on an explicit and internally consistent value system”.
-
Trust focuses on others potential actions and trustworthiness to protect ourselves.
When working with teams, one of the first items on the agenda was building trust, but it is the wrong thing to focus on and more difficult to influence on a team level.
→ The presence or absence of psychological safety tends to be experienced at the group level of analysis, unlike trust, which pertains primarily to a dyadic relationship – whether between individuals or collectives such as firms.
Three things to enable psychological safety:
- Frame the work as a learning problem, as opposed to an execution problem - the Cynefin framework
- Acknowledge you own fallibility.
- Model curiosity by asking a lot of questions. - the Scrum framework
Evidence-Based Management Guide - 2020 (PDF English version):
Key elements:
- A Strategic Goal → is something important that the organization would like to achieve.
- Immediate Tactical Goals → critical near-term objectives toward which a team or group of teams will work help toward Intermediate Goals.
- A Starting State → is where the organization is relative to the Strategic Goal when it starts its journey.
- A Current State → is where the organization is relative to the Strategic Goal at the present time.
→ To progress toward the Strategic Goal, organizations run experiments which involve forming hypotheses that are intended to advance the organization toward their current Intermediate Goal. Use the evidence obtained to evaluate their goals and determine the next steps to advance toward these goals:
- Define specific measures that will indicate that the goal is achieved.
- Goals, measures, and experiments should be made transparent.
For example:
- The Strategic Goal is to eradicate the effects of the disease, as measured by the number of people who fall ill and suffer significant illness.
- Measurement: focused on the effects of the disease, and not on the means for achieving the desired impact e.g., the goal is not to vaccinate a certain percentage of the population against the disease; that may be an activity necessary to achieving the Strategic Goal, but it is not the Strategic Goal.
- An Intermediate Goal is the successful completion of a trial of a vaccine against the disease.
- Immediate tactical goals: isolating symptoms, evaluating a therapy, sequencing the DNA of a virus or bacterium, etc.
→ The Strategic Goal is usually focused on achieving Unrealized Value, which is the satisfaction gap between a beneficiary's desired outcome and their current experience.
Measures fall into three categories:
- Activities → things people in the organization do e.g., perform work, go to meetings, have discussions, write code, create reports, attend conferences, etc.
- Outputs → things the organization produces do e.g., product releases, features, reports, defect reports, product reviews, etc.
- Outcomes → things a customer or user of a product experiences. do e.g., being able to travel to a destination faster, or being able to earn or save more money than before, a service users previously relied upon is no longer available (negative), etc.
→ Delivering valuable outcomes to customers is essential if organizations are to reach their goals e.g., working more hours (activities) and delivering more features (outputs) does not necessarily lead to improved customer experiences (outcomes).
-
Current Value (CV) → value that the product delivers today.
- How happy are users and customers today? Is their happiness improving or declining?
- How happy are your employees today? Is their happiness improving or declining?
- How happy are your investors and other stakeholders today? Is their happiness improving or declining?
-
Unrealized Value (UV) → potential future value that could be realized if the organization met the needs of all potential customers or users.
- Can any additional value be created by our organization in this market or other markets?
- Is it worth the effort and risk to pursue these untapped opportunities?
- Should further investments be made to capture additional Unrealized Value?
-
Time-to-Market (T2M) → organization's ability to quickly deliver new capabilities, services, or products.
- How fast can the organization learn from new experiments and information?
- How fast can you adapt based on the information?
- How fast can you test new ideas with customers?
-
Ability to Innovate (A2I) → effectiveness of an organization to deliver new capabilities that might better meet customer needs.
- What prevents the organization from delivering new value?
- What prevents customers or users from benefiting from that innovation?
- Understand your Current State.
- Understand where you need to improve such as effectiveness (A2I), and responsiveness (T2M).
The Experiment Loop - helps organizations move from their Current State toward their Next Target Goal, and ultimately their Strategic Goal, by taking small, measured steps, called experiments, using explicit hypotheses:
- Forming a hypothesis for improvement.
- Running your experiments.
- Inspecting your results.
- Adapting your goals or your approach based on what you learned.
-
Features are “distinguishing characteristics of a product”.
-
Requirement is something that someone thinks would be desirable in a product. → A feature description is one kind of requirement. The entire feature or requirement need not actually be built to determine whether it is valuable. It may be sufficient for a team to simply build enough of it to validate critical assumptions that would prove or disprove its value.
-
A hypothesis is a proposed explanation for some observation that has not yet been proven (or disproven).
-
An experiment is a test that is designed to prove or reject some hypothesis. → Beliefs in what is valuable are merely assumptions until they are validated by customers. Explicitly forming hypotheses, measuring results, and inspecting and adapting goals based on those results are implicit parts of an agile approach.