...copyright Elena Yatzeck, 2010-2017

Friday, December 21, 2012

3 Agile Risk Management Tips from Shamu

Experienced agilists make it sound so easy, don't they?  They tell you over beers about the big, honking project they did last time.  They showed up, did some "workshopping," set up a little CI environment, and then, two weeks later, they began churning out working software.  And not just any working software:  high quality, low complexity, and perfect fit to business needs.  And why not?  The Product Owner was in the room to design and approve it!  Agile is fun!  Woo hoo!

This may not sound like the projects you do at all, where you experience confusion, resistance, fear, sweat, and tears, and you teeter daily on the edge of failure, public humiliation, alcoholism, and unwilling participation in corporate "resource efficiency" efforts.   How can you be an agilist when you don't share this ability to triumph over the grim corporate realities and do the impossible every day (twice on Sunday?)
Here's a quick answer from Shamu, the quirkily named Orca(s) at the Sea World amusement park(s world-wide):  if it looks like a killer whale, and it swims like a killer whale, and it has killer whale teeth, then it probably IS a killer whale, and you need to be careful.  Agilists cannot be any more cavalier about project risks than anyone else.  Ask yourself:  are you "making a hard job look easy," or are you thinking that you have "changed the world so that we don't have risk any more." If it's the latter, please think again.

If you as an agilist are not finding, mitigating, and escalating project blockers, issues, and risks faster and with more rigor than your waterfall counterparts, then you are going to"fail fast," but not in a good way.   This flop is going to be without proper messaging, and on a schedule that is quite a bit faster than the one for which you, yourself, had hoped.

Every software project is a corporate financial investment backed by an explicit or implicit risk strategy.  Executives put money on the table to finance team activities with the expectation that the business will benefit from the expenditure.  That is why they are financing the project rather than putting the money into CDs and living on the interest (or buying a patent to exclusive-or bit-map representation and living off of the lawsuit proceeds).

When you are working on a big project, where a lot of money has been paid up front, then you own a piece of a sizable executive gamble.  What you do matters not only to you, and to your team, but to your whole organization, to your board of directors, and, depending on your industry, potentially to the whole world.

Which brings us back to Shamu.  What does Shamu have to recommend to you as an agile team participant, leader, or funder? 

1.  Risk is real.  Even in agile, and especially in agile, "risk management" is not a CYA activity in which boxes are ticked off, although that may be all you are doing today.
  • Effective project participants need to start with the expectation that the world tends towards entropy, and that if something can break, it will.  
  • Entropy needs to be constantly evaluated and triaged.  Do we have a crisis today, you should ask yourself, not just at the retro, but every day.  
  • If you do think you see something terrible about to happen, "pull the andon cord," as they used to say at Toyota.  Make a stink.  Get people's attention.  Make sure that the team acknowledges and fixes your perceived crisis-level problem or can explain to you why your perception is off, within a reasonable time frame.  And don't be too quick to think "it's just you." 
Problems come in many shapes and sizes but an actual crisis can come up on any day, and you want to be the one to point it out and prevent it, not the one crushed by it. 

2.  Put on a show, but be honest with yourself and your team, and fix your important issues.  As of 2010, Sea World has banned having trainers in the pools with the whales, after a whale trapped an experienced trainer at the bottom of a pool and killed her in front of a crowd.  For the 20 preceding years, the trainers had made it look easy, but it's not as though there hadn't been warning signs.  Wikipedia relates:  "On March 4, 1987, 20-year-old SeaWorld San Diego trainer, Jonathan Smith, was grabbed by one of the park’s 6-ton killer whales. The orca dragged the trainer to the bottom of the tank, then carried him bleeding all the way back to the surface and then spat him out. Smith gallantly waved to the crowd when a second orca slammed into him. He continued to pretend he was unhurt as the whales repeatedly dragged him to the bottom of the stadium pool. Smith was cut all around his torso, had a ruptured kidney and a six-inch laceration of his liver, yet he managed to escape the pool with his life."
  • Jonathan Smith is a bona fide hero for "going on with the show" under terrible circumstances to safeguard Sea World's flow of money in 1987.  
  • It's not as clear that Sea World looks good in allowing a stream of trainers to be injured before finally banning them from the pool.  And I don't even particularly want to get into the ethics of keeping Orcas at Sea World in the first place.
The point here is that it's a balance.  Your reputation as a successful software delivery person needs to be maintained, and face must always be saved.  But while you save face for yourself and your sponsors by staying positive, you need to be vigilent and powerful in getting the small group of people who have the power to fix your biggest risks to do so as quietly as they like, but quickly and efficiently.

3.  Please, never be optimistic.  Take the time you need to identify and mitigate identifiable risks before you start.  How much time you take, and how much you wait is going to vary by your context, by the stakes, and by the risk appetite of your funders.  Don't go for "fast" on principle.  Put this in context:  at its best, agile software development lets you find and fix your most important problems in a time frame that is months ahead of when the waterfall project would have even started standing up its first environment. 

Please, my friends, don't be macho.  Be smart.  As they said in the Sex Education Road Show at my college,  "Hope is Not a Contraceptive." 

Thursday, December 13, 2012

A Corporate Agile 10-point Checklist

I'm pretty sure my few remaining friends in the "small, collocated team agile" community are going to desert me after this, but I actually have a checklist of 10 things to think about if you're a product owner at a big company thinking of trying out some agile today.  Some of these might even apply to you if you're in a smaller place.  So at the risk of inciting an anti-checklist riot (I'm sorry, Pez!), I am putting this out there in case it is helpful to someone else.

From http://www.yogawithjohn.com/tag/yoga-class/
Here's what you should think about:

1.       Your staffing pattern.  A full agile project requires that you have the full team engaged for the whole duration of the project at the right ratios.  So as you provision the project, check to see whether you can arrange this staffing pattern.  If not, you will encounter risks because of missing people.  Concretely it means that:
a.       You need your user experience people (if applicable) and your analysts at the beginning of the project, as always, but you need them to stay around all the way through.
b.      You need your testers, including someone to do testing from a user perspective, from the beginning, not joining in at the end and being confused.
c.       You need to look at what the right balance needs to be between UX, analysts, developers, and testers.  One designer can go pretty far, but a starting assumption for agile is that you should have 1 analyst and 1 tester per 4 developers.  Then you would adjust the ratio, based on the specifics of the people you have and the project.  So the question would be:  do you have the right resources lined up for long enough?

2.       Environments.  In addition to your development environment, you need to have your testing environments and perhaps also pre-production staging environments set up from the beginning and all the way through to deployment.  And these environments should all be set up so that you can pull code into them at will using a tool like Go or Jenkins.

3.       Training.  I would recommend training your chosen team on the methodology you intend to use.  There are a lot of flavors of agile out there.  When you start, you should pick one.  If you're really agile, you'll change as you go, and it won't matter too much where you started.  It would be best if team members get this training just before you do your agile requirements workshop (see item 5!).

4.       Coaching.  You probably need to have a lead coach per team/work stream to help you over the bumps of culture, process, and tool change, for long enough to get through release planning and the first couple of iterations, about 1 quarter, if you have a reasonably sized project and you're doing 2-week iterations.  The coach will likely not be needed after the first quarter, because your teams will be fine on their own to move forward.  The coach is helpful at the beginning though, because this is hard to do on your own.

5.       Workshop.  Please use some kind of structured process for building your “release backlog” of “stories.”  You should allow 3-4 weeks for the provisioning and release planning phase of an agile project for 3-6 months.

6.       “Iteration 0.”  Before you start development, you should take another 2-3 weeks to get the development and test environment and strategy in place, as well as exploring the detailed requirements for your first development iteration.  Aim, then shoot, I say.

7.       GUI Guidelines.  If you are developing software which includes a graphical user interface, then before you start, you should have a GUI playbook of some kind, and you should provision someone who can instantiate the screens you need following those guidelines.  It limits debate about what can be on a screen if you go in with rules.

8.       Auditing.  If this is working correctly, you should always know what is going on, because you are there for it in person during the release planning phase, and you can see the plan and execution to plan in the project dashboards for your work streams.  You will have working software after your first iteration, and all successive iterations.  If there is a problem, it will be escalated when it is encountered, not at the last minute.

So as you get started, you should immediately be suspicious if:

a.       There is no high-level architecture.  In agile, we encourage teams not to go into detail on the architecture before it has been written in code.  But on the other hand, the big pieces all need to be known, and there needs to be a plan for evolving the code base from a small working program to a big working program that performs correctly.  No architecture is bad news.

b.      There is no plan.  There are “scrum purists” out there who will tell you “you’ve wasted your client’s money if you spend more than an hour on a site before you start coding.”  Totally and scarily wrong, at a large company.  The work should be presented as a set of work units, called “stories,” which should average a few days each in duration.  Big, vague stories are a bad sign.  The stories, moreover, should be traceable to a business process or screen wireframe, so that any business person with knowledge of the system can recognize what that story contributes to the system’s overall value.  There should be a plan, and it should be meaningful.

c.       There is no project dashboard, or you don’t have access.  You should have 24x7 access to a meaningful dashboard.

d.      You aren’t invited to an iteration planning meeting and a showcase for every iteration.  And the showcase has to show working software.  You should see proof at every showcase that the team is where they expected to be in the plan.

e.      You don’t get any escalations coming out of the planning workshop.  You are in the Stepford Project.

f.        The team performs perfectly in Iteration 1.  It is common for new agile teams to take 1-3 iterations to get their act together.  If your teams deliver perfectly to plan from Iteration 1, most likely someone is making them work crazy hours, and they are already calling in sick or with fictional dead relatives to escape the oppression.  I have seen this.

g.       You aren’t welcome to join daily standup “Scrum” meetings as an observer.  These meetings run very quickly, and getting them right takes a lot of practice, so it’s not good to jump in and start chatting, but you should certainly be welcome to observe and address the team afterwards.

h.      You can’t get metrics about software quality (code complexity, defect rates, performance, etc.).  You should be able to see those metrics.  You should also know your defect rates and once you go into production what the rate is of CRs due to “bad fit.”

9.       Sustainable Pace. Your project is late, and you may feel the temptation to ask everyone to work day and night for a year to get it done somewhat on time.  This is risky to quality, both directly and indirectly.  Tired people make more mistakes, and staff turnover creates a situation where ignorant people are driving the bus.  It’s better to properly staff it, to get a good result.  Plus your team will be happier.

10.   Beware of Zealots.  The world is filled with “definitive” information about agile software development.  Most of the classic information was written by people in an environment significantly different from yours.  Any time you see the words “it’s just not agile if…” you should beware.  Agile offers a lot of opportunities, but to benefit, you need to start with common sense, experience of human nature, technical expertise, and a lot of pragmatism.  You should never accept advice unless the person giving it to you can tell you why it would benefit you to do so.

Not even this!

Sunday, December 2, 2012

Beware the Dark Triad: Your Worst Change Management Nightmare

What do you think is your biggest blocker, in terms of introducing agile software development to an organization which hasn't used it before?  Ignorance?  Lack of the proper tools?  Cube farms?  These perils are grave indeed, but they are nothing compared to something for which I have just learned the name:  the "Dark Triad." 
Machiavelli tells it like it is--or does he?
The Dark Triad consists of three personality constructs: Machiavellianism, narcissism, and psychopathy.  As that source of all knowledge, wikipedia says,
  • The narcissistic personality (in the clinical sense) is characterized by a grandiose self-view, a sense of entitlement, lack of empathy, and egotism.
  • The Machiavellian personality is characterized by manipulation and exploitation of others, with a cynical disregard for morality and a focus on self-interest and deception.
  • The psychopathic personality, is characterized by impulsive thrill-seeking, and in its "primary" form by selfishness, callousness, lack of personal affect, superficial charm, and remorselessness.
The Dark Triad is in the news this week because researchers have now confirmed that what these three constructs have in common, among other things, is that a member of the Dark Triad will statistically seem more attractive than her peers.  Better dressed, funnier, and worst of all, sexier! Two studies reported in New Scientist revealed that, in a survey of 35,000 people in 57 countries, that those men with Dark Triad traits were more successful sexually. “It is universal across cultures for high dark triad scorers to be more active in short-term mating,” David Schmitt, of Bradley University in the United States, told the New Scientist.

This is not because they are intrinsically more attractive, it turns out in the Scientific American study, but because they know how to dress and present themselves.  It's a killer combination, literally, when the person isn't "high functioning."  In a corporate environment, it can mean that the person about whom you make the quick snap judgement that "this person really GETS IT" is exactly the person you most need to watch out for.
From http://geekeryonline.com/geeklife/7-tips-to-being-a-good-bad-boy/
So what, you say.  So--if you work in a corporate environment with executives who are trying to be promoted, you should know that "the incidence of psychopathy among CEOs is about 4 percent, four times what it is in the population at large," according to British researcher Jon Ronson, and those are just the ones who got to the top.  The road to the boardroom is littered with the debris cleaned out of corner offices where lesser Dark Triad members were identified and sent home.

If you work with 100 people during a large scale organizational change program, statistics tell you that four of them are going to be Dark Triad members.  The Triad is like Opus Dei as presented in The Da Vinci Code, or Soylent Green in the eponymous movie.  It is PEOPLE, it is REAL, and it is dangerous.

Stop and think about the people you work with.  Have you seen enough of them to know who is really trustworthy?  Or were you so excited finally to meet a person who understood you that you didn't stop to ask critical questions, or verify their behavior once you left the room?  Who have you been trusting in your environment and why?  When you rely on your instinct, have you been fooled before?

How do we deal with the Dark Triad triple threat?  I think there are two important lessons here.
  1. In the words of that awesome punk rock group, the Stranglers, "You'd better watch out for the Skin Deep."  Please take a step back as you are bonding with your team.  Trust, but verify.  Do not confide things, especially in writing, that could come back to haunt you.
  2. As TheGeekeryOnline suggests, albeit more with an eye towards scoring than implementing a robust agile program, think about applying Dark Triad behaviors to shake up your own marketing effort.  Be exciting!  If it works for evil, it can work for good too.
So my friends, be careful out there!  And watch for strangers with decoder rings and charming smiles.

Wednesday, November 21, 2012

Monatizing Transparency

As a budding agile coach at a new site, you are probably poised to champion "transparency."  You eager to introduce your friends to "information radiators," open lines of communication, and fortnightly project showcases.  But not so fast!

From some blogger who borrowed it from Dilbert without permission.
As a wise mentor of mine once said, "the truth is something to be very careful with."  The control of information directly and indirectly translates into control over budgets, income, and even job security.  Sadly, if you are working in any organization which employs humans, you need to be careful.  You will run into a world of pain if you misunderstand what will happen to the flow of money in your company when you change the flow of information. 

Three patterns to look out for:

1)  "Good news up; bad news down."  Are there people in your organization whose entire job it is to make sure that the people at the "coal face" stay in a perpetual state of concerned stress that the project, the division, and even the company is on the brink of disaster, in order to "boost productivity?" Do these same individuals simultaneously feed their bosses a steady stream of nothing but good news, so they can bask in a shared sense of "good management at work?"
  • Double check:  I suggest that if you think this isn't happening with your teams, you should double check.  You will likely NOT know about these people, because they will look exactly like the people who are actually excited to work with you. Once you leave the room, they will order their teams to disregard everything you have said, and try to minimize further contact.  
  • New strategy:  Whenever you start working with a new team, ask yourself what each member of the management chain above the team has to gain or lose if information flows freely from the bottom to the top and back.  Plan accordingly.  Trust, but verify!
2)  "Let's keep the meeting small."  How many times do you hear this?  As an agilist you believe in having face-to-face conversations with small groups of people, preferably in person.  So you may be inclined to accept the "small meeting" suggestion at face value because you already think it's a good idea to set up a meeting that fits your mental model of how a meeting should be run.
  • Double check:  who wants to keep the meeting "small," and what is the reasoning for who gets included and who gets excluded from the meeting?  Who would you have at the meeting, all things being equal, and everyone being available?  
  • New Strategy:  "Small" is never value-free.  "Small" means that the person who wants to "keep the numbers down" wants to build a consensus strong enough to overwhelm the "extra people" who aren't being allowed to slow things down at the meeting.  That can be something you agree with or disagree with, but please be aware of it.  "Knowledge currency" is being actively controlled every time someone plays the "let's keep it to just us three" card.   
3)  "It Depends."  Are you an agile consultant, or do you work with consultant helpers who answer questions with "it depends" as a standard response?   If you are on the giving end of the "It Depends" response, please consider the ramifications.  You likely feel you are speaking from principle, from the heart, and from the Agile Manifesto.  "Don't lock anything down!" you say.  "Make them think for themselves."
  • Double check:  where are you or your consultant friends making their money?  I don't think there is any bad faith going on here, but I do think there is sometimes a "principled" withholding of practical information which is a pattern perpetuated by professional people who make their living doing a bunch of specific things very well.  
  • Double check:  if you are on the receiving end of the "It Depends" thing, and you aren't getting enough useful factoids from your consultants to let you do something in particular better than what you were doing before, why are you paying them?  And if you agree that what you are buying from them is that they keep you "hungry" for continuous improvement, why in the world is that happening?  Were you really not hungry before?  Why did you decide to hire them in the first place?  Where did you get that money?  Seriously!  
  • New strategy:  Parties on both sides of the agile transformation consulting contract need to remember that important concept from the Agile Manifesto:  people are more important than process.  If the people being trained on agile are already empowered, thoughtful, careful, intelligent and prone to continuous improvement, then they should set up an agreement to be trained by their consultants on new techniques with a minimum of philosophical lecturing or Socratic game playing.  If the trainees are in a broken culture which doesn't allow for individual initiative, then there still needs to be a combination of long-term strategy for fixing the culture, which can take a long time, and short term tactics for working with teams within their current limitations.  In neither case should the words "it depends" ever be uttered except as a preface for one or more options, and re-usable advice on choosing between them in the future.
So I guess that was a bit of a rant.  Sorry.  At any rate, I don't mean to be all "Mayan End of Time" here, but you know what?  There is no innocent use of information, and there is no innocent refusal to provide information--every communication is an act in the world.  Please be very thoughtful in your communication choices.

Sunday, November 18, 2012

Einstein's Sailboat: 3 Ways To Speed Learning for Agile Newbies

Albert Einstein turns out to have been both an awesomely brilliant physicist and an enthusiastic but comically bad sailor.  Apparently, he spent whole summers amusing his neighbors by capsizing frequently and needing to be fished out of the water.  You would think that he could be calculating wind directions and consequences in some small corner of his vast brain, while also solving World Peace, but you would be wrong.  Not sure about the World Peace thing, but he definitely couldn't sail.

From a post by "Angel" on http://www.boatdesign.net/forums/sailboats/einsteins-sailboat-tinef-40050.html.  Watermark suggests image wasn't obtained legally by Angel, but what a cool photo!
Einstein's difficulties have several points of relevance to you, if you are a person charged with helping people develop software in an agile way.  It's not just a parable--it's a valuable set of lessons learned!  Here's how to plunge forward in your agile training program with more speed and less splashing.

Speed Teaching Tip 1:  Brilliant High-Level Generalizations Are Not Your Friend When You're Trying To Learn To Do Something In Particular With Multiple Tricky Steps.  Some would-be agile trainers like to sweep their arms expansively and say "everything you need to know is in the Agile Manifesto!"  Or maybe they will agree to throw in the Agile Principles too.  In fact, I challenge you to find an "Agile for Beginners" deck that doesn't start with a little meditation on the Manifesto.  Yet how helpful is that? 

Did the Agile Founding Fathers write up the Manifesto first, and then derive their various methodologies from it?  No, they did not.  They tried a bunch of stuff, kept track of what worked and what didn't, wrote books, staked their intellectual property claims to some different specific methodologies like DSDM and Scrum, and then eventually agreed that the Manifesto captured some common things across those specific methodologies. 

Why, then, do we insist on teaching agile as though it can be derived from the principles instead of vice versa?  We get pointlessly tied into knots that way.  Let's not do that any more.  When working with beginners, you can skip those Manifesto slides.  I give you permission.  Which leads us to:

Speed Teaching Tip 2:  Maps, Checklists, and Procedure Descriptions Really Are Your Friend.  Airplane pilots reliably maneuver their crafts all over the world with far more reliability and far fewer accidents than the average American motorist, and let's just say we're glad Einstein didn't fly us to our most recent conference speaking gig.  How do the pilots do it? 

They use checklists to keep track of the details.  Yes, they have experience, knowledge of the principles of aerodynamics, and muscle memory, and no, they wouldn't be able to depend solely on checklists when conducting an emergency landing on the Hudson.  But they can focus on the things that take human execution because they have written down the detailed things they need to remember, and they make it a routine to consult those lists.

Would it be so bad to create a standard set of checklists for our software development teams?  How about if we stipulate that people can tailor the lists to their needs, and that the lists will change over time?  Complicated things lend themselves to being presented in a predictable order.  Which brings me to:

Speed Teaching Tip 3:  Just Use a Timeline.  When people learn, they need to attach the new information to old information in their brains.  Everyone's brain is going to do associations differently, but you have a fighting chance of attaching at least some information to everyone's brain if you organize your thoughts in chronological order.  Almost everyone you will ever present with a deck can relate to "beginning, middle, and end."  Organizing your agile presentation "topically" the way you think about it will drastically cut down on how much other people can actually absorb from you.  What unifies "Pair Programming, Sustainable Pace, and Evolutionary Design?"  Only you know.

There is something unbearably cute about the idea of Albert Einstein capsizing sailboats around the world in his free time.  But if large scale agile transformation is something you do for actual pay, I recommend stowing the brilliance and hauling out some dry procedural documentation, at least when working with beginners.

Friday, November 9, 2012

Technical Debt is Real Financial Trouble

Do you shun the people at work who hassle you with statistics about your company's software cyclomatic complexity?  Are you tired of this issue, frequently raised by developers whom you need, but whom you privately think of as highly strung prima donnas?  Do the words "JUST GO AWAY" not seem to work with these people?
From http://www.comicvine.com/prophet-of-doom/29-66484/
You and I may find this counter-intuitive, but it turns out these geeky prophets of doom have a point.  "Technical debt" has actually been proven in the real world to cost you money both directly and indirectly.  Lots of money.  Moreover, you incur additional security risks when you turn a blind eye to unnecessary code complexity.  Your current laissez-faire attitude towards code quality could actually turn into an unplanned financial catastrophe at an inconvenient moment in the future.

The "golden age" of research on costs of cyclomatic complexity seems to have been between 1990 and 1992.  A lot of the original work has perhaps been tainted for the modern agile audience because it was done to justify the use of Computer Aided Software Engineering tools (CASE), discussion about which has gone out of vogue.  But studies since the 1990s have consistently had the same results, and if anything, the situation has only gotten worse as the world's code base has grown.

Quick Technical Debt FAQ:

What is Technical Debt?  The phrase was coined by Ward Cunningham in 1992, actually.
Shipping first time code is like going into debt. A little debt speeds development so long as it is paid back promptly with a rewrite... The danger occurs when the debt is not repaid. Every minute spent on not-quite-right code counts as interest on that debt. Entire engineering organizations can be brought to a stand-still under the debt load of an unconsolidated implementation, object-oriented or otherwise.
Right, so it's just coders being fussy.  It's a matter of opinion.  Uh, no.  It is measured in terms of things that actually should be fixed quickly rather than allowed to linger, for actual business reasons.  Examples of this are not aesthetic or subjective.  They are countable things like:
  • High number of known open defects logged in your test repository.
  • Lack of an automated test base, so you have to pay a lot for manual testing in order to know from one release to the next what you might have broken.
  • High cyclomatic complexity, which is a term developed by Thomas J. McCabe, Sr., and is similar to the Flesch-Kinkaid Readibility Test.  It measures independent paths through a software system, if you consider all "if" or "case" statements, and the like.  A high score indicates high complexity.
  • High amount of duplication of individual lines of code.  This means that to "fix" it if it's wrong, you have to go more places and fix it more than once.
  • Very long methods Just as you have to put more effort into reading a blog than a tweet, a programmer has to work harder to make sense of an individual function or method of 1000 lines than of one limited to 100 or so.
  • SEI Maintainability Index -- a mechanical combination of this type of factors to a score indicating overall difficulty of making changes to the codebase as needed.
Why would those things translate to an actual cost?  As your developers would aver, it's fairly intuitive that it costs more to maintain something complicated than something simple.  They seldom describe this impact in terms of money, however.  So let's look at the two main scenarios where the problem moves from "coder stress" to "CFO expenditure."  I did a casual survey of the available interweb research and found the following.  A rigorous review would surely find more:
  • Routine Software Maintenance:  The original referreed MIT research on the cost of complex software in an enterprise environment found that when you control for other variables, "high levels of software complexity account for approximately twenty-five percent of maintenance costs or more than seventeen percent of total life-cycle costs."  This study was published in 1990, when state of the art for commercial software was COBOL.  One can conjecture that in modern multi-component software architectures, opportunities have arisen for even more complexity, and even higher maintenance costs.
  • Security Risk:  A 2012 white paper published by the Coverty company documents software "mistakes" which cost billions of dollars, and for Bank of America, a stock plunge of 15 percent.
Oh, I get it, isn't this is just a classic long-term/short-term decision about capital spending?  Well, yes and no.  The "short term" doesn't last very long on a project.  As Ward Cunningham said in the quotation above, shortcuts are fine for any given release, if your project is small.  On a large project, where you don't release for several months at a time, you can easily accumulate technical debt even before you deploy to market.  Technical debt doesn't age well.  It is a "payday loan" type situation, not the kind they advertise on the radio with "NO MONEY DOWN, NO PAYMENTS UNTIL JUNE!"  The longer you wait to fix the complexity, the more expensive it gets to fix.  Complexity gets added to complexity.  Like financial debt, technical debt compounds.

Your policy should be to maintain a constant state of low complexity except in exceptional cases, and then only with a plan to go back and fix the anomalous complexity immediately after the market advantage of the premature release has been enjoyed.

In the diagram above, "A," "B," "C,"and "D" represent different spending levels to get the same software written on behalf of your company.

A:  represents the money you are budgeting for total cost of ownership of your software today, which calls for paying no attention whatsoever to the financial risks inherent in your increasingly complex code base.

B:  represents the money you could be budgeting and purposefully spending to to avoid expensive maintenance and security risks.

C: represents the money you are spending today.  Technical debt isn't hypothetical.  You are spending 17-25% more than you should be on BAU software support, and that is a conservative estimate.  That's every single day.

D: represents the money you think your developers want you to spend on making the code "elegant."  And maybe they do.  But while you are busy trying to do "A" instead of "D," you have lost track of the opportunity to go from "C" to "B."

It's not just you.  In 2011, Andy Kyte at Gartner estimated that 60 years of accumulated technical debt has created a world-wide ticking financial time bomb worth $500 billion in 2010, with the potential to rise to $1 trillion by 2015.  What's worse is that every day, companies are spending billions just to keep maintaining this mess.  This isn't a "hypothetical" -- it is a cost to your business right now.  Can you really afford this?  Get a jump on your competition by systematically finding and eliminating technical debt the way you would any other serious organizational risk.

Monday, November 5, 2012

The Anti-AMM: Sculpture, Not Pyramid Building

Get a bunch of agile evangelists together, and we like nothing better than argue over the details of our favorite Agile Maturity Models (AMMs) over a few beers, the more complex the better.  "But HOW can you make a REAL DIFFERENCE until you TACKLE HIRING PRACTICES FIRST!" we holler, having (unfortunately) switched to tequila shots a little later in the evening.  Our client practices are raw boulders, and we are going to help them build a pyramid!
If only our clients will listen to us, we think, we can help them "start small," and gradually evolve into high-performing teams like the ones we're used to.  First they might try Stand-Ups and Burn-Ups, we say.  Then if all goes well, we will try test automation.  Refactoring for extra credit, but only once the analysts have been trained.  Sequence is all, and it gives us a lot to argue about.  Let's build that pyramid!
AMM rendering of the first verse of "The Sloth" by Flanders and Swann
Fellow agile thinkers--have we really stopped to think about what we imply when we use the word "maturity" to describe what we are helping clients build?  Our slide decks feature aggressive use of primary colors, and we tacitly use the word "immature" in close proximity to the words "CIO," "CQO," and "CFO."  What have we been thinking?  This isn't just wrong, it's bad business.

What we need is the exact opposite of a maturity model.  We need to know Nirvana in its pure and complete beauty, and then we need to let our clients help us to sculpt away our assumptions, to make our model even more useful.  We had it backwards:  clients aren't in the infancy of building our Nirvana state.  We are in the infancy of being able to cut Nirvana into the right pieces to efficiently help our clients.

What Does This Big Block of Nirvana Look Like?  First, let's freely admit we need to always have Nirvana with us.  It could even be a Nirvana borrowed from the top of someone else's Agile Maturity Model.  In Nirvana:
  • Product Management knows how to design a software product so that it can be tuned on the fly--try out the "A" and "B" models simultaneously, and if "B" makes more money, flip a switch and turn "A" off.
  • We can release new versions of software to production every week.  Hour.  Second.
  • We have room to make mistakes because we have a portfolio strategy which constantly checks to see that the return on investment for any given project is rising from one iteration to the next, not leveling off.
  • We're satisfying our customers in a fast-changing world, and our code quality is incredibly high, so we can change it on a dime and release something new tomorrow.
How do we do this in Nirvana?
  • all teams are small and collocated, and 
  • they work solely on brand new software, or maybe software that's a year or two in age, 
  • but all of it is swaddled in a Continuous Deployment pipeline 
  • hitched up to 
  • an automated testing framework that 
  • handles all possible levels of testing 
  • either at check-in, or overnight, if the thing to be tested takes a long time.  
  • Also, in Nirvana, all applications are web applications with virtually zero fixed cost for releasing to market.
All teams in Nirvana
  • are self-organized, and 
  • all members of those teams are team-oriented geniuses 
  • who understand that agile is not a fad, but a collection of productive goodness, 
  • who can do anything, and 
  • who would never let you down.  
There is no ill-will in Nirvana, no politics, no personal ambition except Getting the Job Done.  Everyone is competent and no-one is new, except for the occasional hyper-smart individual we hire and quickly train through effective use of pairing.

Sculpting Nirvana to Fit the Real World. How useful is our vision of Nirvana to the average executive?  Not very, especially when it is accompanied by an Agile Maturity Model that measures each company by how much it doesn't match, and calls for fundamental corporate change "before we can even get started."

What must we do to make our vision useful?  Stop thinking in terms of "maturity."  We're not looking to help clients build our ideal pyramid.  Or if we are, we have to stop.  We need to think instead of Michaelangelo's concept of the "non finito:" the thing of beauty constantly emerging from the rock.  Our clients are helping us evolve our vision by testing it against reality (again).
But concretely, if you will pardon the word, what do we do?  Here it is:
  1. Pack.  We pack up our big old block of Nirvana and take it with us to visit a client.  But we leave it out in the truck for the initial meeting.
  2. SWOT.  We have a SWOT analysis, whether formal or implied, with our clients.  Not just "what are your pain points," but "what are your opportunities and threats?"  Not "what are your software development processes," but "how can technology minimize threats to your business and capitalize on your opportunities?"  Think like a business person.  Think about increased revenue, decreased operational costs, increased customer satisfaction, creating a new market, lowering cost of business as usual, shrinking time to market, retaining the best staff and being a destination employer.
  3. Rethink.  In two stages:
    1. We take the facts of the actual client business situation, as we understand them, back to our block of Nirvana in the parking garage, and we start chipping away at our own assumptions.  Wow, our client is building middleware with a team on three continents, and they've been through three major "process engineering" fads in the last six months.  Gee, the product management group hates the technology people.  Hm.  The developers don't unit test, and they get mad when testers send code back to them to be fixed.  Yikes!  Eight different "stage gates" with hundreds of employees who will lose their jobs if we try to cut down the bureaucracy.
    2. Once we have thrown away the "all or nothing" view of Nirvana, what can we propose from our Agile bag of tricks that will actually give our client a positive return on their investment for hiring us?  What reasoning and proof can we give that our suggestions will work?  What can they do in 3 months?  A year?  3 years?
  4. Propose.  We go back to the client with a "business proposal," not an AMM.  We suggest things that can be done in 3 months, a year, or 3 years.  We give them our price points for helping them reach these achievable goals, and we give them metrics to suggest why they will see a business return on their investment.
  5. Drive home.  Note that nowhere in this process do we force the client to come out to the parking lot to view our big old block of Nirvana.  It is a model which is the thing that powers our thoughts and provides bounteous patterns to us in every engagement, and it's something we keep refining.  But it is our luggage, not theirs.

Wednesday, October 24, 2012

Two words for Agile Business Analysts: Pan and Zoom

Do you have trouble wrapping your arms around the question "what do Agile Business Analysts do?"  I figured it out today!  And I will tell you!  And as a special bonus, I figured out what the Waterfall BAs do too--so if you didn't know, and you were worried--and who among us isn't--you can kill both birds with one blog.

Business analysts of every ilk do two things really well:
  • They look at the big picture end-to-end.  They are able to describe concisely what your project is doing and why.  They are czars and czarinas of the "elevator pitch."  They see it all, and they make sure everyone else on the team sees it too.
  • They look at every detail of your project pixel by pixel.  Who is the person in the room most likely to say: "wow, paragraph 4, sub-element 2 totally contradicts that chart on page 3 in the leftmost column."  The BA, that's who.  They are razor sharp.  They are intolerant of errors.  Any errors.  A BA is probably reading this saying "'any errors' isn't a complete sentence, Elena."
In other words, they "pan" and they "zoom."  The best BAs are unlike most other people in their ability to do both of these things really well.  So let's look at the difference between Agile BAs and Waterfall BAs.
From http://chocolatecamera.blogspot.com/2011_07_01_archive.html

Agile BA:  Mostly pan then mostly zoom.  A business analyst in an agile project separates panning from zooming, for the most part. 

During the project startup, the Agile BA keeps the team in "Pan" mode, even when they don't like it:
  • The agile BA works with business subject matter experts to diagram a complete end-to-end story map describing the new software system to be built, in words an executive could understand.  Three features with accompanying profit and loss.  That type of thing.
  • The agile BA enforces the discipline of considering system features holistically, and they get the team to determe what the minimum features need to be for the first software release.  And then they make the team let go of those other features for now--we wrote them down.  We'll get to them later, but now we need to focus.
  • The agile BA does the hardest thing of all in a project inception phase:  they break those big features down into smaller pieces without going into detail.  What kind of heroes are these, who can divide some big data loading widget into 45 smaller parts and never once allow the team to descend into a discussion around a naming convention?  Agile BAs, that's who.
Once the project has moved into the familiar pattern of delivery iterations, the BA ensures that zooming occurs.  Lots and lots of detailed zooming:
  • The agile BA ensures rigor around the way the requirements are expressed, even on teams with a single Product Owner who sits with the team.  The BA champions a standard format for capturing needed information, whether it is verbal or written.  Yes, even on a team that is collocated, where very little needs to be written down, someone needs to understand the details.  On a team of more than four people, one person may specialize in knowing the details, and that person will be your BA.
  • On more complex projects, the agile BA may need to convene meetings with widely dispersed subject matter experts, get those people to focus, and record their decisions, still in a standard format.
  • On really challenging agile projects where SMEs are dispersed and team members are even more dispersed, and all five continents are represented, the agile BA will maintain a coherent written set of documentation and a network of local experts to help everyone navigate through it.  And every detail will be right.
In the mean time, of course, the agile BA has not lost sight of the big picture, and typically leads discussions during "Backlog Grooming" meetings during each sprint, to ensure the big picture is kept up to date as the team learns things.  There's still a little "panning" that must go on, and the agile BA is flexible enough to be able to do this, even while focusing on details.

Waterfall BA:  Pan and zoom all at once.  Once you understand how an agile BA functions, it's hard to understand how waterfall BAs manage to do what they do.  Waterfall BAs are asked to both pan and zoom at the same time.

  • During the early phases of a Waterfall project, the Business Analyst is asked to write a virtual novel.  Every chapter must be there, and each chapter must be complete and perfect, down to the punctuation.
  • During the Waterfall "development" phase, where the software is actually being written, the BAs are asked to participate in a process called "Change Management" in which they are required to locate and fix things in their large-scale requirements document as the business changes its mind, and the developers run out of time.  In fact, at the end of each Waterfall release, everyone runs out of time, and the software will never quite match the requirements.  There just isn't enough time.
The truth is that ONLY a waterfall BA can fully understand the documents they write, because these documents are long and detailed, and people on the team who specialize in development or testing don't have time to make sense of a huge binder full of text, even if it's online.   And only a waterfall BA could bear the drudgery of revising their encyclopedia of requirements over and over again, every time something changes.  Waterfall BAs are heroes too, and what they do is really hard.  But we shouldn't ask them to do it in the first place.

As a member of the Business Analysis community, I need to end by saying that the "pan" and "zoom" analogy suggests that BAs are nothing more than "order takers" who somewhat mechanically record the world around them.  I hope the details above make it obvious that nothing could be farther from the truth.  Equating a good BA with a camera, because both can pan and zoom, is as silly as saying that chewing gum is equivalent to Crème brûlée, because both of them make snapping sounds.

Friday, October 19, 2012

The Agile Lumberjack: Why Batched Requirements Are Not As Sensible As You Think

Let's say you're a Business Analyst, and you're okay.  You've done your job for years.  You are a subject matter expert in your own right, and you get the job done. 

Suddenly, a sparkly-eyed Agile Guru (SEAG) shows up at your workplace and asks you to stop writing a "requirements document" that holistically describes the software your developer friends will be building.  Instead, the SEAG insists that you use a set of index cards to "hint" at what needs to be built, tape the cards to a wall, and plan to focus on the details of each card later, right before the developer starts to build it.  And maybe you won't even write those details down then, either.  You'll take the "hint" from the card, have a "conversation" with the developer, everyone will nod enthusiastically, and off you go to find out more about a different hinty card.

Really, when you put it that way, it sounds totally crazy.

This is why some analysts have a very hard time with agile at first.  Analysts are the conscience of an agile team.  They are the people who draw the big picture from tiny, precise details.  They get the details right, but they can always place the details into a larger context.  They see the forest because they can see the veins on the leaves of every tree.

Why in the world would you NOT want to develop software in such a sensible way?  Aim, then shoot, you might say.  Map, then deforest.  And so on.  Actually, no.

What Toyota learned in the 1950s competing with Ford is that you have to be very careful about building your "economies of scale."  It might seem to you that it's more efficient to "just sit down and write all the requirements at once" than to intersperse writing requirements with developing software to meet the requirements, but empirically this is not so.  Consider this schematic view of a simple development life cycle -- requirements, development, and test of 10 software widgets:
Diagrams based on a really wonderful blog at:  http://rasmusson.wordpress.com/2008/04/16/batch-vs-continuous-flow-processing/

Done in the "economy of scale" requirements batch, followed by a development batch, and then by a testing batch, the first widget rolls out to your production web site after 51 hours, or maybe you wait to do a release, and all 10 widgets roll out in a total of 60 hours.  Nice.

But what if instead of batching the work by "role," you instead batched it by "widget?"  Viewed from solely your perspective as an analyst, it seems uncomfortable.  But if you think in terms of the whole system, this mode of operating is amazingly efficient.
You do the requirements for just one feature and hand it to the developers.  Then you move onto the second.  You work continuously on just one requirement at a time.  Devs work on building just one widget at a time.  Testers work on just one set of tests at a time.  The regrouping makes a remarkable difference in terms of time to market for your widgets.
  • Let's say you decide to release all of your widgets to market at once, once they're all tested, and let's say each widget earns your company $10K per hour once it is deployed.  Your "group by widget" strategy earns the company $1.8M more than the "group by role" strategy did ($10K times 18 hours times 10 widgets)
  • But if you have the flexibility to release your widgets to your production site as they get done, the benefits are even greater.  The first widget gets done in 12 hours rather than 51.  If this is a money-making widget for you, and it's worth $10K per hour to your business, that difference is worth $390K for just the one widget, and you get an additional influx of revenue for each widget that comes in ahead of the eventual 60 minute mark.
You will notice that this system still isn't optimal.  What would make sense would be to see whether the development work could be split into smaller pieces and done in parallel, so that the elapsed time per widget would be 1 hour for requirements, 1 hour for development (because you would have 10 developers for each analyst), and 1 hour for testing.  Now we're talking about bazillions of dollars difference in revenue, more than enough to make up for staffing the additional developers.

This is one of the big reasons why big Web companies like Amazon.com are so excited about agile.  They have widgets that can make this much money.

And no matter what software you are building in your company, you can benefit the same way.  Even if you have to wait to release software on some regular cadence, like quarterly, each release can have that much more software in it, because you batched by feature, not by role.

Which brings me to one final point.  Often times, new agilists think that "agile is just doing waterfall over and over again, really fast."  A team new to agile may take the time they have to develop a piece of software, and divide it into 4-8 week iterations.  In each iteration, the analysts do requirements for the first week, the developers do development for the next three weeks, and the testers get everything at the last minute, and then get blamed for bad quality.  You know they do.  You've seen this before.  Only it used to take 12-18 months, and now it happens monthly.

"Rapid waterfall" is really just the worst of both worlds.  You still have people sitting idle part of the time, or else you evolve some kind of "overlapping rapid waterfall" where everyone is working on three iterations at once to "keep busy."  So don't do that!
Do the stuff the SEAG tells you to do.  Break the work into small "stories," and work as a team to move the stories from "not started" to "done" as individual units, keeping the flow constant, and not waiting for some artificial whistle to blow somewhere to announce that "now it's time to start developing."  That's why we have a card wall.  The smaller your units of work, the more productivity you can squeeze out of your system.

You didn't want to be a lumberjack anyway!

Sunday, October 7, 2012

5 Reasons to Embrace "Cafeteria Agile"

Agile enthusiasts are quick to make fun of people who pick and choose among various agile concepts, philosophies, techniques, and tools, rather than working hard to be "pure."  We have a word for people who do that:  dilettantes. 

From http://lifeasareader.blogspot.com/2010/11/i-am-cafeteria-catholic.html
But when we use two words we call them "cafeteria agilists."
  • If a software development team has a burn-down chart, weekly releases of something to production, and no discussions with the business, ever, we are quick to chorus "THAT's not AGILE!"  
  • If they have a great working relationship with business partners and talk daily, but managers still do estimates of work durations, and assign work to the programmers and testers, we roll our eyes, and we start to abbreviate:  "TNA!"  
  • If a team deviates from any named agile technique, be it Scrum, Extreme Programming, Crystal, or WaterScrumFall, and even if they follow that last one to the letter, "TNA!"  If they use UML these days, or even Use Cases, "TNA!"  
One almost wants to design a t-shirt with "TNA" on the back in flashing letters, since it's a saying that fits almost every real-world situation you'll ever see.  It's fun to make fun.  And to some degree this is human nature--why would you choose to help a company "suck a little less" when you went into this business to change the world?  Seriously.

I have five quick defenses for "cafeteria agile:"

1.  People Have Label Fatigue:  Today's business people are tired of fads, and tired of labels.  Flying the "Agile" flag for this audience not only isn't good--it's actively going to get in your way.   Unless told otherwise, when you address a new audience, you should assume that they think you're here today to represent a management fad.  All your listeners can think of is "the guy doing Six Sigma wore a blue track suit, not a rainbow one," or "the TQM lady had a cuter English accent."
  • They do not want to lie on their backs on blue towels and listen to blurry cassette players through headphones, as they did with the PMP trainer.  
  • They do not want to do "Jeopardy" skits, like they did with the Tech Leadership trainers.  
For the label-fatigued audience, your best bet is to avoid using the word "agile" altogether, listen closely to what they have to tell you, figure out how to best help them from your treasure trove of agile philosophies and techniques, and just do those things first.  One day they may forgive you for being an agilist, and one day they may develop an interest in the Manifesto.  But in the mean time, what about giving them something they can use?
From http://www.oempromo.com/Tools-and-Hardware/Measuring-Tapes/index_25.htm
You're going to win more friends with useful piecemeal advice than you can by taking a hard party line that it's all or nothing.  Which is related to:

2.  It Takes Time to Change the World.  Think of each Agile Cafeteria choice you ladle out to your client as a "thin slice" of a bigger system.  What time frame did you have in mind, when you came in to do your "agile transformation" of this group?  A week?  A month?  18 months?  It's amazing how you can take a group of sophisticated software developers who understand about "incremental delivery," "refactoring" and "thin slicing," and have them despair when they aren't able to do a "big bang" change to the software development processes in a company of any size:  lock, stock, barrel, culture, tools, and team rooms.

Although "social epedimic theory" suggests that a "biggish" bang may occur along the way, you're likely going to have a long incubation period when you're slowly wooing your audience by feeding them measurable returns on the money they have invested in your agile advice.
From http://blogs.cornell.edu/info2040/2011/11/08/viewing-the-world-tipping-points-and-social-epidemics/
You may need to swallow your pride and just provide your audience with a few key things to try that will pay off, and then spoon feed them a little more the next time around, and the next time, and so on.  Later they will understand that they were short-changing themselves, but they can't hear that message from you now.  Which is related strongly to:

3.  Client Executives don't want a generic label.  They want something they can brag about specific to them and relevant to their own context.  There's a reason most consultants do a thing called "pain point analysis" early in their engagements.  If you know what the company's pain points are, you can design a strategy to help with those things that matter to your employer.

You may feel "TNA" if the team isn't collocated.  But if your sponsoring executives are going to live or die at the end of the year based on the ROI on some big project you're helping with, and what they're looking for is low investment and accelerated revenue, you won't make yourself popular by insisting on an expensive relocation of the entire offshore work force.  Find out what they care about and deliver it, making sure they get the credit for all of your ideas.

Executives will seek you out if they hear that you can selflessly solve their problems and make them look good.  They are less likely to feel a strong motivation from a person who comes on strong with the message "look!  you're doing this simple thing all wrong!"  Which brings us to:

4.  The Prix Fixe menu makes it hard for YOU to claim success too.  If you spend any significant time with agile evangelists, and you will quickly find that the "definition of how agile we are" quickly gets mixed up with the question of "how are we making software delivery better?"

Let's say your "definition of agile" is that software goes from idea to production in a week, every week.  You work with a pilot team to make this goal a reality.  You claim "Victory!" and then suddenly find yourself stalled.
from http://scienceblogs.com/strangerfruit/2008/05/02/national-mission-accomplished/
Let's say it turns out that your company mostly has customers who can only absorb change once per year, and then only with a LOT OF TRAINING.  The project where you were able to instantiate your idea of agile was an anomaly.  If you're measuring your "agile penetration" by the percentage of the portfolio going to production every week, and also calling that your "success," you've just boxed yourself in quite thoroughly.  Don't do that!

5.  Don't Be The Thing You're Fighting Against.  What do we agilists want to stand for?  Change!  Agility!  Flexibility!  The last thing we want to do is get locked into some rigid set of "dos" and "don'ts."  Do you seriously want the next generation of rebels to laugh at you?  No!  Have some self respect.  Be a cafeteria agilist, and be proud of it.
From http://www.huntsvillerewound.com/athens.htm

Thursday, September 27, 2012

Your Agile Transformation Needs to Start with a Quiet Phase

From a really great blog post on agile adoption:  http://smoovejazz.wordpress.com/2011/02/16/an-agile-approach-for-adopting-agile-practices/
I've observed some different agile transformation patterns, and maybe you have too:

Just Do Standups  (Shoot, then Aim):  some people feel that since you're "agile," you should just start doing stuff, like daily standups, and then build more of the the plan as you go.  Find a team and start doing some agile with them!  Start a revolution one practice at a time, one team at a time.
  • Pros:  you're very busy from the start.
  • Cons:  what exactly are you doing and why?
KPI-Driven Change (Aim, then Shoot): some people who have worked in large corporations for a while will tell you that to get the respect of the people, you need to start with a plan, support the plan with awesome printed and online collateral.  Then you "kick off," tell teams what to do, and measure them using "Key Productivity Indicators," KPI, to see whether they are good at the new thing you want them to do.
  • Pros:  you know what you're doing and why
  • Cons:  you could fail in a big, public way.  Live by the KPI, die by the KPI.  Unless you lie.
I'm not going to call "Do What You Want And Lie About It" a strategy, but it certainly is a pattern.

Plan-Do-Check-Act (Shoot Something Easy To Hit Successfully, Then Move On to Bigger Game):  W. Edwards Deming's PDCA takes out a lot of the risk out of KPI-driven change.  In this pattern, you plan something small, try it out as a pilot, verify that the small thing worked as expected, and then try it with any needed modifications on a larger scale.  You can create a whole program as a series of PDCA cycles.  You could even create your own new acronym, PPME:  "Plan, Pilot, Modify the bigger plan based on the pilot, and Execute for real."
  • Pros:  you never bet more than you can afford to lose
  • Cons: depending on when the review cycle occurs, it may not look like you've done much while you're still doing small pilots.
So here is my personal revelation for the week.  You can even improve on Plan-Do-Check-Act, even though it's designed to not allow for anyone to trump it, ever.  Think about it.

What if...

...you could LOOK like you were doing massively successful KPI-driven change, to impress all your command-and-control enterprise buddies, but you could control the risks the way you can with the PDCA method?  Allow me to introduce you to a standard practice of large-scale fund-raising:

The Quiet Phase (Don't Declare the Plan Until It's Already Succeeding):  An organization-scale transformation is extremely analogous to an institutional fundraising "capital campaign."  Just as you want to get a lot of your target employees to start developing software the agile way, fundraisers want to get a lot of target donors to actually give them money.  It's not clear what's hardest to do, and I suppose it partly depends on the economy.  But at any rate, suppose we stipulate that "raising billions of dollars is difficult," for purposes of the argument.  How do fundraisers do it?

Fundraisers always start their campaigns with a "quiet phase," in which a small number of "capital gifts" fund-raisers make personal appeals to large scale donors, asking them to help anchor the campaign.  Studies have shown that the most successful campaigns actually raise up to 40% of their targeted funds this way before the campaign is even announced.  So when the campaign kicks off, it is already successful.  (There also turns out to be an analogous "goal line effect," which is that a huge amount of donations come in after the campaign reaches 95% of its stated goal).

What can we learn from this?  If you need to do a very large transformation, plan to start by spending some time on a series of "Quiet Phase" Plan-Do-Check-Act pilots in a very "Lean Startup" entrepreneurial mode, tracking what works and what doesn't, and racking up success stories.  Once you know what important wins you are likely to gain at scale, and, more importantly, once you have actually achieved some important wins at scale, THEN do your kick-off and announce your KPIs.  You give the impression of having an incredible ability to succeed from the start, because you've made your mistakes before you were out in public.  And the people who had the "behind the scenes" view of the quiet phase feel all the more important because they were in on the ground floor.

As one of my awesome colleagues says, "perception is reality."  Make perception work for you, by setting the reality first.

Sunday, September 23, 2012

Tips for Those Suddenly Traveling Frequently

Do you suddenly need to travel a lot for work?  If so, here are some helpful ideas.  I'm not getting kick-backs from any of these companies--I just like some of these products and you might too!

Tiny laptop:  some people really can't deal with a tiny laptop, but if you can, then you should get one.  I have the 11" MacBook Air, which fits into my purse.  It's about the size of an iPad, but it's an actual laptop with an actual keyboard.  By the time you get the iPad case with the keyboard built in, you're carrying more weight than you would be if you just got the MacBook Air in the first place.  I'm not one of those Apple fanatics--I swear by my Android phone, and scoff at iPhone 5 users who are suddenly discovering spoken turn-by-turn navigation.  You can also get a tiny Intel-based PC.  The chip isn't the important thing--it's the size of the overall laptop and the screen quality that matter.

Suitcase:  avoid checking your bag.  One day they will lose it.  This is not an "if" proposition, but a "when."  Have you visited that store in Alabama where they sell stuff people have lost on planes?  Find a way to fit all of your stuff into a bag that will fit in the overhead bin of a normal plane.  My favorite bag is the Zuca Pro, because you can sit on it in an airport.
Note, one time I was traveling through Calgary on a slow day, and they brought all of the security people over to watch me unpack the bag, along with all of the little travel pouches.  But that's only happened once.

Also:  if you want, you can order flashing Magneto LED wheels for your Zuca.  I totally did!

Travel bottles:  But Elena, you may say, if I can't check my bag, how can I bring enough of my special shampoo and conditioner with me?  Exactly.  You do not have to rely on the drugstore "travel bottle" selection, which inevitably seems to consist of 2-ounce bottles of Head and Shoulders, even though the TSA will allow you 3 ounces.  For viscous liquids such as shampoo or face cream, I recommend the Humangear "GoTube 3," because these bottles hold 3 ounces, and are easy to fill or clean.

However, the GoTubes are not good for clear liquids, such as single malt whiskey.  Don't even ask.  Just buy those little travel sized bottles of alcohol for your in-flight and at-destination alcohol-related emergencies.

Loyalty programs and loyalty program credit cards:  if you're just about to start traveling all the time, figure out which airlines have a hub in your home airport, and which hotels your company wants you to stay at, and enroll right away into their frequent flyer or frequent visitor programs.  Make sure you get credit for all of your flights, stays, and purchases.  It adds up quickly to free flights and free hotel stays.  Even more importantly, once you get a few miles on your airline of choice, you start being upgraded to the not-coach seats.
Always bring a bathing suit so you can use the hotel pool and spa as needed.

Popup travel laundry hamper:  I'm not Ms. Neat Freak, but each day when I am on the road, I like to be able to tell the clean clothes from the used ones, in case I meet someone important who might regret my second day underthings even more than I will be.  If you get a popup hamper, you just set it up in your closet, and throw your already-worn clothes into it, leaving the others safely out for later use.  At the end of the trip, dump everything back in your suitcase willy-nilly and wash it when you get home!
Note, you will need to be able to figure out how to twist the little suckers up into a tiny 6" diameter circle, but surely you can do that!

Auxilliary power for all your gadgets:  I accidentally bought two different "extra power" gadgets to charge my phone before I realized that if I just got a USB charger for each gadget, I could charge everything on my laptop.  Don't do what I did.  Buy the cheap USB adaptors and just use your laptop as an extra battery in car, plane, and train!

Jersey clothes:  not the state, the fabric!  Jersey is your friend.  No-wrinkle, shake-out, washable, drape-able, fabulous!  Also, ballet flats, if you are woman-identified.  They take little room in your Zuca, and they do not hurt you.  Also, take a Pashmina to keep you warm, and leave the six chunky wool blazers at home.  Also, no-iron cotton shirts, if you are man-identified.  Same as Jersey, but masculine.  And for both genders (and those who go beyond gender), there is a whole new generation of wrinkle-free cloth you can use to make suits and jackets and things.  No-iron is your friend.

Appropriate planning for having mobile phone/text service, if you are traveling abroad.  My extremely beloved AT&T Samsung Galaxy III from the US, for example, does not work in India or in Hong Kong.  There are several mitigations you can consider (Lord knows I wish *I* had!), including getting a country-specific SIM card that you put into an unlocked phone that you carry around in addition to your home country smart phone.  But at minimum:  have some device with you that is wireless-capable, so you can email for help from Starbucks world-wide.  Ramp up the complexity of your phone strategy from there (portable routers!  internet phones!  service to forward your home number anywhere in the world!  skype or facetime on your tablet with wireless!  so many choices!  But all of the choices will be easier to put into action if you research and plan for them from home before you leave).

One last reminder in this category:  if you have a phone that already works on networks outside your native country, you should turn off "roaming data" to avoid HUGE phone bills, and you should arrange for an "international calling plan" with your home phone company.

Also for those traveling abroad:  talk to your credit card company before you go, to let them know where you will be and find out what restrictions they have.  I found out at an inconvenient time (when the tailor was delivering my custom-made clothes to me at a hotel in India) that my beloved credit card company will not allow transactions of a certain magnitude if the merchant sells garments.  Supposed garment transactions are apparently a big money laundering scam, or so my credit card company informed me on the phone call from my hotel room that cost as much as the clothes (see "arrange for a working mobile phone" above).  It was awkward, to say the least, and eventually I had to withdraw the money from an ATM in order to pay him.  So I suppose the additional points here are:  have multiple cards, and make sure you have a card you can use to withdraw money from ATMs as well as pure "credit" cards.

Also, of course, make sure you always know where you can find an ATM.  You might expect that hotels will have them in the lobby.  This is a classic case of "trust but verify."  Speaking again from sad experience.

Add your own!  This is the audience-participation part of the blog.  If you have additional travel tips or product recommendations, please add them!  And have a really nice week!