Leadership

September 27, 2021October 4, 2021

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)

January 27, 2021February 1, 2021

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

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.
Work through a few problems from the book.
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.
Memorize things you need to memorize to help you with your accuracy and speed.
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.

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.
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.
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.

April 15, 2020

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.

Management	Leadership
– 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.

April 6, 2018April 20, 2021

Rock Engineering, Gold Plating, and Features

I used to have this post somewhere else, but it was inside a “previous life”. It got impressively long (see gold-plating below), and even talked about Beethoven. I’ll start this out small. Maybe I’ll enhance it with some of those additional stories at some point.

The intent is simply to identify and describe anti-patterns associated with Requirements. Mostly this is for fun, because we don’t do Requirements anymore in Agile (although the lessons within these anti-patterns do have applicability in the Lean/Agile world for sure). Instead, in Agile, we often use the XP constructs user stories and epics, or sometimes just a simple and regular flow of enhancements and other issues. In OO we do use cases and scenarios. In any case we’ve recognized that they’re not really requirements; they are – to quote one of my mentors Walker Royce – desirements. That is, they’re negotiable.

Contents

Rock Engineering anti-pattern
Gold-Plating anti-pattern
Features

Our first anti-pattern is Rock Engineering. It is a form of crafting a solution to a problem that doesn’t exist, or a problem that is poorly understood. It goes like this …

King: “I need a rock. You there, go bring me a rock.”

You: “Yes, Sire, I shall bring you the finest rock in the land.” (and so you go find a rock.)

You: “Sire, I have brought you a rock, here it is, it is the finest rock in the land.” (Present with flourish)

King: “This is not the rock I need. It is too small.”

You: “Yes, Sire, I shall go find you the rock you need, the finest rock in the land.” (and so you go find another rock)

You: “Sire, I have brought you another rock, here it is, it is the finest rock in the land.”

King: “This is not the rock I need. It needs to be brown, and this rock is gray.”

You: “Yes, Sire, I shall …”

Of course, we can go on like this for hours until we accidentally bring the King a rock that he finds suitable, and even then it might not be exactly what he was looking for. What we need to do is elicit some requirements, shorten the time by focusing in on a solution that meets the actual expressed need. In order to do this, one is going to have to ask questions! Of course, if any time one asks the King a question one’s head is removed, that might be a cause of this wasteful behavior we obviously refer to as Rock Engineering.

Gold-Plating

A poor practice accentuated by Waterfall is called gold-plating. It occurs in conjunction with developing some capability that we perceive is needed or has been asked for. We have plenty of time to develop it, because it’s Waterfall and there’s never any urgency early in Waterfall. Let’s be sure we get this right and Wow our customer. So in addition to the bare minimum need we go over the top and really add some bells and whistles.

Yup, this is called gold-plating. Several results can accrue, and only a few are good. Among the not-so-good:

Customer says, wow, that’s really cool, but I don’t need that and I’m not going to pay for that. All I needed was the functionality I asked you for.
In your zeal to build this cool stuff, you injected Mr. Debt. Mr. Technical Debt. It’s buggy. It doesn’t run, or it runs slowly or otherwise unreliably.
You overrun the time budget and/or the dollars budget.
Your supervisor discovers that you’re overrunning the time/dollars budgets.
Customer says, ugh, that’s really awful, that sucks, and I really I don’t need it so I’m not going to pay for that. All I needed was the functionality I asked you for.

One reason for Agile’s focus on values like sustainability, the customer, customer collaboration, short feedback loops and minimum viable product (MVP) is to avoid this anti-pattern.

Features

This one is short but I found it amusing once upon a time.

Definitions:

Bug: informal name for a software defect. The name arose because Adm. Hopper was tracking down a defect during some of her early work and found a physical bug in the hardware that was shorting it out and yielding erroneous results. Often depicted graphically as the image of an insect.
Feature: a bug that has been lovingly documented and memorialized in the software and its documentation artifacts. Depicted as an insect wearing a tuxedo.