Thursday, June 19, 2014

I was stuck at the airport for 14 hours

What follows is an email I sent to James Crites, the VP of Operations at Dallas Fort Worth airport.  If it seems stupid or cranky, please note that I wrote it when I was both stressed out and sleep know, about half an hour ago.

I believe that problems this severe should make their way to the top, so I'm notifying you personally.

Let me preface this by telling you that what I experienced is commonplace.  It is so common that one of  the customer service managers said that he called his wife to tell her he wouldn't be home hours before the incident occurred because he knew it would happen.  Additionally, another person among the group waiting established that she had encountered this exact same scenario at DFW only 5 days earlier.  Naturally, she blamed the airport.

First, the airline screwed up.  They under-staffed themselves, and when inclement weather hit DFW airport, they were unable to retain enough pilots to get their flights out on time.  Following that, they chose to rectify the situation by telling us to wait 12 hours until the next morning for re-booked flights.  Naturally, since this was blamed on the weather, there was no compensation for anyone.

Then the customer service representatives screwed up.  Everyone who was not in first class was booked on standby for a flight the next morning.  Surely, being put on standby and not getting onto a flight for another day would only create greater fury from the customers.  I know this bit was the airline again, but the staff is representing your airport poorly and I thought you should know.  This poor representation included a representative yelling at a customer (which is to be expected this late and with this much stress).

Then the staff of DFW screwed up.  In order to accommodate the large crowd, they called in several local deputies to ensure that the crowd did not turn into a mob. Then they secured a number of Coleman camping cots and told the angry customers to either accept those sleeping conditions or find a hotel and pay for it out of pocket.  The quantity of cots was nowhere near the number of people waiting.

Then the management of DFW screwed up. Given the limited accommodations, and the almost certain repercussions for running off with these priceless cots, we were all forced to remain centralized in the D terminal between gates 24 and 20.  As you should be aware, this part of your terminal is under heavy construction.  No effort was made to deal with the heavy amount of dust or noise that continued to choke and keep us awake the whole evening.

Now, I am young, under 30.  I'm healthy enough to deal with this sort of treatment.  Many people on this flight (and the several other flights that were included in this debacle) are not so young and healthy.  Many older people struggled to get in and out of the cots without hurting themselves.  I watched an inebriated man waiting in line for the re-booking of flights slip and smash his head open on the floor.  It was late at night, and much of the staff was tied up in re-booking, so it was a long time before anyone other than those of us in line were able to help him as he bled all over the terminal floor, still conscious but no doubt in need of stitches.

The staff was kind enough to come by at approximately midnight (about 6 hours into our wait) and provide us with some nature's valley crunch bars and a bottle of water each.  As you can imagine, being confined to an airport where all of the stores are closed limited our options for food.  I did not notice anyone having issues with diabetes, but I'm sure you know how dangerous that might have been.

I will not take up any more of your time.  I just thought you should be informed.

Update: James replied to my email.  This is what he sent:

Mr. Winslow,

I first want to apologize to you on behalf of DFW International Airport for yours and your fellow passengers unacceptable experience that night. I also want to sincerely thank you for your email, a Such correspondence provides information that enables those who are not directly involved in a specific situation to gain some understanding from those who were directly involved such as yourself.

Secondly, we strive to properly accommodate stranded passengers, and satisfy their needs, and it would appear we were unable to accomplish that. As such, the information you provide is something we can use to remedy are shortcomings.

All this being said, I will be sharing this email with my staff as well as the airlines and others who had a role to play in this situation, in order to implement corrective actions.


Jim Crites

Sent from my iPad

 UPDATE: The email chain continues, notice this is someone else

Hello Mr. Winslow,
My name is Paul Martinez, VP Operations at DFW Airport.  Jim Crites provided your below message to me, and as he noted, I’d also like to apologize for the poor experience you had during your recent travels through DFW Airport.
I am hoping you can provide details of your travel, such as date, airline and flight information.  We had severe weather Wednesday evening, June 18, that resulted in airline flight diversions and caused operational delays across the airport, however I’m not certain if this was your actual travel date.  Your flight details will assist me in working with my colleagues to understand the situation and with our efforts to improve our overall airport processes. 
Thank you again for your message.
Paul Martinez

I did not reply, so he sent another

Hello Mr. Winslow,
I just wanted to follow up on my message and see if you will be able to provide any further details regarding your travel experience through DFW.  We focus heavily on continuous learning and improvement, so your information will assist us toward this effort. 

Again, thank you for taking time for your message to DFW. 


Sent from my iPhone

I replied

Had to get this information from my partner as he booked the flights this time.   I did not include it because this is not a rare occurrence.
American Airlines flight 2318
Arrived 15 minutes late on June 18th
Flight 1386 was then cancelled at 9:45pm.  At 9:40 I went to the desk to ask if the flight was cancelled and was told "absolutely not "  and shortly thereafter ended up waiting in line for 4 hours.
We paid for first class tickets and were repeatedly treated like garbage in spite of our platinum level loyalty memberships.  And there are tons of others terrifying details I can provide like the cost of missing work the following morning or the couple in front of us in line who missed the cruise departure for their honeymoon with no attempt to refund them.
This is not something you should take lightly.

He replied

Hello Mr. Winslow,

Thank you again for providing the flight details and for sharing your experience while traveling through DFW during a weather event that negatively impacted operations.
We have reviewed our airport procedures and are working to shore up some internal communication to assist customers with hotel information during these types of irregular operations.
We also met with AA to review and discuss these types of operations.  While DFW Airport cannot directly address flights operated by our airline partners, we strongly believe in partnering with our airlines and work towards improving the experience for our customers.    

Again, thank you for sharing your information.

Paul Martinez  

Monday, June 16, 2014

Scrum/Agile and Doing it Right

Here are some things you can do to implement scrum more effectively around your workplace.
1. Explain it to your customers
   1a. Communication comes from your side to the customers, not the other way around
   1b: Code is still a process, and adding and removing features is not a simple task
   1c: Sprints are often enough communication
2. Sell it to your developers
   2a. Explain the good and the bad to them
   2b. Get them to like the idea before you move forward
3. Help your developers build a new workflow

Disclaimer: Let me start by saying that I am not some Scrum Trainer.  I am a developer who's been working with scrum for years.  I don't teach new teams how to do scrum, unless it happens to be my team ask for my guidance.  But I've worked at 6 different organizations who implement Scrum in one form or another, and so I have experience on my side.

Scrum is a hard transition.  It sounds easy, but I've yet to see a company get it together and follow all the (sometimes arbitrary) rules, in the last 5 years.  I see a lot of failures in scrum implementation, and since this is a software development blog (mostly) I figured I'd offer my perspective to try to help people to be more effective at using style.

Please note that I am a fan of scrum.  What I am presenting here is an honest perception and some realistic ways to improve the implementation of scrum where you work.  Please don't think I'm bashing scrum when I point out its flaws.  I believe it's important to see the flaws so we know what we need to focus on improving.  For this reason, I'm not going over obvious things, like using Kanban or Burndown.  These are the strengths of scrum and most companies are already using them well.  This post is about the weaknesses and how to alleviate them.

Scrum Definition

Scrum is a term from Rugby, a sport where punching people in the face is nearly mandatory.  A "scrum" is kind of like a huddle, where a team puts their heads together and plans their next play (more like after the huddle, but the same ideas apply).  That's why Scrum is called that.  The team is all equal, with everyone contributing their ideas--sometimes loudly--until a decision is made.  But the term is usually used in combination with the term Agile.  Note that this definition emphasizes two important things about Scrum, two of my favorite features.  All team members must be equal, but all teams must also have leadership.  Just like the quarterback can end a huddle and make the final say, or call an audible in a football game, we have to keep our teams focused on a singular objective, but from the same perspective, developers are all brilliant minds, and ignoring any one of them is a bad idea.

Agile Definition

Agile means flexible.  You're considered "agile" if you have a high dexterity and can do things like gymnastics.  In a company, you're agile if you can change at the drop of a hat.  The boss comes out of his office and announces that suddenly everything changed -- and you shrug it off because it may be 4pm on Friday, but you're agile  You'll be done with the changes at 4:30 and still out the door at 5.  So when we combine the terms, some companies actually use the words "Scrum Agile" like it's some sort of holy grail.  We're talking about a team, putting their heads together to make the next strategic play.  And we're talking about doing it often, and with as large a playbook as possible.

Programmers Are Not Agile

I'm sorry if that sounds mean, but it is simply true.  Programming is about wrapping your head around complex logic.  It takes some time spent sitting there staring at the screen just to get your brain open to the idea of changing it.  In the programming world, this is called "ramp up time".  Programmers simply are not agile.  If you throw some massive project at them at 4pm on Friday, they have 2 choices: work through the weekend, or go home and worry about it Monday.  There is no agile fix they can do.  Do not assume that implementing scrum or agile will somehow make your programmer's work faster or more flexibly or some silliness like that.  It simply is not how things work.

Teams Are Agile

Fortunately, scrum's major claim to fame is that it makes programmers more agile.  Because companies put teams of programmers on projects, scrum allows companies to leverage the inherent agility of the team around the fact that they're programmers and scrum effectively gives the illusion of agility to the programmers themselves.  Basically, because not every programmer is engrossed in a task at a given time, there appears to be flexibility in assigning tasks to the programmers because among the ten programmers, one of them will finish before the others and be able to start on the randomly inserted task.  This shows the customer that they don't have to wait for the whole team to finish, and their requests get done faster, which is the agility that we really see in a scrum environment.

Scrum Is a Sales Pitch

Let's face it, scrum is just another style.  The reason people are doing it is because it sounds better than the way they're doing things now.  In my opinion, it is better, but that doesn't make it anything more than another style for doing things.  The major problem with styles, is that not everyone likes them.  In education for example, teachers are told to teach in different styles for kinetic, visual, and auditory learners.  In management, it is much the same.  Different companies require different styles of management.  The argument for scrum is that it's the best management style for "programmers"-- so it is a specific use case, but that is also dependent on whether or not the programmers (and the managers) are SOLD on the way it works.  And the problem with sales pitches is that they're brief, and often miss important aspects.

Scrum Is for Managers, Not Programmers

As we've established, scrum is a management style, and therefore, it's designed around how managers think.  It does a much better job of acknowledging how programmers think, but in the end, what it really does is rewrite a programmer's workflow.  I'm OK with a different workflow, but the truth is, most scrum trainers, and scrum devotees forget about the details, what that different workflow really means for the programmers.  They only repeat the phrases "User Story" "Task" and "Backlog" as if none of that affects how programmers work.

So That Was a Long Explanation

So all of that detail was just to get you to this point.  Here are some things you can do to improve the implementation of scrum around your workplace.

1. Explain it to your customers

Your customers (even those in your own organization) don't know what scrum is, and chances are you've said something silly like "bi-weekly releases" and they think that the programming world has magically changed.  You need to take the time to be clear with them.  Developers are still the same people they were, many anti-social, and most unable to speak non-developer business language (sorry guys & gals, it's true).  This "Agile" approach may result in more direct contact with developers, but it is not suddenly the job of the developers to take phone calls from your customers.  Trust me, you don't want them to do that when they're fixing a bug that was written by another developer whom they aren't fond of.

So that means that 1a: Communication comes from your side to the customers, not the other way around.  I know this may sound backward from scrum, but the reality is that we have seriously increased the customer's interaction by demonstrating the product to the customer in demos every sprint or two.  They are gaining from scrum by being able to communicate more often, but it has not changed the fact that communication still must be initiated from your side.

Additionally, your customers may perceive scrum to mean that each user story is completely independent.  As any developer will explain to you, code builds on itself.  You can't build the attic room to a house without at least building the frame (or the attic).  Your customers won't see it this way.  While there may be independent user stories that can be implemented without their counterparts, the customers must understand that 1b: Code is still a process, and adding and removing features is not a simple task

The sad truth of 1b is that most scrum training tries to explain this, but does so very poorly.  And finally, there's 1c: Sprints are often enough communication If you followed scrum correctly, you designed your sprints around a single unit of work for your team.  That means that, aside from requirements clarification, meeting with the customer in the middle of the sprint is only going to distract from getting the requirements complete.  Your customers need to understand that, in the old days, it would be months between communication, or worse, they couldn't change a feature except by renegotiating the contract for the software.  They don't need unfettered access to communicate with the team all day every day.  If the team chooses to be more open, so be it, but it's the team(read developer)'s choice, not the customer's.

2. Sell it to your developers

That's right.  These people may work for you, but they're bright men and women, focused on independent thinking as part of their job.  They need to be onboard with the idea, which means you need to 2a: explain the good and the bad to them and 2b: get them to like the idea before you move forward

Don't take the comment about explaining the good and bad lightly either.  There are downsides to scrum.  For one, there will be more meetings, though ideally they'll be shorter which should make up for that.  But that means they will get more interference with their 'ramp up' time--like the daily stand up for example.  It also means a more structured schedule, because of things like the daily stand-up, programmers who were used to more flexibility in the past tend to lose some of that flexibility in order to be around the team more--even if that means being around their remote machine during more traditional office hours (when I'm least productive I should note).

3. Help your developers build a new workflow

This is the piece that most companies miss.  They'll set up some agile software and say "yay, we're agile, we're scrum" and teach their Project Managers that there's a new workflow, but they never sit with their development team and take the time to develop a new workflow for them.  This goes way beyond teaching them to watch the backlog, and how to add tasks to user stories.  For one thing, scrum starts to require source control to be used differently.  Branches become a much bigger deal, as do rollbacks.  This means your team may need to convert to a different source control/build system altogether.  This is a BIG deal, and too many companies seem to ignore it completely.

Some examples of workflow ideas that I've either implemented or started researching for this very reason:

  • Use branches for prod, test, and dev.
  • Use separate branches for prod & test fixes, so they are separate from your general dev code & fixes from other sprints
  • Consider individual branches for each user story, and consider the extra work this burdens devs with
  • Emphasize clean coding practices, like DI, SOLID, and DRY making your code more "Agile"
  • Consider frameworks like Docker to make CI simpler
  • Implement Continuous Delivery at least to Test & Dev, Consider full Continuous Deployment
  • Negotiate for easier-to-use tools for Agile
  • Use whatever tools you can to make your Agile software take up as little time as possible (IDE plugins, etc)