Agile Travel — Does it Pay?

Can you get quality and on-time performance at less cost, based on discipline, openness, and prioritization by value to the customer? Agile says you can. I decided to put it to the test even while traveling to an Agile conference in London (RallyON Europe 2014), by traveling a no-frills airline into Luton, UK. You guessed it, it’s EasyJet, the airline where the only thing that’s free is the orange color scheme that makes everything from the check-in area to the seat headrests look like a children’s playground.

My no-frills experience started while packing. Several readings (or viewings — they have a video too) of the EasyJet cabin baggage policy. One carry-on bag allowed. ONE. They make every effort to be “open and upfront” about that. And two size limits: a normal one that they might still check (for free) if the flight is crowded, or a really small one — 50cm x 40cm x 20cm — that they guarantee you’ll be able to take on the plane.

So I got that into my head. Flying a no-frills airline is easier if you’re prepared. Pack light. Pack only the one bag. Make sure it meets the guaranteed carry-on requirements. (Tip: While EasyJet allows online checkin for all flights up to 30 days in advance, don’t check in until you’ve made up your mind about bags and seats, because after that, at check-in, the prices are higher.)

I measured all the carry-on bags we had in the house, then put them aside and chose a medium-sized day pack instead. Packed minimally and measured. It just fit the guaranteed carry on baggage size as long as not filled too fat. Nice clothes for 3 days, a laptop, a few other small essentials. True, I’ll have to repack carefully each night so I’ll be ready for the return flight. Trading that discipline for the convenience of just throwing everything in to a large suitcase at the end of the trip. Added benefit is that I’ll be able to walk or metro easily wherever I need to get to, hands free. Just the light backpack. Less is more.

Trip to the airport. I was traveling from a warm climate to a colder, rainier London, so I was a bit warm wearing my layered sweater and rain jacket. I took them off when safely seated on the shuttle bus, and to be sure to remember them, I repeated the mantra: “You have 3 items: jacket, sweater, backpack”. The sweater would actually prove useful later — over a short-sleeve polo it kept me comfortable on the air-conditioned flight. No need for one of those airline blankets. Which EasyJet does not supply.

At the aiport. On arrival, I discovered that EasyJet departed from an old terminal rather than the new one I was used to, so I jumped off there and asked my way around. Separate terminal for check-in but I realize now I probably didn’t have to go there. My boarding pass did say that I could have gone directly to security, passport control, and gate at the main terminal. But everything was smooth and not crowded at the EasyJet security and passport areas and shuttle back to main terminal was quick too. Let me out straight into duty free as a transit passenger.

Onboard. The phrase that comes to mind is “nickel and diming“: EasyJet charges extra for everything. But I changed my mindset — can’t think about it that way. Instead, I used the significant savings on the main ticket price to feel better about adding on any extras. EasyJet believes their system is better for the customer: I pay only for what has value to me.

One extra I found worth it for peace of mind was to choose seats beforehand. That way I didn’t have to wonder what seat I would get and how cramped it might be. I probably should have paid even a bit more to get the extra legroom seats because for someone with long legs, the seat spacing was tight enough to hit my knees unless I sat up really straight the whole time. Not that that was so difficult: the obligatory announcement on take-off to “put your seat backs in their upright position” is superfluous on EasyJet as the seats do not recline. Just as well, because if they did, nobody would have any space at all!

The “speedy boarding” extra charge  might have been worth it too, to board sooner, but I made up for it by being first in line for the general boarding. I stood (rather than sat) at the gate for the 10 minutes it took to board the “speedy boarding” people first. In essence, I got to be the last speedy boarder without paying the fee. I guess that’s called advanced flow control … or just gaming the queue.

What about the infamous 50 cm x 40 cm x 20 cm x 1 bag rule? I had never seen it in person so I even brought along a measuring tape to make sure and prove it if I had to. But the EasyJet metal sizer stand was mostly there as a prop to support the gate staff’s emphasis of the 1 bag part. Nobody’s bag was actually tested in the sizer. The tally: two or three cases of, “That’s not one bag, sir, that’s three — please arrange it as one bag and return to the gate when you have done so.” A few got, “That purse, it’s not duty free — you’ll have to put it inside your carry-on suitcase.” Which they actually did, with minimal complaint. One or two people slid by with a regulation carry-on but also another bag.

The real challenge to on-time take-off was when people boarded the plane. Since I had been on the first shuttle bus, and thus already seated by the time most people boarded, and I had a row 8 aisle seat, I had a good view. There wasn’t any pushing or shoving — people were relatively polite and quiet. But to board a 180-seat, one-aisle plane where everyone has the maximum-size carry-on took quite some time as people worked to fit their bags into the overhead compartments. And then, remembering what they would want during the flight, standing in the aisle blocking progress while they got it out. Echoing the recorded announcement, one or two passengers assertively and vocally encouraged people within earshot to please sit down in their seats so we wouldn’t miss our turn at takeoff. I admit that I was one of the two. But in the end, all were seated, only the very last few people boarding had to use their precious under-seat footroom to stow a bag, and we took off 20 minutes late. Since that was followed by the flight staff’s announcement that we would nevertheless be landing on time, I gather that EasyJet includes the slow boarding process as part of their scheduled flight time.

The flight itself. Cramped legroom but survivable, especially if you get up and walk around every so often, which is a good idea on any flight. There is food service, and you pay even for a cup of tea. But if you want one, you can afford it: you saved 80 cups of tea by flying EasyJet instead of the non-budget competitor. They actually came through twice during a 5-hour evening flight, and still had a reasonable selection of hot and cold foods. If you buy more than GBP 5, you can even use a credit card to pay. Otherwise, cash on the barrel — well, on the trolley.

I didn’t buy any food on the plane. I had used my cheap gold card (i.e. not American Express which is great but costs money) to get into the cheap airport lounge, and I ate there instead. But if I had been more hungry, the egg salad sandwich would have been fine.

Newspapers cost money too. I brought my laptop to read from instead. (Essential Scrum by Kenneth S. Rubin.)

During the flight, there was also some kind of duty free service. It’s for people who must have an overpriced, underfed Paddington Bear. To be fair, I don’t really know if they were overpriced, because I didn’t even ask.

They are efficient on the food service. For example, my neighbor’s selection (twice!) was “tea, 3 milks, 2 sugars”. It was only by the second time that I realized how they served that. No pouring here. Instead, a large paper hot cup, filled and covered, and a second paper cup with cigar-sized packs of sugar and dehydrated milk. Worked for my neighbor, and the flight staff came by promptly after each time with a bag to collect trash. Now that I think about it, the food service was much cleaner, quicker, and more comfortable than on full-service flights. No sitting for a half hour waiting for your food while the rest of a 300-seat plane is served, and then another half hour with the leftovers on your tray table, preventing you from resting, working, or even getting up to walk around. People who wanted to eat got to, and yet air was fresh and aisles were clear pretty much the whole flight. Approaching the end of the flight, they came through a third time with food and gifts, and announced they even sell bus tickets!

Cramped? (I was.) Hungry (I wasn’t). But those were my choices. Next time I’ll know to buy extra legroom.

In summary, an agile experience: EasyJet has a system which requires discipline from staff and customers. In return, they provide a quiet, clean, on-time flight for half the price.

Tomorrow morning, EasyJet’s orange cousin, EasyBus!

Advertisement

Agile Why and How

Ask about “Agile” and everyone will start with the Agile Manifesto. It serves us well, seems short — only 4 sentences. But then there are 12 principles as well, so I guess 4 sentences weren’t enough.

After trying, and learning, and delivering some good software, we’re also getting the message clearer.

Why Agile?

To put working code in front of the customer quickly, so they discover better what they want, and tell you.

How to do that?

Reduce batch size, and limit work in progress.

—

Today’s thanks go to Rex Morrow, Dele Sikuade, Ken Clyne, and another coach who’s known me all my life.

 

Whole code awareness

Busy software developers tend to think of refactoring as a luxury activity, and separate from writing new code or fixing defects. At first glance, the latter two activities clearly contribute to why we write software — to get new, working functionality from hardware — while refactoring, by definition, doesn’t change the software’s behavior at all.

But if we recognize that every code change or addition may affect both the dynamic behavior (what the software does), and the static behavior (how easy it is for the developer to modify it as desired), then all three code-change activities come together. Every code change, whether it’s refactoring, new code for new feature, or changes to fix a defect — and no matter how small a change — is a change to the entire codebase with the purpose of increasing its value.

This mindset is what motivates code quality engineering practices such as in-person design and code review, static analysis, and automated whole-system regression testing (including load testing and robustness testing). As well as, of course, refactoring!

And while time and resources for these activities can be planned as part of any software development methodology, it seems easier in Agile. Include all these activities regularly in sprint tasks per user story, evaluate them all in planning based on their size (cost) and their benefit (value), and get them done regularly. Apply this whole-code awareness, and watch defects decrease and velocity (and enjoyment) increase!

—

Thanks to Will McKinley for the post Code Refactoring – Dealing with Legacy Code that made me ask myself what are the differences, and similarities, between refactoring and other types of code changes.

I’m in Software

When somebody asks me what I do and I say, “I’m in software”, or “I’m in computers”, they usually give me a “Oh, that’s nice,” but it’s clear they aren’t any wiser than before they asked. Why is that such a conversation-stopper? If you’re a lawyer or a doctor, people think they know, and jump right in.

Maybe that’s because lawyers deal with people and justice, or at least arguing, which sounds familiar. And doctors — well, everyone’s been to the doctor. The drama of dealing with people is what gets lawyer and doctor shows on TV, and I’ll be the first to admit that my picture of what they do comes straight from there. Really that means I have no clue.

After a bit of thought, I realize that software is more like art, if that helps.

(Right — saying you’re an artist is like saying you’re in software, only poorer.)

But really, it can help.

The solution to explaining what “I’m in software” means is to realize that software, and software development, is really three very different things. To the software developer, it is code — lists of instructions to make a generic machine behave in a specific way. To people in general, it is invisible: as mobile phone users, airplane travelers, or just people turning on the faucet and getting water, the world is full of things made of plastic and metal that behave or respond more actively than a cup or a pair of scissors. And finally, software development, the activity that goes on in a hi-tech software office, includes a good deal of accounting, scheduling, and event planning.

This triple personality parallels art. When someone tells you they’re an artist, do you think of paints, chemicals, brushes, and canvas? Or paintings on the wall? Or the business of running an art gallery?

I’m pretty sure most people hear “artist” and think of paintings. But the “what the artist does all day”, whether it’s looking, thinking, or carefully mixing paints, is invisible in the painting. We see the painting and know nothing about the work life of the artist.

So being in software, like being an artist, means doing something unseen to materials and creating interactive things that everybody then takes for granted.

Probably the only way forward for more people to understand what’s “in software” is to take them into the studio — the hi-tech office — and let them try their own hand at coding a mobile phone app. Or on the other hand, attending a project meeting.

Say, why aren’t those kinds of experiences available at the local computer or science museum — not playing with the things, but making them come alive?

John Hollar and Grady Booch, are you listening?

Error-Proofing Made Simple

Error-proofing is preventing errors rather than just warning about them.

With compiler warnings, that means setting warnings-as-errors in your compiler so you cannot complete your build. Yes, you also need tests that can fail and a source control system that refuses promotion of versions that fail test. And code review to ensure that code changes to address compiler warnings only improve the code. But the key is warnings-as-errors.

While error-proofing is simpler with fast-food trays, the idea is the same. Read “Simple, Brilliant, Error Proofing at the Amazing In-N-Out Burger” (Mark Graban  |  04/11/2011  Quality Digest) and look for where else you can error-proof your process.

Don’t Call it Testing

Recently I went to a workshop on Exploratory Testing given by John Stevenson. Just as exploratory testing finds the unexpected, so I learned something unexpected. Every time John used the word “testing”, he meant it as (re)defined in Michael Bolton’s Testing vs. Checking. It’s a powerful redefinition, and simpler to say than what I’ve always meant by “adversarial testing”. Here’s how the redefinition works:

1. Notice that many tests don’t find defects
2. Decide we need a new definition for the word “test”
3. But the current definition is useful, so move it to the word “check”
4. Now the word “test” is open for redefinition
5. Define “test” as in Testing vs. Checking

Quick summary of new and useful definition:

Let  “test” mean an exercise of the software under test that helps a thinking tester answer the question, “Is there a problem here?”

Change the Software

Recently I became the unwitting user of a new piece of consumer software, when our office upgraded our mobile phones. Suddenly, with every phone call, appointment reminder, and even when charging the phone, I’m acutely aware of what I want from this piece of embedded software that I did not even buy. As a software user I want only two things: more or better features, and problems fixed. I don’t care what version the software is — I care what’s changed. It would make sense, then, that software developers should focus on changes, not versions, and that tools should support them.

The most common tool on a software development project is always the “bug tracker” or defect tracking system. It’s really a change request tracking system, with two kinds of requests for changes: enhancements (performance improvement or new feature requests) and defects (fix requests). Tracking requests for changes. That’s good.

Now look at the other major tool in every software development group — it’s usually called a “version control system”. But see above —  users don’t care about versions. And developers have to report to the defect tracking system what they’ve done, and that system is which is full of requests for changes, not requests for versions. So why would we want a version control system?

That’s why the light went on for me when I read Joel Spolsky’s Hg Init: a Mercurial tutorial. Not because Mercurial (or Git) makes branching cheap and merges easy. (It does.) But because, as Spolsky writes:

Subversion likes to think about revisions. A revision is what the entire file system looked like at some particular point in time. In Mercurial, you think about changesets. A changeset is a concise list of the changes between one revision and the next revision. (When Spolsky writes “revisions”, read “versions”.)

Now I understand why there’s so much trouble connecting our defect (change) tracking and version control workflows. Testing too — what we really want to know is, “Which change broke the build?” And bringing in code review, more problems, because people want to review whether each change accomplishes the goal of adding or fixing something.  Software development is all about changes: specifying them, designing them, coding them, testing them, and delivering them. Not versions. Changes. Sure, versions have a place in software delivery — they are labels for the software after a certain number of changes. (Mercurial supports them, as “tags”.) So if you want all the tools to work together and make your software development life easier, switch to a software repository that lets you control changes.

What should we call them? Maybe “software changeset control systems”. The two big ones these days are Mercurial, and Git. For Mercurial, see Spolsky’s tutorial. For Git, listen to Linus Torvalds on git.

Software is Writing

Software is not construction

Software is not construction, no matter how popular that statement may be. A program is not a building. Parts are not chosen first and then fitted into place. Design continues almost to the last minutes of coding. Further, almost nobody spends time creating new code, at least not for very long. Sure there are new products and new codebases. But even then, after a short period, most additional coding is extending or changing an existing codebase. So if coding is not construction, and mostly involves changing what’s already created, what is it?

Well, coding is writing. It’s using text to communicate a message. That may not sound like much, but understanding this helps a lot. Instead of struggling to make up new ways of thinking and learning, as if programming were a completely new human activity, we can look at how good writers write. People have been writing for many hundreds of years, and have become pretty good at it.

Learning to write

How do people get into writing? Do we start, as most do in programming, full grown, writing essays? No, not at all. We start as children, and learn first to talk, then to read, and finally to write. Yes, I know that school seems to teach writing, at least forming the letters, before reading. But it’s an illusion: listening to a bedtime story is essentially reading – paying attention to someone else’s writing, and understanding it – and comes before writing. Most people don’t try writing that communicates a message – expository prose – until secondary school or later.

Good writers have their audience in mind at all times. They edit their writing through several drafts, as well as getting others to review it, and give written comments. And they talk about their writing. Maybe not always directly, but when a political columnist goes to a dinner party, you can bet he’ll talk politics. When a novelist chats in the park, she’s talking about the same human struggles that will later appear in her books. Even for the solitary writer typing in a darkened room, the life that feeds the writing is one of talking with, listening to, and reading about people.

Software is Writing

Now back to software: software is not like writing, it is writing. In our industrial setting, it is too late or too radical to suggest re-teaching programming, by teaching first how to talk, then to read, then to write programs. But we can highlight where daily programming work already involves each of these three activities, and where it doesn’t, but should.

Talking includes formal design reviews and code reviews, but also whiteboard conversations and hallway arguments. How should I write this here? Why is that data structure that way? Why does the compiler give that warning? Don’t just think alone – talk it out with someone nearby. It is the same with tests. Why does that scenario fail intermittently? How should I write it differently? And even for defect entries -what does the submitter really mean? Phone him up. Why does this change fix the problem? Find the developer and ask.

Reading is for design documents, training materials and perhaps professional books. But mainly, it includes reading lots of existing code. That’s reading it until you’re really sure what it does, so you know how to change it, fix it, extend it. There is also code review — where the author asks you to read their code, not just to say that it looks fine, but to identify what’s wrong, or unclear.

Writing is the coding, of course. But who is the audience? There are two audiences. One, the compiler, which is your personal translator, from a non-native language (nobody’s mother spoke to them in C), to an almost unknown language – the machine language that the hardware actually understands. The compiler is a rigid, simple-minded, sometimes unpredictable audience, just a ghost of the person who wrote it. Here you have to be very precise, careful, and limit yourself to what the compiler understands and to what the hardware will accept. The other audience, is so very different – the next developer. This may be yourself a few weeks later, or someone else, but there will always be another developer, coming back months or years later, to fix or extend the code. She wants comments, explanations, meaningful names for things, and an easily readable structure. Because now you’re long gone, she can’t talk to you: she must read, so you must write.

Tools!

Well, with all this talk about programming being writing, let’s come back to earth. Software developers are technical people, and expect to use the best tools to do their jobs. There’s the whiteboard in the hallway — we need more of those, for talking. Defect tracking systems, where we can make sure we write clear resolution notes. And for automatically sharing and discussing code, web-hosted code tools for static analysis and code review are the way to go.

—
Originally published in company internal newsletter. Edited and released here with permission.

Tell it to your Teddy Bear

After spending more time than I should have troubleshooting a coding (actually static code analysis) problem, I shared the story with a co-worker, who reminded me that Kernighan and Pike had been there before:

Another effective technique is to explain your code to someone else.  This will often cause you to explain the bug to yourself.  Sometimes it takes no more than a few sentences, followed by an embarrassed “Never mind, I see what’s wrong.  Sorry to bother you.”  This works remarkably well; you can even use non-programmers as listeners.  One university computer center kept a teddy bear near the help desk.  Students with mysterious bugs were required to explain them to the bear before they could speak to a human counselor.

Brian Kernighan and Rob Pike, in The Practice of Programming

Seems that there are rules that we learn, then love to break, and are always sorry afterwards. Here’s how.

My code doesn’t work

• I’ll just try this change to see if that fixes everything. And then this change, and this other change.
• I’ve been stuck for 10 minutes, but since nobody knows this code like I do, I won’t ask anyone for help.
• I know I don’t understand what every line of code does, but it’s OK — I’ll figure out the problem anyway.
• A complete build takes only a few minutes, so there’s no need to try a 3-line sample instead.
• I’ve read the documentation and I’m sure I’ve understood it, so I won’t ask anyone for a second opinion.
• I already asked someone 3 times for help and got it, so I can’t bother him or her a fourth time.
• It doesn’t compile (cleanly, or at all) just now, but soon it will again if I just keep at it

(The only way I got home today was that somehow I did realize it was, um, OK to call the tool support line.)

What are your favorite “justifications” for why it’s better to stay stuck than to get help, or at least take a break and share your problem with someone else?

While I’m waiting, I’ll go talk to my teddy bear.

Two Against the Code

One of the big human challenges to code review is ego. For all the talk about “egoless programming”, ego still means “self” and when a person writes code, or owns it for maintenance, s/he identifies with the code. That kind of “ego” or “self” thinking is what lets the code author work through problems by saying, “let’s see, when I receive this signal, I enter this loop and I calculate that value.” So how can code author and code reviewer(s) go into a code review, whether it be a meeting or online, and yet avoid criticism and defensiveness?

Here’s an image that can help: when code review participants enter the review, imagine everyone sitting on the same side of the table, with only the code on the other side. The code author is no longer the author or owner — just another reviewer. The two or more people in the room, or in the online review, form a team together to find as many things as possible in the code to improve. Now nobody needs to defend the code, because everyone is a reviewer. Still, though, if criticism is in the air, the real code author will feel it.

The desired result of a code review is a list of important things to improve. Comments which the code author can take back to the code and say, “I understand what I need to do to make this code better.” Take a concept from the topic of assertive communication: The “I” message. Best explained by an example:

Let’s say I’m a busy, pressured group leader who has to lead meetings, and someone is always late for the group meetings — much later than everyone else . I decide to speak to that person. What can I say to him that will cause him to feel what I feel, and based on that, to join me in solving the problem? Not to feel criticized, and to become defensive. An “I” message would be:

“I’m under a lot of pressure when leading our weekly status meetings, and when I see you come in 20 minutes late to the meeting, it makes me more tense, and makes it hard for me to keep the meeting on track.”

The idea is that, while I have mentioned the person’s lateness, I have described only what I see, and described a problem that I have. All the focus is on me and my problem, which the group member may realize is his problem too, since he may benefit from a calmer group leader and a more effective meeting. Hopefully, he is drawn into solving my, or our, problem.

Similarly with code review. Instead of a critical comment like, “this code is very confusing,” say, “when I read through this function — both the comments and the code — I get to the end and I still have no idea what it’s really supposed to do. If I had a change request on this code, I would not be able to confidently make the change.” Given that the code author probably does not have the same problem, this comment draws the author into saying, “I understand what the function is supposed to do, but apparently you don’t from reading the code. I’ll try to improve the comments or clarify the code so that you understand what I understand.”

Try this method in your code reviews to get everyone working together against the code, to improve the code.