Life is a broccoli

Everything in life is a broccoli. Take a broccoli, and snap off a piece. The piece of broccoli is a broccoli in itself. Take that piece, and snap off yet another piece. Again, that piece is a broccoli in itself.

In short, broccoli is self-similar. It is fractal. It is a holacracy.

You will find broccolis all over the place.

A portfolio is comprised of products. A product or a system consists of essential parts. Each part consists of subparts, and so on.

An organization consists of units, divisions, departments, groups, teams, squads, individuals. All broccolis within broccolis.

An initiative consists of programs, programs, in turn, consist of projects, projects have milestones, milestones take a couple of sprints to complete, sprints take one or two weeks.

Values, values, values

Actual values are the behavior and skills that are valued within the ‘fellowship’. The fellowship being the group of people pursuing some—noble—goal.

The Scrum Guide from 2016 pulls the Scrum values back into its center. Ken Schwaber and Jeff Sutherland call it the heart of Scrum.

The agile and lean frameworks, methods, and practices—like XP, Scrum and the Kanban Method—each have their own set of values. The total set counts 17(!) unique values:

  1. simplicity;
  2. communication;
  3. feedback;
  4. focus;
  5. courage (2×)
  6. openness;
  7. commitment;
  8. respect (3×);
  9. agreement;
  10. balance;
  11. collaboration;
  12. customer focus;
  13. flow;
  14. leadership;
  15. respect;
  16. transparency; and
  17. understanding.

The long list of values reminds me of a joke that emerged during the UNIX standardization battles:

The nice thing about standards is that there are so many to choose from.

How can you live all those values? Which one do you pick? Which value do you focus on?

Perhaps picking your 3–5 top values, share them with your fellowship, and then dot vote the result to distill 3–5 fellowship values: behavior and skills that are valued by most or all.

Perhaps gauging them on how they contribute to the Fantastic Five may help:

  1. Abundance—The byproducts of already having abundance rather than how much.
  2. Livelihood—The byproducts of doing, rather than what you will do.
  3. Health—All that your fantastic health makes possible.
  4. Relationships—The results of having a new or an improved relationship rather than who.
  5. Appearance—The effects of being pleased with yourself rather than diets, time lines, and body weight.

Anyway, what do you think?

Just Say No

Just say no to make your yes mean something.

Spending your limited time on the things that really matter creates a more intentional and solid yes, builds trust and coherence.

If you believe that you must keep your promises, overdeliver and treat every commitment as though it’s an opportunity for a transformation, then the only way you can do this is to turn down most opportunities.

No I can’t meet with you, no I can’t sell it to you at this price, no I can’t do this job justice, no I can’t come to your party, no I can’t help you. I’m sorry, but no, I can’t. Not if I want to do the very things that people value my work for.

Yes is the future no—in other words, you are lying, often to your dear ones.

Say yes too often, and your body will automatically tell you no in no time.

No is the foundation that we can build our yes on.

Here are nine practices to say a strategic no in order to create space in your life for a more intentional yes.

  1. Know your no. Identify what’s important to you and acknowledge what’s not.
  2. Be appreciative.
  3. Say no to the request, not the person.
  4. Explain why.
  5. Be as resolute as they are pushy.
  6. Practice.
  7. Establish a pre-emptive no.
  8. Be prepared to miss out.
  9. Gather your courage.

Say no to all issues that do not align with values, goals and norms—that fall outside the tolerance of your self or your organization.

  • To say “Yes” is about quantity.
  • To say “No” is about quality.
  • To say “No” gives certainty, dependability, safety and sureness.

Approach (similar to process leading to en|consent):

  • Actively listen to the other’s question.
  • Say “No’”.
  • Show understanding for any response or reaction.
  • Provide a focused motivation of your “No”.
  • Find a solution that you both can live with.
  • Track progress.

Therefore:

Listen to the other’s request and provide an understanding “No”, along with its motivation. Find a solution that you both can live with and track progress.

Variations:

  • Say “Yes, as soon as… I’ve completed all these things first‘.”

Clear goal, simple rules

Dee-Hock-Clear-Goal-Simple-Rules

:Simple, clear purpose and principles give rise to complex and intelligent behavior.
:Complex rules and regulations give rise to simple and stupid behavior.

::—Dee Hock, CEO Emeritus VISA International

From en|team charter:
*”’Team”’—A group of people or animals linked in a en|unity of purpose.
*”’Self-organization”’—The tendency of an open system to generate new structures and patterns based on its own internal dynamics. Organization design emerges from the interactions of the agents in the system; it is not imposed from above or outside. Facilitating Organization Change: Lessons from Complexity Science

Three factors influence the patterns that emerge:
#The container sets the bounds for the self-organizing system. It defines the “self” that organizes.
#Significant differences determine the primary patterns that emerges (power, level of expertise, gender, …).
#Transforming exchanges form the connections between system agents.

Just as a person needs time and space to incubate thoughts before a new Idea can emerge, a system needs a bounded space for the emergence of new patterns. Patterns imply structure, organization. Self-organizations gives you order for free. Effortless organization? en|don’t just do something, stand there!

Life is a [http://www.gogamestorm.com/?p=88 serious game]. en|life is a broccoli.

Success profile

success-profile

Fused [http://agilemanagement.net/index.php/Blog/thoughts_on_the_value_of_liquidity_as_metric/ Agile Management » David J. Anderson » Lean Risk Management—Options, Liquidity & Hedging Risk using Kanban Systems] (ppt) and [http://vimeo.com/52371405 LKCE12 » David J. Anderson » Liquidity in Flow] (video) on a single en|big visible chart (A2-sized).

Changes:
*David uses ‘risk profiles’ to find out what to pull next. If success + risk = 1 you can invert a ‘risk profile’ into a ‘”’success profile”’’ if you will.
*Chart uses a ”’polar chart”’ rather than a radar chart.

Usage:
#Create success profile on an index card for every option you want to execute soon.
#Put it into corresponding swim lane, honoring any en|work in progress limit.

Firefight no more

Highlights from ”Past the Tipping Point: The Persistence of Firefighting in Product Development” by Nelson Repenning, Paulo Gonçalves, and Laura Black.

Putting out fires is not improvement. Finding a point out of control, finding the special cause and removing it, is only putting the process back to where it was in the first place. It is not improvement of the process.

—W Edwards Deming

Unplanned allocation of resources to fix problems can switch the entire company to epidemical firefighting and organizational pathology. Even a temporary increase in workload can initiate the firefighting dynamic and cause a permanent decline in system performance and health.

Firefighting:
*snaps into place when pushed beyond the tipping point or threshold
*drives out disciplined and more structured (development) processes, becoming the (development) process instead
*can significantly degrade an organization’s ability to create high quality products in a stable, predictable, sustainable and resilient way
*is a self-reinforcing syndrome with a tipping point, and is, therefore, fragile
*is hard to recognize (its symptoms), causing corrective action to be taken too late
*comes very naturally

Likely goals:
*be an innovative, competitive, stable, predictable, sustainable and resilient organization;
*stay clear of the tipping point when you are on its productive and innovative side;
*get close to the tipping point a.s.a.p. when you are in firefighting mode, and then nimbly nudge it over;

To avoid firefighting to become a company-wide disease:
*Discourage, ignore or penalize heroism and heroic behavior.
*Use a boom buffer with a clear policy and managerial impact when excepted.
*Keep current tools and technology, avoiding time needed to invest in learning them that (temporary) lowers productivity
*Have a laser focus on top quality for product, process and people as lower quality will push the organization into the death spiral of declining competitiveness, reduce revenue and future innovation.
*Do root cause analysis and resolution of the top problems. Just postponing problematic projects does not prevent the spreading of firefighting, it just pushes them downstream to bite you next year, and probably harder.
*Perform aggregate resource planning to prevent fires.
*Reduce the number of parallel products or projects—so bring focus.
*Avoid full utilization of human assets. Cherish slack resources as a buffer against uncertainties (also see boom buffer).
*Aggressively cancel failing projects early.
*Revisit the product plan instead of trying to catch up.
*Do not rent or steal people from or lend people to other parts of the organization as it might start a fire.
*Reduce workload effectively to stabilize the system, e.g. by skipping a model year altogether.
*Do fewer projects and cancel more.
*Put a strict (Work In Progress or WIP) limit on many or all parts of the value stream, and use those to maximize flow.
*Undercommit and overperform.
*Uphold a strict policy of only accepting finished, done work. Mercilessly reject any unfinished work and loose ends.
*Perform thorough up-front work. Make policies and admission criteria to pull something into the next step crystal clear. This will:
**increase the likelihood that the item will get done in time;
**reduce or avoid the need to cancel it later;
**make owners face strong incentives to invest in the early phase activities and develop clever ways to demonstrate the efficacy of a proposed product far in advance of its detailed design.

All this resonates with agile, scrum, lean, and kanban.

Boscard

The BOSCARD can be seen as an acronym for the A3 and be used as a strategic planning tool used to provide the terms-of-reference for new projects:
*”’Background”’—Provide background information that includes the reasons for creating the project and mentions the key stakeholders who will benefit from the project result.
*”’Objectives”’—Describe the project goals and link each of them with related, SMART project objectives.
*”’Scope”’—Provide a high-level description of the features and functions that characterise the product, service, or result the project is meant to deliver. Be explicit about what is in and what is out of scope.
*”’Constraints”’—Identify the specific constraints or restrictions that limit or place conditions on the project, especially those associated with project scope.
*”’Assumptions”’—Specify all factors that are, for planning purposes, considered to be true. During the planning process these assumptions will be validated.
*”’Risks”’—Outline the risks identified at the start of the project. Include a quick assessment of the significance of each risk and how to address them.
*”’Deliverables ”’—Define the key deliverables the project is required to produce in order to achieve the stated objectives.

Include the initiative’s name, its strategic fit, date raised, sponsor, and lead.

Make all stakeholders understand the BOSCARD and make sure you have everyone’s consent before investing even the first euro on this initiative. Woithout everyone’s consent, some expectations will not be met.

Consider replacing your PIDs with BOSCARDs. Decision-makers, scarce on time, will love it.

The BOSCARD is thought to have originated with consulting company Cap Gemini in the 1980s.