A Big Visible Two-Day Agenda is an excellent visual reference for a training, workshop, or conference.
Each half day is based on a simple 3 × 3 grid with a title. Key:
- Pink—game or exercise.
3″ × 5″ Post-it notes cut into 3″ × 1¼″ strips allow for a landscape text that fits nicely in one of the nine cells. It is easy to move the contents around.
The day before, you can prepare the whole to save time setting it up at the site:
- use sheets of A4 paper with the grid and small Post-it strips;
- prepare four flip charts in landscape orientation with the grid structure—one flip chart accommodates morning and afternoon, each with a 3 × 6 grid;
- prepare the full 3″ × 5″ Post-it notes; you can even already stick them on the flip chart; they might curl up a bit, though.
At the site, stick the four flip charts to the wall, and the Post-it notes to the flip charts.
Kudos to Olav Maassen for inviting Jeff ‘User Story Mapping’ Patton over to Xebia last Thursday.
Jeff mentioned a couple of resources:
Everyone is creative, by nature. Just unsuppress it by following Albert Bandura’s ‘Guided Mastery’.
Picture tweeted by David J. Anderson made me look it up. I like it.
- There are no best practices, only practices that fit best.
- To optimize the whole you must sub-optimize the parts.
- Bad metrics are worse than no metrics.
- Relationships precede process.
- Relationships outlive transactions.
- Don’t confuse documentation with reality.
- Before you can be strategic you have to be competent.
- Big solutions that work start as small solutions that work.
- Customers are external. Internal customers aren’t.
- Don’t run IT as a business, run it in a business like way.
- There are no IT projects.
- Digest with intestines, think with brain.
- Every employee is irreplaceable.
Keep the Joint Running—A Manifesto for 21st Century Information Technology
- 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 team charter:
- Team—A group of people or animals linked in a 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? don’t just do something, stand there!
Life is a serious game. life is a broccoli.
Fused Agile Management » David J. Anderson » Lean Risk Management—Options, Liquidity & Hedging Risk using Kanban Systems (ppt) and LKCE12 » David J. Anderson » Liquidity in Flow (video) on a single big visible chart (A2-sized).
- 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.
- Create success profile on an index card for every option you want to execute soon.
- Put it into corresponding swim lane, honoring any work in progress limit.
The 7th Key Principle of Lean Software Development is Optimize the whole.
The burning question is, how to boost collective evolutionary power from a participative, co-creative agile organizational point of view? Large Scale Intervention (LSI) provides principles, patterns and practices to just this? LSI is also known as Whole Systems Change.
Hope you enjoy a short slide deck on Agile Organization (PDF, 1.3 MB).
“Ontwikkelen moet je meemaken.”
Highlights from Past the Tipping Point: The Persistence of Firefighting in Product Development by Nelson Repenning, Paulo Gonçalves, and Laura Black.
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.
- 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
- 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.
Zachtwaarderij—onderneming die ambachtelijk zachtwaar (software) vervaardigt.
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.
Joseph Perline’s 3 Rules:
- We don’t make mistakes, we learn.
- Whoever carries the risk, decides.
- If it’s not fun, you’re doing something wrong.