Scrum Gathering Las Vegas 2013

I used to attend Agile and quality related conferences years ago and have saved notes from many of them. While some topics have become overtaken by events since then, there still seem to be some useful ideas that I’d like to pass along.

[I took lots of notes, but what follows includes some context/thoughts of my own in remembering what I wrote and why.]

Jeff Sutherland Keynote — The Future of Work

Jeff asked a lot of questions of us and did not necessarily offer answers though he implied what his own experience had taught him.

His first question was we a team could deliver at the point where 20% of the features were done, i.e., the top ones most expected to be of value and used? By this I believe he was asking about the ability of both the team and customer to deploy by that point in project work rather than wait longer.

Benefit

Detriment

Detriment

Benefit

Rat Race

Happiness

Nihilism

Hedonism

He then asked us to consider what the real cost of projects was and where it comes from. He said we should consider the cost of deciding to do the project at all. [From work done years before I encountered Agile ideas, I also believe one should consider the cost of features developed that are hardly ever used.]

He put up this chart where the vertical represents the business and the horizontal represents the people doing the work Each quadrant represents the position/result of how these are combined for each group’s benefit and detriment.

Sutherland offered several quick ideas:

· Daily meetings are about how to make things go faster (i.e., more productively).

· Only look at unbelievable and unexplainable results.

· Product Owners should increase revenue per point — value for effort measure.

· Can’t bring in more points than average of last 3 Sprints (that were Done).

· Interruptions happen — be on alert for the unexpected — how much effort does that require? If no consequence to interruptions, then interruptions never stop — abort and replan.

· Put top Kaizen actions in the Backlog with acceptance tests.

· While velocity is not comparable across teams, increase in velocity is.

· Management needs to take an active “How can we help?” position.

Then he asked what impedes us from getting to Done each Sprint? [I find this one of the most common, if not the most common, challenges for Scrum teams.]

He also asked us how many critical projects are we doing at once?

He then mentioned a few companies and things he observed they are doing/have done:

· Valve as an example of no managers and no performance reviews.

· MicroSoft remodeling their buildings to support Scrum.

· SAP (800–1000 teams!) hold management responsible to assure teams have a good Backlog ready to work on each Sprint.

Dan Rawsthorne — Using Story Points for Project Management

Rawsthorne started by defining the difference between a plan (people believe they understand how this can be done) and a goal (some % of people can’t say this).

While the Product Owner is responsible for making priorities clear, the business owns the scope.

The assumption should be that the Product Owner is “on” the team, i.e., closely connected to it and aware of what is happening on the team. [The Scrum Guide specifically says the Product Owner is a member of the Scrum Team.]

He compared ideal to actual effort:

· Ideal Effort = no disasters, no magic, Done met, no change, “if everything were as it should be”

· Actual Effort = Ideal Effort + Environmental Drag + Slack

o Environmental Drag = team skills/ability, technology, organizational “noise,” etc.

o Once Drag stabilizes you know what it costs you.

o Story Points are what it should cost.

Regarding addressing dependencies, he stated we should do what we have control over, then, later, we do another story to incorporate the other work. [That is, split such work into achievable parts and those that must wait on others so some progress can me made/shown without delaying everything due to some partial element(s) missing.]

John Miller — Coach the hand you are dealt

Miller first mentioned the International Coaching Federation (http://www.coachfederation.org/) which is “the world’s largest organization of professionally trained coaches, and the leading voice for the global coaching community”. As such it addresses all domains of coaching and is not specially Agile focused.

Miller quoted Lyssa Adkins’ advice that “rather than fixing or changing anything, reveal the system to itself.” One idea for doing this, Mille said, is to find people’s resonance with Agile and plan from possibility rather than circumstances.

Miller claimed that Scrum is a “coaching structure” because it reminds us what we committed to do and helps reveal the system to itself.

He also said that a coach is an information radiator — do not hold back information.

Angel Medinilla — Agile Kaizen, Improvement Beyond Retros

Medinilla [who I met at the Barcelona gathering] started by addressing management by walking around [which the Lean folks call “going to the Gemba” or asking management to get out of their offices and go to where the work is happening] to ask people “How can I help you?”

He then spoke a bit about culture saying, that it gets transferred — good or bad — through shared values which can be represented by artifacts (& behaviors), assumptions, and stories. The latter explain “The way we do things around here.” or “The way things have happened around here.” He noted that spoken (supposed) values are assumptions compared to how things really happen.

All business models are assumptions (until tested by real sales). Long delivery cycles mean long delays in testing assumptions. [This parallels the lack of learning when there are long cycles between developing stories and verifying that they are “Done,” including satisfying the customer.]

He suggested an approach to the Daily Meeting where you tell the “Sprint Story” before launching into the individual, detailed 3 questions.

Medinilla also mentioned Root Cause Analysis and identified some techniques such as the 5 whys, fishbone diagrams, and affinity diagrams to explore issues, noting that the first ideas are often symptoms, not root causes. Then regarding making improvements, he suggested incremental (daily) follow-ups to see how they are going like any other work for the team. [I’ve always encouraged team facilitators to make this a part of their contribution to the Daily Meeting by asking how such improvement efforts are going if that isn’t clear due to having specific stories for them.]

Rod Claar — Effective Scrum and High Quality Code

Claar asked a lot of questions to prompt our thinking:

· Is there a budget for quality?

· How much quality is enough?

· How do you know how much quality you have?

· How do you know you have “enough” quality?

· How do you express non-functional quality characteristics?

· How easily can you add more value? (software viscosity)

· What kinds of changes can reasonably be expected?

· How easy is it to test? Cohesion, coupling, binding, complexity

· Quality = how fast can we deliver new value over time?

If the end point is predefined, feedback may seem of limited value other than feedback about meeting the end point.

Make technical debt visible and be clear that it is not defects. And can new work be done and the results be “cleaner,” so you do not need refactoring.

YAGNI (you ain’t gonna’ need it) — just by designing things you give them a “life of their own, i.e., justification for their existence apart from need.

Bill Joiner Keynote — Leadership Agility

Joiner said that agility id the ability to achieve sustained success in the face of accelerating change and interdependence (customers & partners).

The role of management as agile leaders is to:

· Understand and uphold Values & Principles

· Set the context

· Develop a culture of openness and trust

· Empower and protect Agile teams

· Use Agile practices

· Not be a traditional manager

Joiner said that the primary obstacle to organizational agility is organizational culture ( based on an Economist study of executives).

Stage Development Psychology identified 3 levels of management and the percent of management behavior for each: 55% expert, 35% achiever, 10% catalyst.

The characteristics of each are:

Expert level is characterized by

· Authority and expertise to get people to follow

· Tactical focus

· One on one supervision rather than direct reports as a system

· Low tolerance for conflict (difference of opinion) [or feedback]

Achiever level is characterized by

· Motivating others through larger objectives

· Strategic outcomes — stakeholder buy-in

· Orchestrating direct reports as a team

· Moderate tolerance for conflict

Catalyst level is characterized by

· Empowering and developing others

· Aim through the target (have an organization that can sense and respond to what comes)

· Participative, empowered team

· Greater tolerance for conflict (straight talk, easy information flow)

Mohamed Amr — Process Increments

The one note I had about this talk was a question he asked:

“What learnings have been gained in doing the improvement effort (and have you captured this learning in any notes, etc. from which others might learn)?” That is, do we consciously do this?

Alistair Cockburn Keynote

Alistair encouraged us to “learn (bad news) early” pointing out that Waterfall (Big Bang delivery) is a late learning strategy — delivers knowledge late because it delivers value late.

He said we should “pay to learn through continuous integration” which starts early in development.

He asked us to consider four project perspective questions:

· Business — are we building the right thing?

· Social — can we build it?

· Technical — will the solution work?

· Cost/Schedule — what will it cost?

He closed by offering this cartoon with one end of a small boat sinking while a person at the other end, still above water, says “Not my problem, the hole is at your end of the boat.”