Hard Battles

I had posted the following on LinkedIn, thus the focus on work, but thought I might share it here too:

"Be kind, for everyone you meet is fighting a hard battle."

I have been reminded of that quote often in the past several days. It has come up in several completely unrelated contexts. Maybe I am just more attuned to hearing it at the moment. (Apparently, there is a bit of argument as to who said it first, which is why I did not attribute it here.)

We are all fighting hard battles, and, though I know it is difficult to believe, not all of those battles are going on at work. There are people every day who were up with a sick child all night or have some financial worry or struggling with mental health issues, who wake up and put on a happy face and come to work to deal with relatively minor issues if only to take their minds off the very heavy battles they left at home.

I am reading When Breath Becomes Air right now and amazed that someone, a doctor, knowing his time left on earth is not being counted in months decides that he is going to go back to work. I wonder what his patients thought, maybe not knowing the courage their surgeon had in even showing up that morning. "Wow! Doc looks awful!"

I especially have a lot of sympathy for those working in customer service or other customer-facing jobs. My wife is a flight attendant, and I know there are many who have to leave a sick child or spouse to leave on a three-day trip and deal with customers who have had their "lives ruined" because their flight was delayed a couple hours and now they are going to be late to the bachelor party.

Some of your coworkers, some of your vendors, the person making your Subway sandwich at lunch -- they left the heavy battles at home today. So be kind to each other.

Leonardo and Any Ideas for Collaboration?

I am currently reading the biography of Leonardo Da Vinci by Walter Isaacson. What I really find interesting about Leonardo is how much he collaborated with others and how much he sought out knowledge from others to bolster his own knowledge gained through astute observation. We tend to think of Leonardo as this divinely inspired genius who just had this innate talent for learning everything and being a master at anything he tried. He certainly was a genius, and he had incredible God-given talents. However, he sought out knowledge, he sought to quench an inexhaustible curiosity by studying the works of others, directly interviewing craftsmen and other artists, and through direct collaboration with other people many of whom knew quite a bit more than he in their respective fields. Apparently Leonardo wasn't all that great at math, especially algebra and trigonometry. (Granted Europeans generally didn't know much about trigonometry in Leonardo's time.) He failed to teach himself Latin. Duolingo wasn't widely available then either. He did, however, possess a gift for greatly raising the bar when building upon the works of others.

I was really struck by the story of the Vitruvian Man drawing. You know the one: muscular naked guy circumscribed by a circle and boxed in by a perfect square demonstrating the proportions of the human body. A little aside: it's likely that Leonardo was his own model for this, and muscular naked guy is a beardless, fit Leonardo. Or at least a close likeness. Vitruvius was a first century Roman general and architect who in describing how to build buildings said that the Romans should use human proportions as ratios for how wide and tall and deep things should be. Then he laid out what those proportions should be. Things like a man's armspan is the same as his height and his foot is exactly one-sixth of his height. Leonardo and his amigos began talking about this when they were coming up with diagrams for a church, and they all took a swing at drawing Vitruvian man. Leonardo's made the others look like grade schoolers' by comparison. It was the collaboration that struck me, though. One of his other compadres put the circle offset from the square, which is something Leonardo then copied. Isaacson also wrote the biography of Steve Jobs and said that collaboration was the reason that Jobs had open areas built into the offices at Apple.

I thought about that in relation to the virtual workspace we are in now. One thing I really missed about going into the office during the pandemic was the conversation that was had outside of meetings. I missed overhearing a couple colleagues talking about some proposed solution and either being able to contribute myself or just listen in to follow some new train of thought. I missed ad hoc whiteboarding in the hallways of proposed solutions. Reading about Leonardo and how he learned and evolved his ideas with input from so many different people reminded me of this excellent keynote given by Jessica Kerr on symmathesy. Interestingly it was also focused on Florentines, just about a century after Leonardo was doing his thing.

What are we doing or what can be done to bring great minds (or even good or average minds) together to collaborate like this in today's age of working remotely from home? Why do we get enraged that Elon Musk wants his workforce back in the office? My money says Steve Jobs would have done the same thing. Don't get me wrong! I am a big proponent of working from the beach! How do we get that same collaboration without requiring everyone to be in office, though?

On Failure

I wrote a long journal entry yesterday about my feelings being laid off from Nordstrom. It was fueled by a LinkedIn post related to the mass tech layoffs that occurred recently particularly the ones by Twitter and Meta, in which the author said, If you've been laid-off, realize that is a failure of the company you were working for, not you. It made me think of Robin Williams as the therapist in "Good Will Hunting" telling Will, "It's not your fault. It's not your fault." I must have watched that clip two-dozen times in the days following being laid off in an effort to make myself believe it wasn't my fault the way things ended there. I am just beginning now to really believe that.

Without going into the details I did in the blog post, I am realizing that what led me to being let go after almost seven years of doing the best I could do in that job, was not my fault at all. If you know me at all, you know I read a lot. (My brother argues that listening to audiobooks shouldn't count towards my book count, but he's wrong.) I read everything I can get my hands on including a lot of managerial-type books, and I had realized before that what was going on within my organization at Nordstrom contradicted so much of what I read, even those books that my vice president herself had given us to read. You can't tout radical candor, which according to the author of Radical Candor, Kim Scott, is equal parts "Challenge Directly" and "Care Personally", if you avoid any sort of direct challenge and do not care personally for those you support. In his book Drive, Daniel Pink lays out the three elements of drive, of personal motivation: autonomy, mastery, and purpose. If you give your subordinates no autonomy, no chance at any sort of mastery in their work, and provide no vision, no purpose for the work is it any wonder that they might feel disengaged from that work?

When I was let go I initially felt like the biggest failure. My self-esteem was already not good and had been further ground down by months of doing all I could to keep projects on track and keep improving while my team was slashed in half and never receiving any sort of encouragement from my superiors. I also did not have the tools for self-compassion and was not using the tools I had learned previously to help deal with the situation. That was a tough lesson for me and one I will not need to learn again.

Some company is going to give me that shot, is going to give me that autonomy, allow me opportunities and encourage me to master my skills, and provide a clear purpose for the work we do. And I'm going to do incredible things for that company and for the team I get to work with.

Check on Your Managers! We are Not Okay!

In dealing with my current issues I have had to turn to my social support system, the friends and family who love me and care about me. I can barely get out of bed in the morning let alone schedule doctor's appointments and job interviews and get myself to therapy. I've been really encouraged, though, by the people who have reached out, and I want to turn a sad story into a success story.

As I think I this support system what stands out is how much I have isolated myself over the past several years. It certainly is no coincidence that this corresponds to the Covid pandemic and working from home. However, I think it began even earlier when I moved into a management role. I feel like the manager role can intrinsically be a lonely one if measures are not taken. As I said in an earlier post, I believe the measures are there in work I have already done in therapy and in DBT, but they can be easily forgotten if not regularly practiced. I intend to write more here about those DBT skills and how they relate to work in order to do my own practice of them and maybe to help some others out there.

I was thinking on how I have not made new friends in several years. When I was out drinking and carousing with my engineering peers, it was easier to get past my own social anxiety, have fun, and make friends. Some of those friendships even stuck. When I moved into a management role, though, I certainly was not going to do any carousing, and I really limited how much drinking I would do, already knowing my propensity to overindulge at times. I did not want anyone I supported to see me inebriated. It became even more difficult when I gave up drinking as I could not get past the social anxiety enough to open up to people. 

Now I know all other managers out there are not depressive alcoholics with severe social anxiety, but I do believe that in that manager role you have fewer work peers and those peers you do have are incredibly busy. I think back on the halcyon days of playing foosball or ping-pong at work! Now, no one has that kind of time anymore even when we were still all in the office. I regret now not reaching out to my manager peers at Nordstrom socially more.

I will also say, it was nice, especially in an environment where I was getting no feedback back from my boss, to hear from someone I was supporting as a manager, "Hey, I know it can be a rough job, but I think you're doing a great job." My team and those people I worked with every day - those are the people who knew what kind of job I did and that feedback was very motivating, inspiring. 

So, today's lesson is if your manager is doing a good job, let them know it. It can otherwise be a very thankless job at times. Despite the provocative title, your manager is probably really okay but will appreciate it nonetheless.

Kanban, an Interlude

I was interviewing a candidate from a large, well-known online retailer yesterday, and we were discussing the development process he uses in his current job. Like most candidates I speak with, his organization uses a form of Scrumbut. "Scrum, but we sometimes the sprints are two weeks long and sometimes they are four. Or "Scrum, but we use developer days instead of points." Or, most egregious of all, "Scrum, but we don't do retrospectives." (That constitutes a blog post all its own.) At Nordstrom we do Scrum but don't have dedicated ScrumMasters. I think that is becoming more and more typical (Also a topic for another post.) and has been this particular candidate's experience as well.

I asked about Kanban. "Oh, we tried that when I first started. It didn't really catch on." Why did he think that was? "I'm not really sure. People just didn't see the value in it." Were there WIP limits (limits to the amount of work in progress)? He didn't think so. So, no. Were there explicit policies that defined when tasks moved from one status to another? Not explicit ones. Then it was really no wonder they got no value from the kanban process. That's not to pick on this big e-tailer either. One of my own teams at Nordstrom is facing that same challenge, and it isn't something one changes overnight.

I have seen at least several interesting origin stories of kanban from the Imperial Gardens in Tokyo to a visit to a PigglyWiggly in the United States. Most everyone agrees, though, that its use as a form of development practice began with developing automobiles at Toyota in the 1950's. As line workers reached the end of their parts inventory, they sent a bin to a backroom along with a card signaling just what part and how many were needed for the worker to keep a sustainable pace of work. Two foundational pieces of kanban as a software development process were born then: that kanban is a "pull process" where the worker is pulling just what they need rather than having parts pushed to them, and that the work is limited to just what the worker can accomplish. In doing so, Toyota eliminated waste associated with a worker having too much of one part and not enough of another, workers waiting around for needed parts, and workers spending too much time restocking unneeded parts.

A key principle of Agile software development is promoting a sustainable work pace. Limiting the amount of work coming into the pipeline to only the amount of work that can be worked on at any given time is optimal. I could go into an explanation of Little's Law here, but anyone who has been in a traffic jam with seemingly no reason other than the sheer volume of cars on the highway knows that by forcing even more cars onto the highway people are not going to get anywhere sooner. Unfortunately many businesses feel like things will go faster if they just add more cars so long as those cars are all laying on their horns. "But THIS one is HIGH priority!" Or the dreaded, "What if we added more people?" Yes, because what would really help this evening commute to move along is to bring in the dump trucks, excavators, and graders to begin adding lanes at this very moment.

A WIP limit in kanban is meant to allow just as many cars onto the highway as the highway can currently support. Without it, we just end up with traffic jams of in-progress items. It also limits a developer's context switching. It's been shown that switching between even similar tasks is wasteful. Switching contexts for a developer not only means getting in the right frame of mind to tackle an issue, but perhaps even switching IDE's, logging into various tools, perhaps even switching machines. Developers sometimes containerize complete work environments in Docker for the purpose of making switching contexts easier. We know that even small changes though are extremely wasteful. Limit the developers to working on one item, perhaps two at most, and a good deal of that waste is eliminated.

Then there are the explicit policies of how work flows through the system. These process policies are key to eliminating waste around confusion as to what should be worked on when. Going back to our traffic analogy: Imagine driving along roads with no traffic signals and no street signs. You will hopefully still get to where you are going, but needing to stop and assess the intentions of others at every single intersection will make the journey much more hazardous and take much longer. Kanban, being an Agile process, doesn't prescribe the rules of how work flows through, but allows for the development team to do this themselves. What kanban does say, however, is that the rules of the road must be explicit and transparent to the team. It does the team no good if someone needs to clarify the meaning of some policy in order to move work along just as it makes no sense for us as drivers to need to look up the meaning of different colored traffic lights each time we come to an intersection.

It is also important that each team decides for itself the policies that work best for the work they are doing and their interactions with each other. Agile practices acknowledge that each team is more or less different in what they work on and how they work. I believe that particularly as we move to doing more remote collaboration, make these policies explicit and visible to the team becomes more important as does allowing the team to tailor the policies to the way they wish to work.

Kanban can be a real benefit to development teams, but just as driving a car entails much more than just knowing that one pedal makes you go and the other makes you stop, there is much more to the kanban practice than simply a kanban board.

Pros and Cons

I wrote the following as a LinkedIn Article, but I think the idea serves for anyone who uses lists of pros and cons to make a decision.

Yesterday I needed to work through one of those tough managerial decisions that occasionally come up. As an engineering manager most of the managerial decisions are relatively easy to make. There are Nordstrom engineering standards, compliance standards, and many best practices for most of what the developers do. The most difficult part of those decisions is really just keeping up with the standards and practices.

The people management decisions are made using a mix of sympathy or empathy given the situation, past experience, and for me, having a background in psychology. Some of that can be learned, but I think the key is empathy: Put yourself into the position of the employee you are supporting and ask yourself how you would like to be treated in that situation.

I'm going astray from my purpose for writing this, which concerns making those difficult decisions as a manager. I've learned a practice that you all are probably familiar with to help make decisions like these, though with an added element: a Pros and Cons list.

Typically when we use a list of Pros and Cons to making the decision, we use the viewpoint of making a change in the status quo and the effects, positive and negative, that change has on our situation. What we don't typically do is also evaluate not making a change or even not making a decision at all and leaving the status quo. Adding that element to this practice has made creating a Pros and Cons list much more valuable to me in decision making.

I'll use a personal decision rather than a managerial decision as an example: Having bought our condo in Cape Canaveral, I was weighing driving my car to have and use down there versus continuing to Uber to and from the airport there or renting a car when we are there. I made a Pros and Cons list beginning with the positives and negatives of having a car in Florida, including the initial act of driving it down there. On the negative side, it was a very long drive down there. On the positive side, that drive down got me an opportunity to see a good deal of country I haven't seen or don't often see including seeing my cousin in Nashville. (It also meant seeing a lot of Kansas, which I'm not sure quite fit into the assets column.) On the plus side, we would save money. Even renting monthly parking down there, with Jen being an airline employee, was cheaper than a one-way Uber from the Orlando airport to Cape Canaveral. On the negative side it left us with one fewer car here in Colorado, particularly a car for the snow, as we would just have the Rogue and the Camaro.

That's how we all typically do a Pros and Cons list. Then, though, I added the additional perspective of what were the advantages and disadvantages to NOT driving my car down. Some of these were merely the opposite of the first list. We would spend more money when we went to Florida Ubering or renting a car. I would not get to need to make a long drive, but I would also not get to see the middle of Kansas. Then a thought struck me: by leaving the car in Colorado it wouldn't be subject to the salt air of Florida and save some life of the car. Being exposed to salt air is really a negative of taking the car down, but I hadn't thought of it at the time. The different perspective brought that out. Maybe it was that I was geared to see the benefits of a situation more than seeing the disadvantages. Sometimes having that different perspective can help you see that there are more disadvantages to a change or advantages to not making a change than you saw at first. Or perhaps vice-versa if you are more inclined to see the negatives in a situation. 

Ultimately I chose to make the drive down and leave the car. I could always change my mind later and drive back to see how Kansas had progressed in the interim. I'm happy to say that so far the decision to take the car down has been a good one.

There are a lot of managerial decisions I could use the practice on as well. Is this employee best to work on this new system or better off where they are? Does it make sense to update this version of the database now or leave it as is? Should we deploy this new software version in this sprint or do more testing? Put yourself into each situation you are considering and make a list of positives and negatives for each situation in order to gain perspective on your decision.

I've Never Been to the Galapagos

 I just got done with an inspiring Leadership Open Space virtual conference with my colleagues at Nordstrom. One of the topics that came up is How do we continue or transfer the Nordstrom culture to a new working environment post-pandemic?

Nordstrom has a culture that in my view is heavily influenced by two principles. First, if you know or have read anything about Nordstrom culture and certainly if you are one of our loyal customers, you know that Nordstrom culture starts with how we treat our customers in the store. Our store employees are truly customer obsessed. The second principle is that as large as Nordstrom is, it is still a family business. The Nordstroms sit on the board, are key stockholders, and hold chief officer roles. More than that, though, they have a genuine care for us as employees just as when their great-grandfather began the store. My first meeting as a Nordstrom manager was with all the other engineering managers, over 200 of us, in a ballroom in the Four Seasons in Seattle overlooking the sound. Blake Nordstrom reminisced about how that meeting had been previously held as a barbecue at his home and lamented a bit that it couldn't still be that way. (The Four Seasons doesn't suck, though.)

Like other corporations, Nordstrom is beginning to think about what the workplace will look like post-pandemic. I believe it is certain to say that we are not all going back to our prairie dog villages of cubicles in big office buildings. As a manager, I am looking to fill open developer positions and am not just looking local to Denver here. I already support contractors in every timezone in the U.S. not to mention in India, and don't see a reason to change that. My belief is that many companies will adopt some sort of hybrid solution with employees "hot desking" (a number of employees co-sharing a group of desks) and making use of conference rooms for meetings where collaboration is especially effective, but otherwise working remotely. 

Like I said, Nordstrom has a very specific culture. A culture unlike other places I've worked. With our group being in Denver and Nordstrom HQ in Seattle, we used to have engineers go out to Seattle almost expressly so they could get a better sense of what the Nordstrom corporate culture is. Now that kind of travel is no more, and likely won't be again. Plus  with even many in Seattle contemplating working remotely and with us finding tech talent in other areas of the country, the question put forward today was, how do we continue that culture in the future? We had a breakout session on this topic, and after 45 minutes the surprising answer I think we came to is "We don't." We don't continue this same culture; we evolve it. We keep what is good, we throw out what just won't work anymore, and we evolve the rest to fit our new environment.

I sort of joked with my Seattle counterparts that part of the Nordstrom culture, being an outsider from a corporate perspective, is wandering around downtown Seattle trying to figure out in which building you are supposed to be meeting someone. The buildings are One, 805, 864, and 865. One is easy: That's the flagship store and there are offices above that. 805, 864, and 865 are not addresses. Those are "store numbers" as well. You would think that at the very least 864 would be next to 865, but you would be wrong! 865 is next to 805, and 804 is a good fifteen minute walk away. (Twenty if you are going in the other direction because it is uphill!) I mean, how are we ever going to replicate that sense of frustration that every Nordstrom employee must have realizing they are in the wrong building for a meeting starting NOW?!

I think we go back to the essence and the principles that made Blake wish he could invite us all back to his place. We start with being customer obsessed. As internal service providers and as people managers we recognize that being customer obsessed means being obsessed with making sure that our store employees can do their very best job and that our digital storefront performs its very best. Then we continue to treat each other as family as we've tried to manage staying close to our own families through this time. We get creative in including them even when we can't all be together. We take time out to check in on each other. We recognize that sometimes we are just going to have some bad days, and that is okay. 

There WILL be a new environment coming whether it is this summer or fall and we need to evolve with that changing environment.

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.

"How can I make my company realize that they are NOT agile?"

I just got an email from a company called agile42 that I talked with at Mile High Agile. I was really just looking for a good place to save this for my own use, but figerd that agile42 wouldn't mind if I gave them some free advertising by sharing it here.

Q: How can I make my company realize that they are NOT agile when they say they are?

agile42 Insight:
This is a great question and one we often get from the community. If a company is saying "We're all good, we're agile now!", it likely means they're looking at it as a binary measure - that they simply areor are not agile. In this case, convincing someone that they are not something they claim to beis difficult, because it feels like failure. Instead, we prefer to think of it like a spectrum. Some might think of it as a journey and most organizations are somewhere between "We need to get started" and "We've reached our destination".

One way to have this conversation at any level of the organization is to have people reflect on the 12 Agile Principles and then rank them in order of how strongly they are living them.

1. First, select the top 3 strongest and bottom 3 weakest.
2. Next, go through the 3 strongest principles and identify two or three concrete things the organization does that makes them good at those principles.
3. Finally, go through the weakest 3 (opportunities for improvement if you'd like a less negative connotation). Identify two or three concrete things that might improve these principles.

• Through this method, you get a list of improvements that either shore up weak spots or double down on strengths - either way, they all make your company more agile!

Empathy

In so much of what I've read from the Dalai Lama, he preaches time and time again that we must have empathy for our fellow humans. Empathy brings us closer to others, it leads to compassion, and, not to get all Buddhist on you but, helps to end suffering. In non-Buddhist terms, having empathy for other people makes us and them happier.

I need to be better about this in practice in so many areas in my life, but especially right now at work. I've certainly not hidden that I am irritated with my job and there are days I am flat-out angry. (Full disclosure, there have been more days recently when I've been able to put aside the irritants and focus on what I like about it, which is solving problems to help people vote.) When I get angry and irritated, however, I've been bad about putting my co-workers in the line of fire. Generally, it shows in passive-aggressive behavior by me, which I don't even realize I'm doing. There have been a handful of embarrassing moments when that aggressive behavior isn't so passive. Even a couple times where I was yelling full-voiced at a co-worker without even really realizing it.

My co-workers are definitely not the issue I have with work. I think that to a person the people I work with are all underpaid and underappreciated by "the powers that be" for what we do. We grouse about it, and sometimes I grouse louder than others, but it isn't like we are underpaid like our nation's teachers are underpaid. Maybe I just speak for myself, but I think it is the underappreciated part of the equation that is worse than the underpaid part.

With the people I work with both day-to-day and only occasionally what I've come to realize is that every one of us is trying our best. Okay, maybe we're not at our best every moment of every day because humans just can't be (except for Meryl Davis and Charlie White. I mean, am I right? They're like robots on the ice.). When I take a step back and acknowledge that everyone else around me is really working just the best they can as am I, how can I fault that? Programming voting machines and election software for U.S. elections is hard work. I mean, it's no putting a man on Mars hard or cracking Verizon wireless encryption so that the NSA can listen in on your phone calls hard, but it ain't easy, Sally. There are a lot of people that I work with that are very good at what they do and care about what they do, and I need to have more empathy for them and forget my own issues at times.

I was reminded of this tonight. At about 4:30 PM MST that call came in. You know the one: "I have a demonstration to the some of the largest counties in California tomorrow, and I can't get the software to work. Can I talk to a developer there?" Of course none of us really WANTED to take that call. I won't go into the specifics why other than to say it was 4:30PM already. However, I was in the same boat last month. I was supposed to do a demonstration to the State of Florida and the test project that I was given didn't work. One of my colleagues in Belgrade stepped up and worked, on Christmas (maybe the day after) I believe (since they celebrate Orthodox Christmas), to get me what I needed. I knew how stressed I was then, so volunteered to help with today's predicament.

Listen, I may have stepped up and volunteered, but I won't say that I did it cheerfully. There may have been some choice words thrown in. Putting myself in that guy's shoes though, I couldn't just walk away and say, Not my problem. When you have empathy for someone, that person's problems become your problems too. The good thing is that having two people to work on a problem is much better than one struggling through it themself. The issue turned out to be a series of relatively minor things, and we got things squared away. My colleague in California was grateful that he wasn't going to be tarred and feathered by the State of California, and I actually appreciated being able to re-familiarize myself with a couple parts of our system I hadn't used in a while.