Flight Levels is a helpful thinking model for organizations looking to realize outcomes through a respectful, lightweight, evolutionary approach. Since it emphasizes incrementalism, transparency and just-enough-structure, I think of it as “Invisalign for your organization.”
The Stay Interview
Understanding first-hand what motivates people
Do you know what motivates people? Why would they choose to stay or leave? If you care about the people you support and want them to stay (and moreover, thrive), it’s pretty easy to find out how to help: Conduct a Stay Interview.
If you know what an exit interview is, you know how to do a stay interview. Simply move the timing up. It’s like the pattern of moving from a project post-mortem to a regular retrospective; by bringing the learning forward, you have a chance to do something about it.
My own lessons from stay interviews
I’m learning a few things by conducting stay interviews. A few lessons so far:
- You need to do something about what you learn. Listening and understanding what people need is only the first step. And you only have a limited time before you lose credibility and trust.
- Motivations differ for everyone. You may find patterns, but the priorities for different people are different. And what is important for one person now – like compensation – may not be as important to the same person later. One person desires words of appreciation and quality time, another growth opportunities, another is concerned about comp becoming an issue.
- Quarterly is a good cadence. Even if you’re a fairly involved manager, organizational and economic dynamics change frequently. How do you know what works best for your people? Ask them.
Why aren’t stay interviews more common?
From my own experience observing various organizational cultures, including my own experiences in a managerial role, I surmise a few reasons:
- You lose control: When you open yourself with a question like “What will make you stay?” it totally upends the power dynamic in the typical managerial relationship. It’s a very vulnerable position to be in, and it’s uncomfortable for people who are accustomed to people “reporting to them” because you are now reporting to them.
- You have to act: When you ask someone what you can do to encourage them to stay, and the person directly tells you, the clock starts for how long you have to maintain your credibility and trust. Whether it’s fighting for a raise or changing the way you do things, it means you actually have to put the “servant” in servant leader. If you fancy yourself a modern manager, you need to put your money where your mouth is and prioritize what you’ve heard.
- You fear you won’t be able to deliver: It’s true that you likely won’t be able to deliver everything, but now you have an option (as opposed to finding out too late to even try); moreover, you can have an honest conversation about expectations.
- You aren’t incentivized to care: This sounds cynical, but people do what works for them in the system in which they work. The sad reality is that many managers aren’t held accountable for people outcomes (e.g., retention, engagement) and have other priorities. They might give lip service to “taking care of people” (and some may even want to), but when push comes to shove, it gets crowded out.
So why do I love the stay interview?
- I can demonstrate to the people that I support that I appreciate them.
- I can tailor my work to support them without having to guess.
- I can get ahead of things that may take time (like compensation).
- I can explicitly tell people that I value them and want them to stay!
Sources and Resources:
- Vegafactor motivators
- Herzberg’s Motivation Theory
- Theory X and Theory Y
- Psychological Flow channel
- Guide to managing me (Streamside Coaching)
Stay Interview questions:
- What motivates you to stay? What de-motivates you?
- What do you like about it here?
- What do you tell other people (friends, recruiters) about why you stay here?
- How “fully utilized” do you feel? (Are you able to employ all of your talents?)
- What do you have to “go outside” of work to get?
- If you managed yourself, what would you do differently that I don’t currently do? What do you like about what I do?
- In what situations do you experience flow here? Where do you not?
- What worries you?
- How would you redesign your current role into your dream job?
- What does your “best day” look like?
This article is also available on my Substack at https://mattphilip.substack.com/.
Winter Lesson: Forecast with a Range
It’s that time of year again when many of us in the northern hemisphere look at the weather forecast in anticipation of that lovely winter precipitation to see whether we’ll have a white Christmas. And that leads me to my annual reminder about forecasting events in the future: Always forecast with a range! Anyone with a weather app is familiar with the concept:
Since the future is probabilistic and not deterministic, we should think of our work forecasts in the same way — always give a range of possibilities, each with its own probability of occurring:
Like the weather, we need to account for the various possible outcomes when communicating what might happen in the future so that our stakeholders know what to expect. And yes, I’ll be hoping for — and this year even expecting! — a white Christmas.
Thoughts on Mik Kersten’s Flow Framework
I read Mik Kersten’s helpful book Project to Product shortly after he published it, and I didn’t comment on it at the time. However, a colleague recently asked about The Flow Framework contained therein, so I am now sharing some thoughts on it.
In general, anytime someone promotes the principles of flow management and thinking — especially when he or she is well received for it — I am grateful. That’s largely the case with Kersten’s book. Insofar as it has increased awareness and even the practice of flow management, I commend it. In the interest of giving credit where it’s due, I offer just a few words of potential clarification to say simply that the flow metrics that Kersten advocates are not new but simply repackaged — skillfully and helpfully, to be sure — versions of what many people have been advocating for a while, most notably those in the kanban community.
To that end, here’s a guide to mapping the elements of The Flow Framework with those that they are based on. I don’t really find much added value in the terms that Kersten uses, and I actually find Flow Velocity rather unhelpful, since it conflates a term that’s already well-known in agile circles with something that we already had a perfectly useful word for.
| Flow Framework Metric | Description | Otherwise Known As | Description (from Essential Kanban Condensed when possible) |
| Flow Distribution | Mutually Exclusive and Comprehensively Exhaustive (MECE) allocation of flow items in a particular flow state across a measure of time. | Work-Item Type Distribution | Work-type mix/distribution (i.e., % allocation to work types) |
| Flow Velocity | Number of items done in a given time. | Throughput/Delivery Rate | Throughput: The number of work items exiting a system or sub-system per unit of time, whether completed or discarded. Delivery Rate: The number of work items emerging complete from the system per unit of time. |
| Flow Time | Time elapsed from when a flow item enters the value stream to when it is released to the customer. | Delivery Time/Time to Value/Time in Process/(System) Lead Time | The elapsed time it takes for a work item tomove from the commitment point to the delivery point. Informally,or if qualified, it may refer to the time it takes to move through adifferent part of the process. |
| Flow Load | Number of flow items with flow state as active or waiting (i.e., work in progress). | Work in Progress | The work items that have entered the system or state under consideration, but that have not yet been either completed or discarded. |
| Flow Efficiency | The proportion of time flow items are actively worked on to the total time elapsed. | Flow Efficiency | The ratio of the time spent working on an item (Touch Time) to the total Time in Process. |
Kanban Myths
[Editor’s note: I was surprised to realize that I had never written my own list of kanban myths, probably because so many other good ones exist. But here’s my take.]
Like the one about George Washington, myths about kanban persist long after evidence to the contrary. Before I list some of them, I’ll start with a few connotations of kanban, since I think that most of the myths stem from a misunderstanding of kanban. Of course, I’ll happily work to understand your own connotation of kanban. As for me, when I talk about kanban, while I respect all of the following connotations, I really consider only the first two to be valid and the latter two to be shallow or incomplete:
- (Valid) A pull system enabled by virtual kanbans which signal capacity and create flow, reduce overburdening and yield other benefits.
- (Valid) A method for defining, managing, and improving services that deliver knowledge work, such as professional services, creative endeavors, and the design of both physical and software products (a.k.a., Kanban Method).
- (Shallow or incomplete) A work board (analog or digital) that makes knowledge or intangible-goods work visible. Since the intangible-goods context derives from the physical kanban system of tangible-goods manufacturing, though, the kanbans are really virtual in these environments. The tickets on these boards are signals of demand, not capacity (which is what kanbans indicate). Therefore, any board that doesn’t have pull signals (indicated either by an explicit work-in-progress limit or a space-limited area) really shouldn’t be called a kanban board. It’s probably only a work-visualization/management board or, simply “work board.” At best, I would consider this a “proto-kanban” board.
- (Shallow or incomplete) Continuous-flow-based delivery or timebox-decoupled delivery cadences, or “Scrum without Sprints.”
All right — on to those myths of kanban, or what kanban is not:
- Kanban is advanced agile, and it’s better to start with Scrum: See Don’t mistake adoption patterns for maturity patterns.
- Kanban needs all work items/user stories need to be similarly sized: I’m not sure how this one got started, but it’s simply untrue. What about a pull system necessitates that the work be the same size? (I won’t even ask how you know that your non-repetitive work is even of a knowable size in the first place.)
- Kanban teams don’t have a sense of urgency: If by “sense of urgency” you mean that at the end of a sprint, everyone rushes to complete tickets, resulting in overburdened workers, shoddy quality and unintegrated work, then it’s true that kanban doesn’t create this sort of environment. If you mean clarity of expectations (in the form of service-level expectations and explicit policies), guidance on how to handle work based on a customer’s needs (in the form of classes of service), and a focus on flow that enables getting things done, then this claim is false.
- Kanban teams can do whatever they want and don’t require discipline: I find it to be just the opposite in reality. Teams that otherwise fancy themselves disciplined and/or “agile” often somehow can’t summon up the basic discipline to implement WIP limits to create a simple pull system. Teams who use Kanban Method are by definition continuously improving, because they “agree to pursue improvement through evolutionary change.”
- Kanban is only for x work (where x usually means ops or support): Kanban allows us to see how our work works, creates flow and reduces overburdening. If you have work for which you don’t desire those benefits, then this might be true. But why would this myth be perpetuated? Perhaps because kanban originated in repetitive-task work environments (e.g., automobile manufacturing), unimaginative people assumed that it couldn’t be applied to the modern unique product development world (another flavor of mistaking adoption for maturity patterns). The question I usually ask is “What about kanban leads you to believe it can’t be applied in your current context?”
- Kanban is useful only at the team level: Flight Levels demonstrates and the Kanban Method elaborates that wherever work is being planned and delivered, kanban is applicable. As Klaus Leopold writes, “teams are usually part of a larger organizational context, which means that the topic of WIP limits should also be understood in this larger context. If the overall company performance — the business agility — should improve … you must limit the work where you want the effect, the value and the benefits of WIP limits to be realized.”
- Kanban and Scrum are mutually exclusive: Depending on what you’re referring to, this one may be only half wrong. It’s true that kanban is born out of a different paradigm and philosophy (e.g., pull vs. push, adaptive and evolutionary rather than prescriptive). But kanban in the pull-system sense is certainly something that many Scrum teams benefit from. And taking the Kanban Method as the “start where you are” approach to improvement, if your starting point is Scrum, you can certainly design a kanban system to wrap over it and improve service delivery.
- There is no commitment in kanban: Well, technically, there’s no “commitment” in Scrum, if you want to go down that road. Again, it comes down to what you mean by “commitment” and of course what you mean by “kanban.” I suspect that people who make this claim aren’t really using kanban systems but rather define kanban by one of the two shallow connotations above. In reality, kanban allows teams to make informed forecasts and improves predictability, thereby allowing everyone in the system to make better and more-informed commitments.
See also:
Project Concerns vs. Customer Concerns
The traditional “iron triangle” of project management often crowds out our thinking about what we should really be focusing on in product delivery.
Although things like scope (count of functionalities, features), cost and time seem easiest to measure — and therefore become the things we measure and elevate — they really have little to do with product success. Rather, customer concerns like return on investment, fitness for purpose and sentiment are more important things to measure if we are interested in building great products — and they’re actually not as difficult to measure as we might have previously thought (if you’re not convinced, see Douglas Hubbard’s How to Measure Anything).
Image credit: Yoan Thirion
The Eight Stances of a Transformational Leader
Inspired by Barry Overeem’s 8 Stances of a Scrum Master, I have been talking about (and will again at the upcoming Agile Kanban Istanbul and UnlimitedAgility conferences) the eight stances of a transformational leader. I’ll be publishing my own white paper with a fuller explanation, but for now here’s a snapshot.
First, I use the term stance in the sense of “a mental or emotional position adopted with respect to something.” So it’s not a title or a role, but a way of being in a particular context. By transformational leader, I mean simply anyone working in a VUCA environment who, as Amy Edmondson says, plays a role in creating and nurturing the culture we all need to do our best work.
- Organizational Refactorer: Like refactoring in programming, refactoring is a technique for restructuring an existing work environment by altering its internal structure without changing its external behavior. It’s the act of making small-J-curve, kaizen changes to reduce friction (caused by accidental complexity) and make it easier for people to do their jobs. As the goal of refactoring code is clean code, the goal is a “clean” organization.
- Strategy Deployer: This is the act of setting direction and providing clarity of mission to foster organizational improvement in which solutions emerge from the people closest to the problem. The goal is aligned autonomy and a leader-leader culture.
- Anzeneer: This portmanteau coined by Josh Kerievsky means “safety engineering.” That is, we need to protect people by establishing psychological and physical safety in everything from relationships to workspaces, codebases to processes, products to services.
- Coach: Coaching is teaching others to be leaders and building an organization that can sustain its success. As Jeffrey Liker says, leaders are responsible for creating an environment in which future leaders can blossom.
- Environmentalist: An environmentalist holistically (re)creates and stewards the environment in which people grow, with particular awareness of context or organizational “terroir.” Just like a winemaker will fail if he or she tries to grow a certain grape varietal in a place that is very different from another, so too will an organizational leader fail if he or she attempts cookie-cutter solutions or to install frameworks or initiatives irrespective of culture or context.
- Experience Designer: Similar to the experience design of products, this is means consciously creating meaningful interactions centered on the employee, with particular focus on intrinsic motivation (mastery, autonomy, purpose); “alleviating people’s problems and bringing them joy.”
- Experiment Curator: An experiment curator models and celebrates behaviors and creates the environment for employees to learn and share learning through experimentation. It’s basically creating a place for others to learn in.
- Flow Manager: Taken from the Kanban Method, flow management means to optimize the end-to-end flow of value in a system. Leaders need to make visible and look after wait flow as much as work flow, actively reducing dependencies and managing the system for smooth, fast flow, rather than utilization.
| Stance | In three words |
| 1. Organizational Refactorer | Reduce accidental complexity |
| 2. Strategy Deployer | Leader-Leader culture |
| 3. Anzeneer | Make safety prerequisite |
| 4. Coach | Enable over do |
| 5. Environmentalist | Passion for “terroir” |
| 6. Experience Designer | Design for engagement |
| 7. Experiment Curator | Foster learning culture |
| 8. Flow Manager | Optimize the whole |
Infographic: Project-to-Product Principles
Following is the infographic that Yoan Thirion and I presented at the recent XP2021 Conference in the poster track.
Also, you can read the accompanying white paper, which will be published in the conference proceedings.
Project-to-Product Principles
I’ve increasingly been helping organizations looking to go from “projects to product,” so I’ve curated/co-created/stolen a few principles for anyone who wants a tl;dr version of how to go about it. I’m indebted to the work of Jez Humble, Marty Cagan, Matt Lane and John Cutler.
In moving toward product-orientation, we prefer:
- Outcomes over outputs
- Solving problems over building solutions
- Options over requirements
- Experiments over backlogs
- Hypotheses over features
- Customer-validated learning over PO assumptions
- Measure value over measure cost
- Flow over utilization
- Optionality over linearity
- Product vision, strategy, personas and principles over product roadmaps
- Small-batch delivery over big-batch delivery
- Optimizing for assumptions being wrong over optimizing for assumptions being right
- Engineers solving problems over POs dictating requirements
- Teams of missionaries over teams of mercenaries
- Business-driven over IT- or PMO-driven
Sticking to the Plan is Not the Solution
[Note: To commemorate the agile manifesto‘s 20th anniversary, this is the first of 12 posts in no particular order on the manifesto’s principles.]
Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.
Manifesto for Agile Software Development
Changes to the plan mid-sprint. Constantly-changing priorities. Those words strike fear into the hearts of many team members. One popular agile-health assessment even downgrades as immature those teams whose “plan changes frequently.”
The agile manifesto addresses the idea of change, but it’s not to fear it or to view it as a sign of immaturity — rather the opposite: We are to welcome change and value responding to it over following a plan. So what’s going on?
I think this is a case of confusing the symptom with the problem.
It’s true that constantly changing priorities are often a smell of disorganized product management or unclear strategy. But those dysfunctions need not create additional ones. And it’s quite possible that those changing requirements actually, you know, create competitive advantage. Far too many teams and organizations blame “changing priorities” for their own inability to deliver quality product. I often see diagnoses of teams having difficulty delivering with prescriptions like “Stick to the sprint plan.” Changing requirements is not the problem, so sticking to the plan is not the solution.
The problem is not that the plan changes but that the team or organization lacks the capability to work in such a way as to accommodate change easily.
If changes to the plan result in any of the following things, you’re doing it wrong — and sticking to the plan isn’t going to help you improve:
- Taking technical shortcuts
- Working overtime
- Getting stressed out
- More defects (leading to the anti-pattern of defect sprints)
I understand why teams and consultants instinctively reach for the “stable plan” panacea: Teams commit to a slate of work, whether it’s a sprint, iteration or program increment, which they’ve often spent time estimating. Stakeholders (including well-meaning scrum masters) exert some amount of pressure on them to deliver what they’ve committed to, heedless of the nature of knowledge work (i.e., complex). Even when external pressure is low, the very design of a sprint or PI plan implies that success correlates to following the plan; I have encountered many teams who suffer low morale simply because they delivered something different from what they planned, whether it was because they weren’t able to estimate complex work or because a stakeholder changed midway through the plan.
And of course, teams are often held accountable for others’ — product management’s or HiPPOs’ — decisions. Sometimes, it’s because stakeholders behave badly: They are aware that their demand creates stress and pain on the team and refuse to acknowledge and respect a team’s finite capacity — they pile on tasks but refuse to remove any. But often, stakeholders do it out of benign ignorance, lacking a feedback mechanism to inform their choices (or, as Don Reinertsen calls it, “an economic framework”) and assuming that the team will figure out how to handle it. Therefore, it is incumbent upon the team to work in ways so as to accommodate change more comfortably.
However, the solution often put forward is to “stick to the sprint plan.” This flies in the face of the manifesto value to prefer Responding to Change to Following a Plan. Clearly, when a stakeholder makes a mid-plan reprioritization decision, it’s because of a real or perceived business need (a.k.a. “customer’s competitive advantage”). The question of whether it actually does provide a competitive advantage is secondary here. The team has an obligation to “welcome this changing requirement” whenever it happens. In what universe it is a good business decision to follow through on building a feature that we determine customers don’t want simply because we need to follow a plan?
People don’t really have a problem with changing requirements; we have a problem with being prevented from doing quality work. So the problem isn’t that we don’t want new information but rather how we accommodate it.
What makes it difficult to do that? Many things contribute, but I’ve seen two in particular:
- Too much work in progress
- Not enough investment in technical practices
The good news is that both of these things are typically within the team’s control.
Too much work in progress
Regardless of whether you work in a timebox (sprint, iteration, PI), your team — as well as you as an individual — should have control over how many things you work on at once. Just because you’ve “committed” to a plan of delivering 20 work items doesn’t mean you need to start all of them at once. That means stopping the inane practice of having individual team members sign up for work items (or worse, having someone assign them) before they start. Limit the number of in-progress work items to something less than the total number of people in the team. (Reinertsen again: “We will always conclude that operating a product development process near full utilization is an economic disaster.”)
This pattern replicates itself at the enterprise level. Organizations are unable to respond to big or urgent demands without significant disruption because they are saturated with “projects.” Most executives that I work with don’t even know how much organizational WIP they have, so for them, making it visible is the first step. But the reality is that when plans become promises and success is measured by conformance to them, we effectively lock in the largest possible batch size, which only exacerbates the problem of dealing with change (and of course is one of the worst things an organization can do).
Not enough investment in technical practices
Talking about XP practices seems so … 2000s. And yet I think that our industry has gotten worse, if anything, with respect to building quality in through things like TDD, pairing, loose coupling, emergent design and continuous integration. Here’s the thing about engineering practices and those stakeholders who are making those changing requirements: They probably don’t have a clue about the practices, and that’s okay. Once you pick up a story, take the time to do it right. The team’s definition of done should include things like proper testing, integration (maybe even deployment!). If it means that the story takes more than two weeks, that’s okay, too. Teams that don’t do these things are reasonably afraid to change the plan because they can’t safely undo (see long-lived branches) or share work (see “not my code”). But here’s the reality: If you avoid doing these things, delivery will never get easier. And, of course, the investment in technical practices will only happen if you limit work in progress.
Other options for better accommodating change:
- Stop planning in artificial time boxes (whether at the sprint or quarterly level) and instead plan just-in-time using pull (e.g., replenish the Next column based on capacity signals).
- Stop punishing teams and individuals for not completing their sprint or release “commitments,” including the tracking of the ridiculous sprint-completion rate and other “success” metrics based on conformance to a plan.
- Spend less time estimating work, as it represents a sunk cost that inhibits change accommodation (and likely has very little information value anyway).
- Show the cost of interruption. If we’re concerned about undisciplined product owners making careless decisions, make the cost of the decision visible. We can do this with simple flow metrics and post-commit discard rates. If we’re tracking delivery times, we can easily see the “flow debt” that we incur by pausing or dropping work to tend to expedite requests. (Typically this is apparent on a delivery-time frequency chart, manifesting as a bimodal distribution.)
- Use and make highly visible policies that show how you treat work, such as the selection criteria the team uses to pull work items. For instance, some executives, if they knew that their requests were being treated as “drop everything and work on this now,” would think twice about the requests (I’ve met a few).
The bonus is that if we solve the problem rather than the symptom, we’ll actually save time by avoiding daft things like trying to get better at estimating, debating “carryover” stories and coming up with complicated prioritization schemes (just FIFO it). If we’re able to accommodate change gracefully, those remnants of the agile industrial complex go away.
I would even go so far as to aver that being able to accommodate change mid-sprint is actually a fantastic “agile health” metric. After all, if you can’t do that, you won’t be able to do anything very well, whether it’s scaling, product pivoting or increasing throughput, quality or speed. Don’t hide the problem by requiring the team to “stick to the plan.” Fix the underlying issues so that the team can support the organization in what it’s trying to do, which is to exploit variability for economic benefit. Isn’t that the whole idea of business agility?
Matt Philip's Blog 