Agile Revolution Breaks Into Business and Life

Agile has been transforming software organizations one by one since the turn of the millenium.

Quadrupling productivity while making people and teams happier.

Modern work and life is knowledge-oriented, fast, and ever-changing. That’s what Agile addresses.

Why doesn’t anyone outside of software development adopt it?

Steve Denning, in a 2012 Forbes Magazine article, called it The Best-Kept Management Secret On The Planet.

It’s still pretty secret, but it shouldn’t be. The word “software” appears only once in the four statements of the Agile Manifesto. Three times in the Principles of Agile. Just replace “software” with “anything”.

Need confirmation? Try Ana Willem’s Should Non-technical Organizations model Agile principles? (no brainer).

So who’s doing it? Who is being Agile in their business or their life?

Here are the very few examples I’ve found so far:

• School: eduScrum
• University: The J-School Scrum: Bringing Agile Development Into the Classroom
• Job Search: Manage Your Job Search

Can you share more?

Advertisement

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!

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.

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.

Play your cards right

A new project is ramping up and needs more resources. Another project is winding down — maybe it can do with less.

Let’s move some people from one team to the other

What’s wrong with this common resource allocation decision? It’s not the decision. Moving resources to the project that needs them makes sense. What’s wrong is the words, which hide a false assumption.

Here, “team” means location. Move people from one place to another. Like conductors putting people on a train: the “teams” are two train stations. One called “Project A Station” and the other one, “Project B Station”.

But teams are not train stations. A team is not the room it sits in, or its box on the org chart. A team is the particular combination of people — their skills and personalities — and their shared experience. They know their project or product best right now, and equally important, they know each other and the special role each person fills. Reassigning people from one team to another is more than moving a person. It is actually dismantling the first team, and disturbing the second. The movement of people based on the train-station model of teams leads to a contradiction: both teams — origin and destination — cease to exist.

If we must model people and treat them as resources, a better model is a hand at cards. The managers are the players and partners; the game is getting more projects completed. There’s a fixed deck — the “human resources” of the company. Some cards may be similar in strength or level, but every card is unique.

The value of your hand is based entirely on the combination of cards you’re holding right now. If you or your partners need a stronger hand, everyone knows that some cards will have to be exchanged. Put down 2, pick up 2. I pick up what you put down. Resources. Cards. I know this doesn’t sound any better to workers than “counting heads”, but it is. Because every card player thinks twice before putting down a good card, and prefers to take over an entire good hand if they can.

Product Quality: 3-in-1

It’s pretty well known that there are three ways to improve software quality: improve process, improve methods, and improve tools. But these are the generic concepts — applicable to any software development effort. Today’s topic is more specific and closer to home. Product quality.

Isn’t it obvious? The software product is the running software, and product quality is how well it meets its requirements. Simply put — does it do what people expect it to do, and not crash or lose data?

But organizations which release software focusing only on that one aspect of product quality are often unpleasantly surprised by inconsistency. They are doing all the right things — following a good process, using good methods and tools, and regularly reviewing all those to see what can be improved. Yet sometimes the product is better, sometimes worse. Why?

External product quality — in software, that’s how well the software serves its users when it’s running, is not enough. There’s also internal quality. The readability of the codebase. Code that’s well-written — easy to understand quickly — is easier to maintain. Fewer programmer errors, and fewer schedule slips. We can add to that clear and organized debug output, which avoids false positives, and gives an accurate record of when the running software seemed to be fine, but was really operating on the edge — just barely recovering from failures.

But there’s another part of the product that’s often overlooked. Overlooked when reorganizing teams, or just when parceling out the daily assignments from multiple projects. The developers. If you take a single iteration of a software product, with development at its best, you’ll apply best process, methods, and tools to put out the next version of the software, and maybe even have codebase improvement (cleanup, refactoring) on the list too. Get to release and you deliver good running software, more maintainable code and … the new state of the team that developed it.

The team members may have learned new methods or technologies. Or just how to avoid pitfalls from the past. Equally important, that particular team learned how to work together — not in general, but specifically in today’s process, methods & tools, and codebase. And with each other. This third part of the product cannot be ignored or thrown away, just as nobody would think to delete a code branch delivered to the customer, or switch out a working library in mid-project.

Looking further at this third component of the product — the team that delivered it — we see clearly that those quality improvement concepts of process, methods, and tools do not exist in a vacuum. They are not just abstract ideas. Rather, they exist in the team members who develop a product, and are unified by teamwork — which means this team learning to work together with these people on this product.

So when you think of product quality improvement, plan to improve all of these:

1. How the product works
2. How the codebase looks
3. How the team works

And at the end of an iteration, make sure to review and protect all three. That’s the guarantee that the next version of the product will be even better.

Simple Use Cases

Google “use case format” and you’ll get lots of templates. Which one to use? Here’s my really simple template that people around me have started using:

• Who I am (role)
• What I’m doing (current task)
• What I want (current goal)
• What I type (into the system being defined)
• What I expect to get (out of the system being defined)

True, it doesn’t address pre-conditions, post-conditions, extensions, and more. But it serves well for high-level discussions, and gives a clear understanding of what use cases are for. After using this template for a while, go to Google and get one of those fancier ones if you want.

The Best Time is No Time

Something that nags at me in the background is time-suckers. E-mail for example. A while back I made myself a list of rules for e-mail handling:

1. Delete without reading
2. Read and delete
3. Read and file
4. Read and reply

But it’s got some problems. First, it’s hard to keep to rules when my e-mail is always there, tempting me away from harder, though more productive, activities. Second, the hidden assumption is that e-mail is a satisfactory way to handle every task which is introduced in e-mail. (Wrong!)

I tried a little experiment, unplanned, on a day when I was off work. I told myself I would process my e-mail (so there wouldn’t be a mountain of it when I returned) but not reply to any of it. In other words, I would apply options ##1 – 3 above, but not #4.

I was off for 2 days, and during that same period, my local worksite was closed, so nobody local was sending me any e-mail. Still, when I logged on, I had almost 100 new e-mails! Some were automatically generated, and the rest originated at another worksite that was not closed. Most of the e-mails were simple text, but a few had attachments. Including reading those, I “processed” all but 5 e-mails, which seemed that they would merit a response or action upon my return to the office.

What’s interesting is that, on second look, none of the remaining e-mails really require a response. My replies might help the sender a bit, or suggest to them something that could help me slightly in the future, but nothing big. Probably my responses, if they are still helpful by the time I do return and respond, will only generate more e-mail.

Meanwhile, I just noticed that the only e-mail that actually requested something of me alone (that is, if I don’t do it, nobody will) was not among the 5, but was an additional e-mail left behind from the first of the two days’ e-mail I reviewed. And the best way to deal with it will be to visit someone in person to discuss it.

So what’s the best way to save time on e-mail? Use it less. Receive less, by tailoring subscriptions carefully. Send less, by e-mailing only to request or provide an answer that must be in writing.

I’ll try that.

Telescopes and Software

This evening I was looking for pricing on some code analysis tools, and found an organization that had done a very comprehensive survey, and published it
 
http://dev.lsstcorp.org/trac/wiki/CppCodingStandardCheckerReview%3A#CStaticAnalysisTools
 
And they’re pretty organized and public about their entire software development process: http://dev.lsstcorp.org/trac/wiki
 
But I asked myself, who are these people?
 
Well, here’s a photo: http://www.lsst.org/About/lsst_team.shtml
 
They are building in Chile: http://www.lsst.org/Images/pachon.shtml
 
They want to take pictures like this: http://www.lsst.org/Science/lsst_science.shtml
 
Overall, this is their project: http://www.lsst.org/lsst_home.shtml, in part:

In a relentless campaign of short exposures with its 3.2 Gigapixel camera, the LSST will cover the full available sky every three nights, opening a movie-like window on objects that change or move on rapid timescales: exploding supernovae, potentially hazardous near-Earth asteroids, and distant Kuiper Belt Objects.

All in all, some pretty interesting people!
 
Also honest about how their software milestones, like those on so many other projects, are behind schedule: http://dev.lsstcorp.org/trac/roadmap?show=all