Of Redskins and Irishmen

I never understood how people backed the Redskins name. It's so obviously racist. I've heard the argument that it isn't necessarily derogatory. Certainly it isn't "nigger" or "kike", and not even "wop" or "mick". But we don't have the "Cincinnati Darkies" nor the "Atlanta Whiteys". Why should we ever lump an entire group of people all in by skin color? You can do your own research on the etymology of the name, but it boils down to making a mascot out of an entire race of people by their skin color. I never understood that. It's (past) time for it to go.

I have mixed feelings about using Native American iconography at all. For example, I understand that Florida State has a very good relationship and open dialog with the Seminole tribe in using their name. I know that the University of North Dakota abandoned the Sioux name after it could not get approval from all neighboring Sioux tribes. ( I have to note here that 'Dakota' is literally one of the linguistic divisions of the Greater Sioux nation, so one of the suggestions in their entire naming controversy was to just call the teams 'North Dakota' as 'North Dakota Sioux' was simply redundant.) I can understand arguments both for and against the Blackhawks, the Braves, the Indians. Those aren't blatantly racist and contemptuous. I could even attempt to hear an argument for the "Tomahawk Chop" cheer of Braves fans. (I dunno. I'd listen, but I'm pretty close-minded to those particular shenanigans. "The Indians" kind of too - I wouldn't really understand the argument behind that mascot. I'd try. [No, I wouldn't.] I like that "Caucasians" t-shirt one can buy that mocks the Cleveland Indians.) Redskins, though, is a racist, pejorative term. It may not have started that way (again, feel free to do your own research) but it has been used that way for over a hundred years. Has to go.

In a Facebook post I brought up the fact that everyone seems to completely ignore "The Fighting Irish". It broke down into a thread about the merits or lack thereof of the Redskins moniker. I should know better. (I should know better than to say anything slightly political in a Facebook post. Though how this is even a political issue is absolutely stunning to me. [I should say, it WAS stunning until I thought about it more and realized I shouldn't be so surprised.] I should also know better than to say anything that goes a slight bit against the tide of the social discourse of the day, which has turned into more tide than actual discourse. Don't say anything against it nor even something tangential to today's topic - you'll just be trying to swim across an overwhelming current. Just nod your head and go with it.) The Rice name is Orange Irish. I'm pretty sure our family went over to the Emerald Isle and beat (and worse) the Catholic into servitude. So I'm not going to feign any sort of indignation at the name "Fighting Irish". What perplexes me is that I don't understand why people ignore the mascot of Notre Dame but are incensed that North Dakota would use "The Fighting Sioux".

The Fighting Irish is no less a pejorative than the Fighting Sioux (though both, to me, are much less so than Redskins). One of the stories of how Notre Dame athletes gained the moniker is that Northwestern students taunted their team with "Kill the Fighting Irish" during a game in 1899. (There have been many proud days in Northwestern history, but that doesn't sound like one of them.) Another is that Notre Dame's own coach used the stereotype when he said to his team during a game in 1909, this time against Michigan, "What’s the matter with you guys? You’re all Irish and you’re not fighting worth a lick.” In 2005 the NCAA went forward with sanctions on just about anyone with a Native American mascot including the Fighting Sioux of North Dakota, but said nothing about Notre Dame.

Anytime the NCAA does something about anything I first assume it's about money. Why doesn't anyone else take notice of it, however? What doesn't anyone, Irish or otherwise say, "Hey, why are you holding onto that old stereotype anyway?" (I have my personal suspicions.) You will notice that the media hardly ever adds the "Fighting" part in anymore, particularly NBC, simply calling them "The Irish" more often than not. But Notre Dame's athletics web page is titled "Notre Dame Athletics | The Fighting Irish". I realize that I've written a lot about Notre Dame now on the day the Washington Redskins gave up their mascot, but here's the reason - It makes doing something that is completely right, like standing against the Redskins name, look hypocritical. It smacks of political correctness instead of simply what it is - Correctness. I'm not suggesting that we change every athletics mascot name that might offend someone in someway. I'm saying that if we are going to have a conversation about removing racially or ethnically disparaging names and The Fighting Irish doesn't even enter the conversation, people need to ask themselves why.

Juneteenth

I am reminded today, June 19th --Juneteenth, Freedom Day -- of the visit that Jen and I made to the Whitney Plantation when we went to New Orleans. It is a trip I would recommend anyone visiting New Orleans should make. In fact, I'd recommend it as the focus of a trip that every American should make. 

It isn't a trip to be made lightly. National Geographic compares it to making a trip to Auschwitz . I would imagine that the contemplation of any human being treated as less than human is going to evoke similar emotions in anyone with a shred of empathy. For as much reading and learning of slavery we have had in schools, it doesn't prepare you for the gut punch of seeing a price list of people.

There is, I think, this myth that we white Americans like to hold onto that slave owners actually treated their slaves relatively humanely, and that it was really only some particularly cruel owners that treated them badly. After all, a dead slave was no good to the owner, right? The truth that one learns at Whitney is that in almost every case, slave owners simply treated slaves as a commodity, cogs in a wheel of a machine that, in Louisiana, was used to turn sugar cane into sugar, a grueling and particularly dangerous process. Yes, while plantation owners did not want their machinery to wear out early, they were horribly practical in the life-expectancy of those cogs. People did not live long while working the cane fields, a handful of years maybe, ten to twelve at most. The phrase "being sold down the river" came from the slave experience of being sold down into the cane fields of Louisiana from cotton plantations further north. 

I compared the entire explanation of slave ownership by our guide at Whitney to my experience owning a car: I don't want to treat my car poorly. I'm really pretty fond of my 2012 Ford Fusion. It was a pretty dear investment. At eight years old, though, I know it's getting to the end of its lifespan. I know I'll move on and get something else in a couple years. To think, even now, that this is how plantation owners felt about people, and that I could conjure up such a comparison now, quite literally nauseates me.

I was very impressed with our guide at Whitney. A young black man, he gave us what I believe was really the unvarnished truth and a horrible sense of what it was like to live at Whitney. There was no need to embellish the awful facts. They were laid out before you like the price list I mentioned or the tiny slave quarters or the "hot box" chamber mentioned in the National Geographic article. Stands of the sugar cane with its razor-like leaves were right there, and the treeline past the fields that led away into the swamps that would beckon slaves to freedom or death, either way escape from their condition, still stands out there. 

This is the story of my slave benefactor at Whitney, Chris Franklin. I say benefactor because Mr. Franklin paid a very costly price in order to provide me a single afternoon of education. I am very grateful. Reading that story, one might say, "It wasn't all THAT bad. They even got extra potatoes and egg nog at Christmas." Then you compare that to Mr. Franklin's impression of how well he felt the master kept his hounds. Slaves were treated no better than dogs. The master was fine to marry off a couple because he knew it meant additional litters of slaves for him.

None of us are free until all of us are free. That is a great sentiment to carry forth today. In a literal sense I'm sure we are all appalled at the idea of a man, woman, or child being manacled in an iron box on a hundred degree day. We have a ways to go to stamp out ignorance and injustice still, however. The focus, of late, has been on the police profession. The police do have the ability to use force that is immediately apparent. However, discrimination still pervades every industry in America. It is still apparent in the retail industry, for example. For, as progressive a company as Nordstrom is, I am still reminded that only two years ago black teens looking to buy clothes for prom were racially profiled by Rack employees. Even so, I believe that the discrimination in the legal, medical, and especially the media is as damaging, if not more so, than by police.

So we need to look at ourselves and our own sense of humanity. My religion is built on empathy and loving-kindness. In just writing that I am reminded also that I am a sinner. I need to practice.

Divided We Die of Typhus

I woke up this morning needing a pep talk. With no Knute Rockne there nor drill sergeant, I turned to myself for some inspiration. I didn't exactly find a Rockne speech in me. I was able to remind myself that our current situation is not normal, nor is it the "new normal". The current situation is not normal, yet we try as try might to seek "normal". For work, even though people are all working remotely, even though they are all dealing with their personal issues regarding dealing with the virus, we are still asking teams to deliver as if things are normal.

So I reminded myself that this is not the new normal and thought I'd pass on that message to my team at work. I also thought I'd try and enhance my inspirational message with some historical inspiration. Where in time, besides the oft-cited Spanish Flue Pandemic, were people cooped up for months at a time. Valley Forge came to mind. They were cooped up there for an entire winter, right? That must have been like three whole months, right? 

So, like I do, I looked up what I could about Valley Forge. They weren't there three months. The Continental Army was camped out there for six months! Dec. 19, 1777 - June 19, 1778. Okay, granted, they could leave their huts -- And it's a good thing they could since an entire squad of twelve enlisted soldiers typically shared a stone hut, sometimes with wives and children as well. Also, the winter wasn't as bad then as we were made to believe in elementary school. (Apparently the winter encampment two years later in Jockey Hollow was much worse and was the root for the myth of the horrible Valley Forge winter.) Still they suffered typhus, typhoid fever, dysentery, influenza, pneumonia, and smallpox (because a group of the soldiers had not been inoculated the year before when General Washington ordered it), not to mention the starvation. (Yesterday, I ordered DoorDash from one of the local Mexican restaurants.) About 1000 of the 12,000 soldiers encamped there did not survive the winter. About 8% mortality.

Anyway, it could be worse... I guess. It wasn't exactly the inspirational message that I was looking for, so I decided to play it. Plus, what did those men have to look forward to? America lost almost every major battle for the next several years until Nathanael Greene took the fight to the Southern theater. 

There is a battle to come for us, probably many. For Nordstrom there is going to be a much smaller pool of higher-end retail shoppers. We're going to be battling other retailers for those customers. For us as a nation there is going to be a battle of words over how and when to come out of this mess and get the economy going again. For many of us individually it is going to be a struggle just trying to get back to normal, to find jobs again, to restart some semblance of a social life, to just get back to a routine. One thing that I think this pandemic has shown us is that we accomplish much more when we can work together rather than apart. The phrase, "United we stand; divided we fall," comes to mind -- something to keep in mind.

Team John, part 2

Yesterday's post ended a bit abruptly while I had a lot more to say on the subject of Team John. The reason for this is a silly one, but this is just a silly blog, so I'll do with it however I will, including using run-on sentences as I feel like it: I am trying to get back to using 750words.com. It's a great site that simply tracks the number of words as you write them to encourage you to write at least 750 words each day. I'm picking this back up, as I have been reading Stephen King's marvelous "On Writing". King encourages people that want to write to start with at least 1000 words a day. Being more of an underachiever, I'm starting by going back to 750 each day. I'll have more to say on Mr. King and his book hopefully in coming days and weeks. The 750 word goal also works to make sure that I don't spend an inordinate amount of time writing drivel and sometimes even forces me to stop when I have more to say.

So I have more to say on Team John. In the previous post I talked a little about how we implemented it with the current team. Other than what I think were good ideas of tying it to our oncall schedule and having two developers on in a rolling fashion, it probably wasn't exactly helpful in understanding much beyond the message that I think Team John is a good idea for teams. I did hit on the primary purpose that Team John shields the team from interruptions and interruptions are very costly to teams. As an Agile, or more specifically a Lean practice the idea of why the Team John works goes beyond just funneling interruptions  away from the main development team and it goes to queuing theory.

Queuing theory is really the study of how queues or "waiting in lines" affects system throughput. As a study it was first used in telecommunications and then was adopted by Toyota in manufacturing and then came from there to software development through Lean teachings. As a practice it is as old as when people first began lining up to wait for something.It's helpful if you think about waiting in line at Wendy's or at the local grocery store. Will opening more registers help people waiting in line move faster? Yes, it will, but up to a point, right? I can open up four registers at Wendy's, but if I only have one person back on the grill, I can only move people as fast as burgers come off the grill. Or think about those videos you've seen of an automotive assembly line. The line moves along at a regular pace with each man or woman doing the job at their station. Highly repetitive, but also very precise - not only in the placement of each bolt but also in the time the entire task takes.

Applying just those two ideas, it's easy to see that the entire process can only move as fast as it's slowest component (we call that a bottleneck) and that a sustained pace is better than randomly throwing work at people. Like I said, these aren't new concepts but have been around at least as long as people have been waiting around for hamburgers. So how does Team John help the process?

First, when a Scrum team has planned out a sprint, they have planned an amount of work that is sustainable if they work a regular pace throughout the sprint. Unplanned work coming to a development team means a) it will be of some volume that the team couldn't previously deduce and b) it will have some deadline that the team couldn't previously expect (presumably sometime within that sprint, however). There is a rhythm to a sprint, particularly when a team has a sprint goal and is doing a similar group of repetitive tasks towards that goal. Unplanned work throws that cadence off kilter.

Secondly, Team John helps teams deal with those bottlenecks. That guy on the grill can become a bottleneck. If you picture the auto assembly line again, it's easy to see that the line can only move as fast as the slowest person working it. The other thing to realize, particularly in software development but also in fast food service, is that you can never completely predict how a relatively short run on the system will unfold. One hour I might have everyone order singles with cheese, a Frosty, and a small fries. The next I may have people each ordering custom orders ("Hold the ketchup, hold the pickles!"), one of a variety of beverages, and all wanting large fries. What if I have one or two people just waiting, ready to place toppings or fill beverages or put down more fries as needed? I wouldn't need to always anticipate exactly where those bottlenecks are going to be.

I probably have more on the subject, in fact I know I have more, but I'm at almost 850 words now and need to leave some for tomorrow.

Team John, part 1

I was introduced to Agile concepts around 2004 or 2005, primarily eXtreme Programming ideas from articles by Kent Beck and Ward Cunningham. Fairly shortly thereafter, 2007 or 2008, I attended my first Mile High Agile conference here in Denver. At either that first one, or possible the next year (my memory is starting to go), I was introduced to the very energetic V. Lee Henson and a number of his really great ideas in implementing Agile including the "Team John" concept. Briefly, a software development Team John is an engineer who works separately from the rest of the development team on bugs, production incidents that arise, work that comes in sideways last minute ("Hey, can you pull some numbers from the database for me?"), or tech debt. The idea is that developer works on all the other shit that isn't part of the team's sprint work that would otherwise lead to interruptions. The responsibility rotates to a new developer with a new week or sprint.

It seems counterintuitive that removing a developer from the mix would allow the rest of the team to go faster, but I think any development team that regular needs to deal with incidents or gets hit with work sideways, from outside the Scrum process will immediately see the value. Interruptions kill a developer's productivity. That loss in productivity is attributed to context switching: The very act of switching from one task to another results in a tremendous amount of lost productivity. Psychological research has shown that context switching can result in 40% productivity loss, and the more complex the tasks, the greater the loss. 

In his blog, Joel Spolsky, the creator of Trello and one of the founders of StackOverflow, puts it this way, "The trick here is that when you manage programmers, specifically, task switches take a really, really, really long time. That’s because programming is the kind of task where you have to keep a lot of things in your head at once. The more things you remember at once, the more productive you are at programming." Spolsky goes on to sum up, "In fact, the real lesson from all this is that you should never let people work on more than one thing at once."

The primary purpose of Team John is to shield the team from interruptions or at the very least funnel them all to a single person. With one of the teams I currently support we were getting a number of ad hoc requests coming into our sprints sideways, whether from our business partners ("Hey, can you get some numbers for us so that we can see how the latest campaign is working?"), or elsewhere within the technology department ("These three servers have critical updates and need to be patched by Friday"), or from within our own group ("This service is causing alerts. Does anyone even know what it does?"). Then you had production bugs and incidents which had to be addressed right away and suddenly we would have three developers dropping what they were doing to look at a single bug. I brought up the idea of using the Team John concept - we already  had an oncall rotation for who would handle incidents outside of business hours. We decided whomever was oncall would also handle the interruptions that arose day-to-day. They could work on regular sprint work if there were no interruptions, but at least each individual developer wasn't being pulled away almost hourly.

We quickly discovered that there was a lot of Team John work once we all started funneling it to a single person. Not enough work to keep that one developer busy the entire time, thankfully there weren't that many bugs and incidents, but enough that they really ended up contributing very little on the actual sprint. Meanwhile the rest of the team was able to accomplish more work that it had in previous sprints. I think there were six or seven developers on the team at the team. By taking one out of the mix to handle interruptions our velocity increased by roughly 15%. 

Rather than have Team John work on sprint work intermittently, we had the developer begin to pick up some of the technical debt we had accumulated and try to pay that down in between other interruptions. As we began doing that, some Team John work would carry over to the next week (our oncall schedule rotates weekly) leaving the next person in the rotation without much context for what was being worked on. After a while, and after adding a couple more developers, we decided that both the primary and secondary, which was always the previous week's primary, oncall developers would both be on Team John. This way as the primary rolled over to be secondary, they could bring the new primary up to speed on what was being worked on. With the addition of the second developer on Team John I don't believe the velocity increased, but it definitely did not decrease.

Why You Shouldn't Point Tech Debt, Take 2

I want to expand on not pointing technical debt stories. As I finished the last blog post, I realized that I had made the presumption that teams should only assign story points to stories based on business value. Then I proceeded to basically lay out the argument for why a team should (or in some cases should not) pay down their technical debt, kind of skirting the entire question of what not assign points in the first place. A classic case of begging the question: We only point things that are valuable because they are things that are valuable. If you already have bought into that statement, you wouldn't be here asking the question of whether to point tech. debt or not.

So now I want to back the premise that a team should only point work that is of value to the business. One of the developers I support is a fan of both metaphors and the NBA, so I would like to present my argument in these terms: When you watch a basketball game rebounds, assists, steals, and turnovers are all very important to the teams. However, at the end of forty minutes, the one stat that matters is how many points each team scored. Just like having a lot of turnovers will hurt a team's chances to win, technical debt is going to drag down your development's ability to deliver new features. In the end, however, the business runs on the value of the features the team delivers.

I mentioned previously that a team may look to distinguish between technical debt points and business value and still somehow combine those to estimate output. I don't believe that this is really an apples-to-apples comparison, however. Some technical debt MUST be addressed and some subset MUST be addressed IMMEDIATELY (particularly if bugs and incidents fall into that technical debt bucket). For example, our organization recently moved its package management from a Nexus repository to Artifactory. Every development team had to change projects to point to Artifactory. No value was delivered to the customer, but this had to be done by a set deadline else project build pipelines would cease to work. We also have contractual obligations for SOC 2 and PCI compliance driven by hard deadlines. Managing API keys and updating network diagrams does not deliver value to our customers but must be done and must be done by particular dates. If that date is a couple years off the tradeoff with choosing to bring in business value may be relatively small. That cost increases, however, as the deadline approaches.

Another thing that makes estimations of technical debt unequal to estimating business value is that technical debt, in my opinion, is generally more difficult to accurately estimate. I say this because if it were easy to accurately assess the risk, effort, and value of paying down debt that teams would actively engage it rather than accumulating it. I believe technical debt accumulates, in most cases, precisely because we find it difficult to assess risk, effort and payoff. "If it were easy, we'd have done it." I know me saying this is my own opinion based on experience and that in some cases teams know exactly the risk and effort and the value simply isn't worth addressing the debt. That said, this is one more reason why, in my experience, I do not believe teams should point technical debt. To extend my metaphor further - a made basket in basketball is worth a set number of points: one for a free throw, two for a standard field goal, and three for those beyond the three point line. A steal, like paying off technical debt, may result in points, and it may not. A coach can't tell his team, "If you get this many steals we are sure to win the game." He can look Jimmy Chitwood in the eye though and say, "Jimmy, if you come off the picket fence and make this shot, we win the game." (That isn't exactly how it happens in "Hoosiers" and I realize I've taken this too far, but I can't get this far into a basketball metaphor and not bring up one of the greatest sports films ever made.)

A final reason why I do not see technical debt and business value estimates to be equivalent is that a team can timebox paying down technical debt. For user stories delivering business value there is some discrete level of effort involved in delivering that value. Generally a user story that is 80% done will deliver 0% of its value. (This in itself is probably another blog post regarding the INVEST model for writing user stories.) Paying down technical debt can be timeboxed, though. I could devote half of a sprint to moving my package management to Artifactory. That's not the same as being able to say how much I am delivering, only the time invested. Perhaps I will get two projects done, perhaps it will be ten - I know how long it will take and how much it is affecting the team's velocity in delivering business value, but not how much it will ultimately benefit the team internally. Still, it's perfectly fine to timebox addressing tech debt, whereas it generally is not with user stories.

Ultimately the business is requesting an estimate on when valuable code will be delivered to production. This is kept simple if your user point estimates correspond to business value delivered and technical debt is not pointed. It becomes an exercise in Sabremetrics if you insist on pointing technical debt as you do business value.

Why You Shouldn't Point Tech Debt

Let's suppose we have a team that does 20 points of work per sprint, but a tenth of that work (2 points) would wind up as technical debt. So, if our hypothetical team wanted to accumulate no debt, they could deliver 18 points of business value, paying off the two points of potential debt, just like paying off your credit card in full at the end of each month.

We could also have our hypothetical team deliver the full sprint of work toward business value and choose to carry the debt into the next sprint. (Of course, we will ultimately fall somewhere between the two hypotheticals, paying down debt as the opportunity arises, carrying it when the friction it causes is relatively less than the business value being delivered. Humor me, though.) So with the first sprint we deliver 20 points and carry two points of debt into the next sprint. The thing we know about debt is that it comes with a price, interest charges! For the sake of argument, let's say our team is paying Lucky Luciano type rates on their interest so that every two points of debt costs us a point of work each sprint due to the friction it causes.

(Tech debt is like sand in the gears of your development process. It will cause things to move slower and slower until development grinds to a halt completely. Of course it works slowly over time, and the interest you pay on it is much lower than 50% per sprint. However, a system of any size that has been around for any length of time has accumulated much more than a tenth of a sprint's worth of debt. Your dev. team could probably work a couple months right now on nothing but technical debt.)

But back to our hypothetical --

So now, in the second sprint, our team can accomplish 19 points of value and accumulate two more points of debt. In the third sprint they are going to do 18 points, just as if they had been paying the debt with each sprint, but now they are six points worth of debt. Of course, in the fourth sprint the debt has caught up on our team: They begin doing less as if they had been paying it off with each sprint, and it will spiral down from there.

When this becomes a big deal is when the business comes to the team and says they would like to add 90 more points to the system and wants the team to estimate how long that work will take. In the first scenario the team can relatively confidently say the work will take exactly five sprints. (Amazing how that worked out to be exactly divisible by 18!) In the second scenario the estimate would depend on where the team was with their debt. A completely greenfield solution would take five sprints, yes, with an accumulated debt of about another half a sprint. If the team couldn't start greenfield, though, it could be six, seven, eight... sprints. While in the first scenario, it would be five sprints regardless of what point the team began developing.

So comparing the team to itself in the two separate scenarios (because we'd never compare velocity of different teams as apples-to-apples, right?), it is not accurate nor fair to say they are delivering the same amount of value in both cases. With an effort lasting fewer than five sprints they will deliver more in the second scenario, delivering value and accumulating debt. More than five sprints and they deliver more by paying down debt every time.

Now suppose another scenario where our team has accumulated 20 points worth of tech debt. Rather than deliver only ten points of value with the next sprint, they choose to take the hit and pay off the debt, delivering no business value. On the next sprint, however, they are back to delivering 18 points of value (accounting, once again, for immediately taking care of any debt). After the third sprint they've delivered 36 points of value compared to what would only be 27 if they continued stumbling carrying the debt. We can measure the difference in value, nine points after 3 sprints, being delivered by the decision to pay off the debt. If we measure debt and business value the same way, that comparison won't be made. It isn't that the comparison can't be made -- And I realized that as I wrote this post. With some bending over backwards while jumping through hoops and some algorithms written in python, comparisons using tech debt pointed as stories could be made. In my next post, though, I will argue why a comparison like that probably won't be made and shouldn't be made.