Posts

Posted on

MOP and MOE for the USA

Measurements are so crucial. But in politics today, measurements are rarely used for their intended purpose. Here I am going to try and select a set of measures, maybe 20? and track them to EOY 2026 and EOY 2028, in hopes of actually understanding relatively objectively the performance and effectiveness of the current USA Presidential administration as of early 2025.

A beginning note follows from my buddy Mike – see below for more on actual MOPs/MOEs we choose/chose. There will be lots of edits to this post if all goes well.

There are MOPs (Measures of Performance) and MOEs (Measures of Effectiveness). These would be against specific functions the government performs. I would argue these would need to be auditable by an independent agent just as it is in the business world.

One example is SS. Is it effective? I’d say the MOE would be the quality of retirement for the people who retired and depend upon it. The MOP would be in relation to its current tax and spend structure and an investment structure for the money. Estimates I’ve seen are the annuity payments for retirees would be 3x higher if the money was put into a private account vis the current structure. Independent auditors should look at this and write an annual report.

It also seems to me this exercise must recognize the nation’s $36.5T debt and the need to do something. We also need to recognize that most of the spending goes to entitlement programs. Their constitutional basis is the authority of Congress to raise and spend money. The MOPs and MOEs would be looking at the question of privatizing these programs to provide more benefit to the recipients and reduce this cost to the federal government.

Education: It was originally justified, I believe on a civil rights basis because separate but equal did not work. However, it doesn’t take much of a look to see that per pupil expenses have soared while education outcomes have declined. Some of the MOPs and MOEs are obvious, such as per pupil spending and educational outcome. I think there is another one to look at efforts to continually improve performance In today’s world that would involve the application of technology to reduce costs and improve outcomes.

Final thought: Some form of measurement and feedback is badly needed. Congress measures success by how much money it spends. You have a problem? We will throw some money at it and maybe create an agency. The goals of measurements should be the overall improvement of society and not the government. In 1787, the federal government was funded by tariffs and consumed less than 5% of GDP. The nation’s economy grew at 4.5% year over year until the 1920s. Since that time, the nation’s economic growth rate has declined and now hovers around 2%. Today’s economy would be 2.5x what it is had the nation’s growth continued at the rate it did with what the Founders left us. I think the size of the economy and wealth accumulation are good measures for the performance of the nation under the stewardship of the central government.

x continuing … (to be determined/edited)

Posted on

Retrospectives in Battle

I have been lax in continuing my blog in retirement – sorry! We’ll see if I do better in the future. It is retirement, after all.

The following excerpt (italics) is from Air Combat at 20 Feet … Selected missions from a strafer pilot’s diary … by Garrett Middlebrook (“Middie”). This amazing book, borrowed from my friend Mark Dickerson, details missions from Middie’s diary of air and ground combat during World War II. He was the pilot and commander of a North American B-25 Mitchell. Shortly after arriving in the South Pacific his medium bomber aircraft was modified by adding strafing gun packs. This excerpt is near the beginning of the book. So often we learn too little from these gentlemen of our greatest generation, simply because it is too difficult for them to speak much about their experiences. No one blames them for this, but this man, Garrett Middlebrook, was up to the task of transcribing portions of his missions diary into an excellent book, and for that we should all be grateful.

That afternoon I met in private with my crew. From the very first mission we did something the other crews, except for Bill Gay, thought unnecessary. We critiqued each mission with a clear understanding that each crew member had the right to make any suggestion or criticism he desired. If I found that some suggestion was not practical, I never ignored the crewman. Instead, I explained to him detail why his idea was not practical or effective. 

On that particular day, however, I accepted all the blame and responsibility for having centered my attention on Parker’s plane [after the airplane was hit by the enemy and was going down], and for having allowed myself to become emotionally distraught with sympathy. Three other crew members confessed to sympathetic indulgence also.

I promised I would never again lose my trend of concentration [on the mission] by being sympathetic to a doomed crew, no matter who they were. I then advised my fellow crewmen that I expected them to refrain from sympathy and to maintain vigilance at all times. I suggested that we would have plenty of time for sympathy and sadness once we were back at base.

I kept my promise. I saw several planes go down after that date. When a plane fell from the formation, I always pressed the intercom button and reminded the crew to look up and not down. I asked them to fight for themselves and for each other so that the Japs would not bring us down. I received magnificent response on each occasion. They did not need morale lectures thereafter because we shared a common transition that day. We all became veterans. Although we endured and suffered through many [Japanese] Zero attacks thereafter, none ever surprised us.

I have two quick remarks on this sobering text. First, retrospectives are useful even in, perhaps especially in, the most dire of circumstances. Second, to accomplish the mission, sometimes one’s sole focus must remain on that mission. These lessons were learned the hard way, in battle. May those who fell rest in peace. 

Posted on

Aviation oils (a bit of research done for my glider club)

I did a little research on engine oils, here is what I’ve found, starting with a summary valid for our horizontally opposed six cylinder engine:

  1. Summary: our options appear to be:
    • Aeroshell W100 and CamGuard
    • Aeroshell 15W50 by itself  (it already has additives for antiwear/corrosion)
    • Aeroshell W100Plus by itself  (already has additives for antiwear/corrosion)
    • Phillips 66 X/C 20W50 and CamGuard


Based on this I recommend a single weight oil in summer, so W100 and CamGuard is a good option there. Full disclosure, I’m a CamGuard believer, I use it with every oil change on my 180 (whose engine is now 700+ hours over TBO btw).

I recommend a multi weight oil in winter unless we are very diligent about thoroughly preheating the engine. From the above, it appears we can use 15W50 by itself, or Phillips 66 X/C 20W50 and CamGuard. Personally I’d lean toward the latter, with our application.

I derive this summary from the information below, which came from two articles:

  • Oil types: Quoted from boldmethod.com: There are two main oil types used in aircraft engines: mineral oil and ashless dispersant (AD) oil. Both types are made of mineral oil – a refined, petroleum based oil. However, AD oils have added chemicals (additives), which collect debris inside the engine and carry them to the oil filter. Unlike mineral and AD oil, synthetic oil is not made from whole crude oil. There are some synthetic blend oils used in aircraft engines, but they aren’t as common. Shell Oil tested all-synthetic oils in aircraft engines, and what they found wasn’t good. At 600 to 900 hours, the engines began to burn more oil and lost compression. “When the engines were disassembled, we found that the piston rings were covered with a gray tacky substance that was primarily made up of the lead by-products of combustion.”

  • Break in oil: also quoted from boldmethod: Many pilots have learned to use straight mineral oil while breaking in a new engine. It’s thought that mineral oil is less viscous (less slippery) than AD oil, and that it will allow the piston rings to wear in the cylinder walls more quickly. However, not all manufacturers recommend this practice. The Continental Motors engine break-in guide recommends straight mineral oil, while Lycoming recommends AD oil when breaking in all turbocharged engines. What should you use? Check your engine’s manual and follow the manufacturer’s instructions – always the best bet for long engine life.

  • Oil selection: Quoted from AOPA: When selecting oil, the first thing to consider is viscosity. Simply put, “viscosity” is the measure of a fluid’s resistance to flow. Most air-cooled aircraft engines are designed for SAE 50-weight oil at operating temperature (approximately 210 degrees Fahrenheit).

    In fairly stable, warm environments, a straight-weight oil such as Aeroshell 100, W100 or Phillips 100AW is a good option because these 100 oils all perform to the SAE 50 spec. In slightly cooler temperatures, straight-weight 80 oils will also work for some engines because they perform to SAE 40. If you have ever had to break in a new engine, you may have been told to use mineral oil. Mineral oil is a straight-weight oil that has no chemical additives and is typically used in engine and cylinder break-in to assist with the seating of rings.

    For performance across a wider range of temperatures, it’s best to use multi-weight oil. Multi-weight oils are typically semi-synthetic, utilizing an added polymer to make the oil flow like a lower-viscosity oil in colder temperatures, yet still perform the same as a straight-weight SAE 50 oil at operating temperature. The most common multi-weight oils are AeroShell 15W50, Phillips 66 X/C 20W50, and Exxon Elite 20W50. The numbers in the name of the oil indicate the range of straight-weight oils that the multi-grade covers. For example, Phillips 66 X/C 20W50 oil has the viscosity of 20 weight oil in low temperatures for faster lubrication on cold starts and the viscosity of a 50 weight oil in high temperatures to protect the engine after it is fully warmed up.

  • Additives:  again quoted from AOPA: The first and most important type of additives is ashless dispersants (AD). Ashless dispersant oils have an additive in them to aid in scavenging debris and carrying it to the filter or screen. This is a very important quality, given the relatively high wear of aircraft engines and the amount of combustion acids and other contaminants that get past the cylinder rings and valves.

    Finally, the last category of additives is anti-wear and anti-corrosion additives. Oils such as Exxon Elite 20W50, Aeroshell 15W50, Aeroshell W100Plus, and Phillips 66 100AW include varying combinations of anti-wear and/or anti-corrosive additives. That said, products such as ASL CamGuard and AVblend can be added directly to non-additive oils such as Phillips 66 X/C 20W50. In these times when airplanes are flying less, I recommend using some sort of anti-corrosion additive in your oil. Please note that these are both FAA-approved additives. You should never use an unapproved additive, regardless of what you might hear around the hangar water-cooler.
Posted on

Wartime Scrum Master

First, some background; this is taken largely from a single book I’ve been reading: Hellcat, The F6F in World War II, by Barrett Tillman, Naval Institute Press 1979.

For many years, there was an aircraft manufacturer on Long Island called the Grumman Aircraft Engineering Corporation. Formed in 1929, this company, during World War II, was instrumental in developing and delivering important military aircraft to both theaters of war, though mostly the Pacific theater. To take but one example, in one month, March of 1945, Grumman delivered 658 aircraft to the United States Navy.

Barrett Tillman, in his book Hellcat referenced above, asserts that the primary reason for the exceptional success of Grumman was superb management. To quote Mr. Tillman from page 8 of the book:

“Equal credit [for this excellent management paradigm] goes to Roy Grumman and Jake Swirbul. They oversaw the efforts of some 20,000 employees working in a 2.5-million square-foot complex, turning out an average of almost one million dollars’ worth of aircraft and parts every day. Even more amazing is the fact that virtually none of the wartime workers had previous experience in building airplanes. A large percentage were women, but Grumman’s turnover rate was less than 3 percent – half the rate for the rest of the industry [my emphasis]. And there was never a strike or work stoppage; the employees saw no reason to unionize.

“In short,” Tillman relates, “Grumman was a happy place to work. Though the payroll expanded to more than ten times the prewar figure, the company still functioned like a small, close-knit family. There were [many] features: [everyone received a Christmas turkey,] daycare centers for children of working mothers, noon softball games, periodic airshows, frequent dances, [imaginative production methods,] even counseling offices …”

With that as background, the following short paragraph, also quoted from the book, will make sense as a sterling example of the idea behind a Scrum Master’s facilitation services to his/her team, so that the team collectively can maintain the utmost focus on the job at hand.

“But the best known, and probably the most appreciated, was Jake Swirbul’s “Green Car Service.” The object was to keep people on the job, relieving them of small distractions. A phone call or a word in the right place would send Jake’s Green Car scurrying off to perform almost any kind of service: fix a flat tire, start a dead battery, make sure the oven was off at home, deliver a message. Anything to keep the employee on the job.”

Cool, eh? That’s a primary goal of the facilitation a Scrum Master provides: keeping people on the team focused and on the job, that part of the job which is adding business value. (Would that we had good ways to visualize the flow of business value! Oh wait, that exact statement is at the top of page xviii of Mik Kersten’s Project to Product; I just began reading this book. It looks good for sure.)

btw here is the NASM page on their F6F-3K. It was an amazing aircraft for its day. (Image credit: defencetalk.com)

Posted on

Modern App Frustrations

Remember the good old days? Software came with a user manual. For complicated software, at least, the manual was indispensable. Complications were dealt with in a way reflecting a focus on procedure. In order to do mail merge, first do this, then this, then this … and so on, until you’re done.

example user manual
an ancient Rational Rose manual

Well, today’s apps are not this way. If there’s a manual at all, it’s online. More often, it’s a few youtube (this and other words herein are most likely trademarked so please assume that where appropriate) videos. However, there is something more fundamental going on. Let’s take your average iOS app. The same is true for Android apps. Such an app, at least if it is popular, is frequently updated. Many of my favorite apps are updated two or three times weekly. Some apps appear to be on an update schedule; others are updated on demand – “we fixed some defects”. Here’s a partial image of my iPhone screen from this morning; after a single day the App Store app has 16 updates.

iPhone screen
Sample screen from my iPhone

More importantly, there is no longer a focus on procedure. No written user manual would be effective, because it will be obsolete in two or three updates. They keep changing stuff! They think they’re making their app better for you. Sometimes they are. Inevitably, they change the way things work. In many apps, the only method you can use to get something done is as follows:

  1. I’ve done this before, now how do I do it?
  2. Review the screen thoughtfully, and click on something that looks like it might lead to my desired action – this may involve several attempts; a common but not-always-available heuristic is “oh, I remember this icon, let’s try that”
  3. Repeat step 2 until you’re on a screen containing your desired action, remembering that the icon displayed that means your desired action may not be the same as last time either

This can be incredibly frustrating. Every human enjoys procedure; it allows actions, especially common actions, to be formulated into a habit, so a lower level of thoughtfulness is required to undertake actions. The authors of some of my apps know this and minimize change per unit time where they can. The authors of most of my apps don’t really try, as near as I can tell; they think, “oh, this would be better, let’s do that”.

Finally, the older you are, the more difficult this transition is. Don’t ask me how I know this.

Posted on

Tackling new problem types

I am motivated by my recent experiences tutoring math students to write the following missive on discipline associated with tackling new problem types. I don’t feel like it is something we should be using directly as tutors, but I often find myself going through this 5-step process by example with the current problem type, so that the student, and I, both know at the end that if s/he simply practices the method we have agreed on, s/he’ll be able to accurately and quickly do the next such problem that arises.

HOW TO TACKLE NEW MATHEMATICS PROBLEM TYPES

  1. Understand the definitions surrounding these types of problems. Then understand why it might be important to know how to do this. It might take some reading and/or asking to know this, but knowing why is important because it keeps you motivated. Be able to say why it’s important to you. You might have a low level why and a high level why – see the example below for what this means.
  2. Work through a few problems from the book.
  3. Use these examples to craft a solution method that works for you. The book presents a method. A teacher, professor or tutor will probably have a related method, but with some differences. Any valid method can be used as long as you can show your work with it, since teachers usually ask you to show your work. The key is that the method be something you can remember and repeat accurately and quickly.
  4. Memorize things you need to memorize to help you with your accuracy and speed.
  5. Practice what you need to practice, until you can do it quickly and accurately.

Example: let the problem type be finding the slope of a line from a pictured graph of that line. Let’s go through what each of these 5 steps above might look like.

  1. Slope.
    • Definition of slope: the angle, inclination, steepness, or gradient of a straight line. Defined to be positive if it rises as one moves to the right, and negative if it descends as one moves to the right. 
    • Low level why: if you know the slope, there are a bunch of other questions about the line that can be answered quickly, such as where does this line cross the x-axis or cross the y-axis? Slope is necessary to at least two common methods of characterizing a particular line, the gradient-intercept form and the point slope form.
    • High level why or practical reasons for this concept: a common use of slope is in geography, when describing the steepness or gradient of the surface of the ground. Many geographic information services (GIS) analyze digital elevation data and derive slope and aspect data sets. Slope is an important landscape metric that is used in characterizing and modeling things like landforms, surface runoff, habitats, soils, wildfire risk.
  2. Work through a few problems of the type allow you to begin to understand a method that will work for you. Use the book, use a tutor, review a teacher or professor lecture … whatever it takes.
  3. Here is an example method for finding slope from a graph that works for many students. Notice that this method is a lot more difficult to describe than it is to execute. That’s often what we’re looking for – something procedural, that you developed yourself, that you can therefore remember and makes it easy for you to do a problem of this type quickly whenever you’re called upon to do so. It doesn’t have to be different than how you were shown to do these problems. But it can be, if that works for you and it is correct.
    • Find any two points on the line, using the graph to do so. It can pay to be a little clever, if only to make the arithmetic you’re about to do a little easier. That cleverness is simply to attempt to find one or both points so that they are characterized by x and y values both of which are integers. But that’s not always possible so don’t work too hard at that. 
    • Write the two points down, each as an ordered pair with the x value first and y value second, using the standard ordered pair syntax. When you do this, write the second point down exactly underneath the first point. For example:

     (41, -6)
     (-7, 10)

  • Now put a big “minus” sign in front of the second point as a reminder of what you are about to do, example

     (41, -6)
—  (-7, 10)

  • Now subtract the two x values and then the two y values, and write the answer as another ordered pair. Be careful with the minus signs, it’s easy to get mixed up. Example

     (41, -6)
—  (-7, 10)
     – – – – – –
     (48, -16)

  • What you’ve just done is compute the “rise” or delta-y, and “run” or delta-x, i.e. (dX, dY). The slope is defined as dY/dX so the last step is easy: divide the second number by the first, and simplify the resulting fraction as necessary. Example: the slope m is dY / dX =b -16 / 48 = -1/3.
    • Double check!! if the slope you calculated is positive, does the graphed line rise as it goes to the right along the x-axis? If negative, does it descend? Does it look right? That is, if it is a fraction between -1 and 1, is the line in the graph going up or down slowly? If it is greater than 1 or less than 1 does the line in the graph go up or down fairly quickly?
    • Summary: find two good points, write them one on top and the second directly underneath. “Subtract” the 2nd ordered pair from the first, being careful with the minus signs!, to achieve a new ordered pair (run, rise). Divide rise by run, then simplify. That’s your slope m.
      _
  • 4. Memorize some things to make it easier for you to do and check your work quickly:
    • Slope, often denoted m, can be defined as rise, or change in the Y axis, divided by (or “over”) run, or change in the X axis. Again, slope is “rise over run”.
    • A line with slope 1 goes up at a 45 degree angle. A line with slope -1 goes down at a 45 degree angle. 
    • A line with slope 0 is parallel to the X axis, and perpendicular to the Y axis.
    • A line with an “infinite” slope, that is any finite number (the rise) divided by zero (the run), is parallel to the Y axis.
    • If you use ordered pairs, you can “subtract” the second point from the first and get a new ordered pair (run, rise).
      _
  • 5. Practice until it’s second nature to do this. There is no substitute for practice.

    Does this look like a lot of work? It IS a lot of work. Well, it is at first. Then you become accustomed to learning how to solve new problem types, and it goes more quickly. This is an aspect of learning how to learn, and having some discipline to do things like this will serve you extremely well in life, that is, for much more than just mathematics. Definitions and why, look through or work some examples, craft a correct method that works for you, memorize things that will help you execute the method quickly and accurately, and practice until it’s second nature. That’s it. Just do it.
Posted on

Remote Story Point Sizing

All you need is a chat window. No really, it’s true. (Though sadly, the reason I’m posting this is because too many companies, even large ones, are astoundingly reluctant to invest in the successful collaboration of their teams.)

Here is a script for sizing a small number of items one at a time using a voice conference call and a chat window; this seems like a small enough technology requirement to assure that almost everyone doing a remote team exercise will have the necessary technology. I’ve been honing the wording on this, as the slightest mistake in wording can lead to someone prematurely showing their size to others, which results in bias.

  • Your facilitator says, “Is anyone NOT clear on the item we are about to size?“
  • If everyone is clear, then the facilitator says, “Ok, without typing the enter key yet, please type your size estimate into the chat window, sending to all; again, do NOT yet type the Enter key.”
  • The facilitator can type into the chat window, “Looking at item <number or description>” – this is an informative interstitial that separates this sizing evolution from a previous one.
  • The facilitator says, “Does anyone have yet to decide on a size?“
  • If not, the facilitator says, “Three two one Vote“, and at that point everyone types their Enter key at the same time, on the spoken word “Vote”.
  • Of course, if everyone is agreed, then your item is sized.
  • Otherwise, one more round of voting can occur as above, after allowing for discussion, remember to get the high size vote and the low size vote in on the discussion to clarify their reasoning to your team. I recommend no more than two voting rounds total to save time.

One can do a Fist of 5 (Fist to 5) in this way also.

  • Facilitator: “I’d like to get a Fist of 5 to ascertain our confidence in meeting the sprint goal and sprint content to which we are about to commit.“
  • Facilitator: “Without typing your Enter key yet, please type your number of fingers into the chat; again, do NOT yet type the Enter key.” Here also, you can describe what each number 0 (or 1) through 5 means as you are accustomed to using this consensus method.
  • Facilitator: “Does anyone have yet to type in a number of fingers?“
  • Facilitator: “Three two one Vote” – as above.

I hope that helps! There are many other ways, but as most readers will already be aware, obtaining an unbiased response from each participant is important.

Theory. If you want to read more, try …

Posted on

Leadership

Reviewing John Kotter’s book Accelerate (XLR8) in preparation for a conversation about a Guiding Coalition. I found this table – about as short as you can get in describing the difference between management and leadership.

ManagementLeadership
– Planning
– Budgeting
– Organizing
– Staffing
– Measuring
– Problem solving
– Doing what we know how to do, exceptionally well
– Constantly producing reliable, dependable results		– Establishing direction
– Aligning people
– Motivating people
– Inspiring people
– Mobilizing people, to achieve astonishing results [including innovation]
– Propelling us into the future


Management vs. Leadership, from Kotter’s Accelerate

As it transpires, this table above was useful. During our conversation we also found a few additional nuggets.

  • Managers often want to be the final authority, to make the decision. They must resist, as encouraged by the principles of trust, empowerment, self-organization … at best, if the team will allow it, they can be part of the team who makes the decision. No more.
  • Product Owners make decisions like managers often want to make. If that kind of decision is needed, go get the Product Owner.
  • All this desire to be managed is amplified by the next fire drill. Two things about fire drills:
    1. Fire drills encourage management-style thinking in people not accustomed yet to being leader. Specifically they may try to abandon process to get it done quicker. As my mentor Murray Cantor would say, do not abandon process. If it’s not going fast enough, improve/modify it for speed, but do not abandon it.
    2. Managers get tired of the phrase “everything is an experiment”, especially during the next fire drill. And yet experimentation is what is needed to become more Agile. The thing is, sure, it is an experiment, but it often comes without the option to fall back, to fail backward. Therefore, plan to fail forward. Experiment continuously, but plan to fail forward. No failing backward, only forward.
Posted on

Working Agreements

I was about to write a post on working agreements with an emphasis on their use in Agile Teams. There was no need – the wheel has already been invented! and is right there on the amazing internet. I encourage you to read these two internet posts in order; they’re both short. The second one has a video with dogs in it – that can’t be bad.

Posted on

A wee bit of predictability math

Agile teams who start their Agile journey in Scrum quickly learn something called story pointing, and how to use it to enhance their predictability. (Hopefully they also learn to avoid trying to leverage story pointing to understand productivity, but that’s a separate story.) Anyway, there are many internet references to story pointing. Pointing is a clever way to avoid the need to make all the stories in our backlog roughly the same size prior to implementation.

When the team is also developing on a static cadence, say a “sprint” length of two weeks, then we can call out a set of stories, put them “in” our sprint backlog to be done in this sprint, add together their story points, and call that our forecast, say 40 points. It used to be called commitment and I still think that’s a good name: we commit to the Business that we’ll do everything we can to make our forecast. We can do that because we’ve established historical perspective that tells us we are consistently able to complete that many story points in every sprint. Jira (among many tools) shows us this in the Velocity Chart report.

Velocity, then, is about a forecast over a static time period. However Kanban teams are among those who don’t “sprint”; they don’t develop on cadence. They do demonstration and review on demand, and to establish predictable behavior they consider flow instead of velocity. They have more work to do on their stories: instead of pointing them, a Kanban team needs to split their stories until all the stories they develop and deliver are about the same size. When that is true and if we are on a cadence, we could switch our units of velocity from story points per sprint to stories per sprint and it wouldn’t matter much. When we are not on a cadence as on a Kanban team, we think about flow instead, or the average time to complete a story once it is selected for development; this is called Cycle time. (Separately we can have a discussion about the related measure, Lead time.) Note that Cycle time and Velocity are inversely proportional to each other if both are being measured with the same units (either stories, or story points). Example using stories:

Let Velocity be the average stories per sprint
Let Flow be average days to complete a story
then Velocity = L / Flow
where L = sprint length in days

If we are using story points rather than stories, and not trying to get all our stories to be about the same size, Jira only helps us if we are on cadence, ie sprinting. Jira does not measure cycle time for story points, only for stories, so a story point-based cycle time must be calculated manually. That being the case, we discourage story pointing unless our squad is sprinting. Instead we encourage splitting our stories until all the stories we select for development are of similar size.

Cadence, such as the sprints in Scrum, is very useful. Teams typically thrive on the rhythm and story pointing is not difficult (at least, not once you “get it” – yet another separate story!). Kanban teams have more flexibility but as is so often the case, it’s a trade off: more discipline in story splitting is needed to be successful.