logo design...copyright Elena Yatzeck, 2010-2015

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.