Monday, March 30, 2009

You've Got Mail (Like it or Not)

One major difference between "pure Agile" (the idealized process with its roots in small software companies) and Agile for the Enterprise is the necessity of managing distributed teams. In a multinational company with thousands of employees, it's nearly impossible to get an entire project team -- not to mention that ubiquitous cloud of stakeholders -- to work in one place. In this environment, asynchronous communication (through email, wikis, discussion forums, etc.) is critical to project success. To be a truly effective force for good in your projects, you need to be able to use these tools – and the short written message – to clearly communicate, coordinate, and collaborate with your project team.

So what’s the big deal about email? We’ve all used it for years and some of us can barely remember a time when it didn’t exist. Can’t we just send email at work just like we do everywhere else? Well, that’s the problem: some people do write emails at work just like the ones they write at home: unintelligibly.

Communication in any form is a two-edged sword. A well-written phrase can instruct, uplift, and inspire its readers. A poorly worded statement, whether spoken or written, has just as much power to confuse, distract, and annoy. How you use your communication skills comes down to a simple question: do you want to serve the dark or the light? For now, let’s assume you chose light. The next question is, “How can I make sure that my emails are helping to move my project in the right direction? How do I avoid being one of those people who elicit groans every time their email hits someone’s inbox?” Here are a few tips:

Know your audience
In order to have any impact at all, your message has to reach its intended audience. To do that, you have to make it through their filters, and that means tailoring your message and style to the needs of your readers. It also means resisting the urge to copy the entire world on every email, since it’s impossible to reach everyone with the same presentation. Your message should meet the needs of your audience, not the other way around.

So, to whom are you writing? Is it a group of analysts or a QA team, looking for detailed technical answers? Then send them specific details, organized in a manner that lends itself to easy review. Are you writing to a busy executive? Then make sure that the subject line is clear and all of the relevant information is in the first two paragraphs, because there’s a good chance that he or she won’t read any further. Are you broadcasting a status report to large group of project team members and stakeholders? Then format your message so that it can be easily scanned, using bullet points, short sentences, and bold type to highlight key points.

Keep it short
Save the long, rambling descriptions for your novel. Business email is about providing relevant information in the most condensed format possible so people can get what they need and get back to work. Your emails should be short and to the point, and that point should be clear.

This doesn’t mean that all emails should be no more than 500 characters long; some topics require a bit more space, and email may still be the best way to present them to a group. Just understand that email inherently encourages short attention spans, so your 2-page missive will likely never be read in its entirety. Prepare to be skimmed:

  • Keep your paragraphs short and use bullet points and headings to organize the information. Give your readers the visual cues to get the information that they need now and to find the other information in a second pass.
  • Place your critical points at the top of the message, rather than saving them for a grand and stirring conclusion.
  • Be prepared to calmly send people back to your message when it’s clear that they didn’t read it.
Of course, a bias toward brevity can also be taken to an unhealthy extreme, resulting in a barrage of one-sentence emails running back and forth between people as one person’s cryptic replies only lead to more requests for information. Keep it brief, but make sure that you provide all of the information that your readers need in a way that they can comprehend it.

Think before you send
There are times when the temptation to blast someone off the face of the earth with a cleverly phrased flame mail is so strong that you can taste it. At other times you may just be annoyed enough to send an intentionally unhelpful response without being overtly unpleasant. You may also want to complain to one person about someone else (all in the interest of “team-building,” of course). Before you hit send, remember two things:
  1. These words are about to leave your control and could be sent to anyone in the world
  2. This message will live forever on various email servers and archive tapes, the living legacy of your presence on this project

Are you still ready to release your thoughts into the wild? Then go for it. Otherwise, you might want to close that email window and go take a walk.

Know when to kill the thread
We’ve all been part of it: the Thread That Wouldn’t Die. Usually it’s the offspring of one or two people hitting the Reply to All button like genetically enhanced lab rats trying for one more food pellet, spewing multicolored questions and responses and “see my comments below” back and forth through the ether while the rest of the world looks on in frustration.

Don’t feed the beast. As a general rule, if you find yourself writing your third reply to the same email thread then it’s probably time to settle things in person. Pick up the phone, walk over to someone’s desk, or schedule a meeting with the people who still have questions. If the emails keep coming, send a polite reply saying, “I’ve set up a meeting to discuss this. Let’s kill this thread for now and I’ll publish the results after we meet.”

The written word will never die out as long as email and its compatriots are around to keep it alive. Harness its power today and make life better for everyone on your project.

Friday, March 27, 2009

Go forth and be Agile!

As Thomas Hobbes observed in the 17th century, “Life under mob rule is solitary,
poor, nasty, brutish, and short.” Life on a poorly run software project is
solitary, poor, nasty, brutish, and hardly ever short enough.
- Steve C
McConnell, Software Project Survival Guide
Everyone who has worked in software for more than a few years can probably relate to this observation. Software projects seem to lend themselves especially well to two things: fantasy-based planning and painful and repeated collisions with reality. Smart development organizations, tired of hitting their heads against the same wall over and over again, are looking at a new way of building software: Agile development. But life on an Agile project is different, and people need new skills to succeed when the easy stages of the waterfall are stripped away and they dive into the Agile whirlpool. Here are the five Agile commandments that every team member should know (we had ten, but we broke them into two releases):

I. Thou shalt prioritize
In a waterfall project everything is high priority, until it isn’t. When you take that big pile of work and break it into iterations, though, you need to distinguish between “kinda high priority,” “really high priority,” and “really REALLY high priority.” For best results, you should rank all of your requirements from 1 to n and work through the queue in order.

Prioritization is a rare skill. It requires you to find the balance between two factors – value and cost – and to not only quantify them but understand and be able to describe them in detail to a variety of audiences. Value means different things to different people. To the marketing person it means, “I could sell that to our customers in a moment.” To the business user it means, “That would finally make it possible to do my job painlessly.” To the technical architect it means, “Until I get that, I can’t build any of this other stuff they want.” You have to be able to capture all of those definitions and translate them into a simple statement: “This element of the application is more important to us than that one.”

Cost is both simpler to describe and harder to specify: it’s the effort required to build a component, but no one knows exactly how long that is until it’s done. You can get a relatively close estimate once an application is designed, but it’s nearly impossible to make accurate estimates early in a project when you need to set priorities. Usually, it’s good enough to say, “That’s easy, and that’s hard. And that? Just thinking about it makes my head hurt.” Balance that with the value, and priorities emerge. Do the easy-but-valuable stuff first and save the interesting-but-nearly-impossible features for later.

Of course, before you can prioritize things you need to know what they are, which brings us to…

II. Thou shalt break it down
Waterfall projects, even relatively short ones, are monolithic by nature. You gather all the requirements, then you design the whole application, then you build all of the features for the release, then you test the whole application at once. Throw in a few stage gates and signoffs for good measure and you’ve got yourself a project! Agile development breaks this concept down, in more ways than one. Rather than assuming that we can know all of the requirements before we even start, we assume that we will learn as we go. Rather than requiring formal signoffs and then locking down any further changes, we build in checkpoints to review the application and add any new features that we feel will make it better. Rather than building everything at once, we build the most valuable features first and let people start using them as soon as possible.

In order to build this way, you need to be able to take large problems and break them down into small ones, a talent that is surprisingly rare in today’s business environment. We all know how to take small problems and make them into crises – thirty minutes watching CNN will show you that – but we struggle when asked to make something simpler. Just as a run-on sentence can be broken into shorter and clearer sentences, so a convoluted system requirement can be broken into its functional components. Learn to do this and you are on your way to (capital A) Agility.

III. Thou shalt communicate wisely
In a waterfall project, formal communication is the rule. Agile development, however, replaces static documentation and formal handoffs with person-to-person communication and collaborative problem-solving. If you jump directly from one to the other, significant chunks of important information will be lost. You need a strategy to broadcast the results of meetings, to capture decisions where everyone can see them, and to maintain a living documentation set that accurately reflects the current state of the application. Rather than relying on giant documents set to educate latecomers, newcomers, and drop-in stakeholders on what you’re building, you need to create 10-, 20-, and 30-minute pitches that present the project in varying levels of technical detail.

Agile works best when everyone knows what everyone else is up to. In the absence of a hive mind, however, you must be mindful of the information that you possess. After every decision, ask yourself, “Who needs to know this, and how should I share it?”

IV. Thou shalt go with the flow
Waterfall projects are like marching band music: regimented, slow-moving, predictable, and often ending with a noisy crash. An Agile project is like jazz: within a tight structure, the players are free to improvise to make the end product as beautiful as it can be. To succeed in this environment, you need to let go of your concepts of how things should go and concentrate on getting to the destination. The important thing on an Agile project is not what we thought we were doing yesterday, but what we need to do today to reach our goal. Once you are able to make that mental adjustment, to focus on that target on the horizon even as you make minute course corrections, you will be able to increase your personal efficiency and your team’s velocity.

As Stephen Covey says, “Start with the end in mind.”

V. To thine own self be accountable
On an Agile project, there’s nowhere to hide when you don’t meet your commitments. You meet with your team every day to discuss what you did yesterday, what you plan to do today, and where you need help. When you miss a deliverable, the person sitting next to you is immediately affected. The traditional waterfall excuses – “That wasn’t in the spec,” “The requirement was unclear,” “I’m waiting for the documentation signoff,” etc. – don’t work, so you have to actually do what you said you would do.

Believe it or not, this is shocking to some people, who find the long silences that greet their daily status reports increasingly uncomfortable and must decide to either start working or go find another project to hide in. High performers find this environment invigorating, though, as they are finally able to just do their jobs with a minimum of obstacles. If you are ready to take the credit and the blame for what you do every day, then you’re ready to go Agile.

So, there you go. As the Lord said on the eighth day, when he created programmers by mixing silicon, Doritos, and coffee: “Go forth and be Agile!”

Tuesday, March 24, 2009

Brother, Can You Spare Some Change?

Jumping off the waterfall and moving to an Agile approach is an exercise in organizational change, and let's face it: human beings hate change. From the earliest caveman to his modern equivalent in the ratty "Evolve or Die" T-shirt, the whole of human history is a long, losing battle against change. Empires rise and fall, civilizations are built up and ground into the dust of the ages, but one constant remains: there's always someone at the top trying to get everyone to knock it off and be satisfied with the way things are.

Of course, few people will admit this dirty little secret, even to themselves. We like to think of ourselves as dynamic go-getters, innovators -- dare we say it? -- change agents! No one wants to be accused of perpetuating the status quo, making the same old mistakes in the same boring ways. The truth, though is that we like things in their places: this always goes there, my project dashboard is always green, and I always do that on Tuesdays at 11:00. It's simple, it's clean, and it means that we don't have to think about it anymore. Change it and you're making us work.

So what's a consultant to do? Our entire industry is built upon the myth that change is good, even desirable. We've convinced people that, not only do they need to change, but that they would enjoy it if they had any sense. We're supposed to thrive on change, to drive progress into organizations, to innovate as easily as breathing. We're catalysts in khakis.

So how do you do it without everyone hating you, or for that matter, without hating it yourself? Consultant, consult thyself.

First, acknowledge the change-hater within. Even the most dynamic people have to struggle not to let their minds grow stale. The innovation becomes the process, which becomes the best practice, which becomes "the reason nothing ever gets done around here." Most people are good for one truly disruptive innovation per decade; the rest of the time is spent polishing the message. Even professional catalysts can fall into a pattern of how they implement change that can be as inefficient as any static process. Recognize that you, too, are inclined to seek your own personal status quo, and then you can do something about it.

Use your experience, but don't live by it. Please, put the cookie cutter away. Your experience should be a foundation upon which you build to reach greater heights, not a pattern that you mindlessly repeat in every situation. Every new environment calls for a new approach, so before you whip out that template from your last project or start telling that long story about the last data warehouse you built in COBOL, ask yourself, "What's different about this situation and what's the best way to solve this problem this time?" Now you're ready to…

Start every day with a blank sheet of paper. Yesterday's best practice is tomorrow's case study for failure, so don't let the routine lull you to sleep. Every morning, look at what you're doing and ask yourself, "Isn't there a better way to do this? Can I make this simpler, faster, cleaner? Why are we doing all of this? What purpose is it supposed to serve, and is it serving it?" Even when you don't find anything to improve, the very exercise will keep your mind alert for new opportunities.

Take baby steps. The resistance you face will increase exponentially with the amount of disruption you cause, so start slowly. Remember, not everyone is as dynamic as you are. Even if your ultimate goal is to remake the company in your own image, start small and be prepared for resistance. As a sculpture is shaped by a thousand blows of the chisel, so an organization can be remade with a thousand small tweaks.

Finally, recognize that not all change is good. Change for its own sake may increase billable consulting hours, but it doesn't necessarily make things better for the company. Weigh the cost of your innovations before you make them and be humble enough to recognize that not all of your ideas are brilliant. If the pain of the change outweighs the immediate benefit, then let things be. You'll have another blazing flash of insight tomorrow.

Our friend in the ratty T-shirt is right: we must constantly improve if we plan to survive, in business as well as in life. But we want evolution, not revolution, and we want everyone to come along for the ride.

Monday, March 23, 2009

Jumping off the Waterfall - An Intro to Agile Development

This is the first in a series of articles I plan to write on Agile development, software development in general, and generally getting things done in the workplace. Hope you enjoy.

For decades, the waterfall project model has been the accepted way to build software in large companies. In this traditional approach, every phase of a project follows logically after the previous one, building upon the work that has gone before in a nice orderly flow. At the end of every phase, the entire extended project team gathers together to review the results of that phase, nod together in agreement that the deliverables are satisfactory, and sign off on those deliverables before moving on to the next phase. It is a calm, rational approach that appeals to project managers, CIOs, and accountants. And if everything goes as planned, it truly is the most efficient, predictable, and repeatable way to work.

Of course, if everything were that predictable, you could hire a precisely calculated number of monkeys, equip them with laptops, and develop the code base that runs the space shuttle in just under 3.26 years (I have the calculations from Wikipedia if you want to try this on your next project).

The fact is, once you leave the tidy world of 1000-line Gantt charts and look around you, reality quickly intrudes. The stakeholders refuse to sign off on the requirements until halfway through the development phase, and then only if you agree to add three more "tiny" requirements that they forgot to mention earlier. The technology that you chose to implement the core of your system doesn't do everything you expected it to do, so you have to write custom code. Your QA lead goes on maternity leave two weeks before testing is scheduled to begin. By the time you're done, your soothing waterfall has become a raging cataract of inefficiency and missed opportunities.

This realization has led even the most staid companies to consider their alternatives, the most attractive of which is Agile development.

Agile is not a single unified methodology, but rather an umbrella that covers several different approaches to software development, all guided by the principles of the Agile Manifesto, a statement of purpose that was created by some of the leading minds in software development in 2001, which says:

We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:

  • Individuals and interactions over processes and tools
  • Working software over comprehensive documentation
  • Customer collaboration over contract negotiation
  • Responding to change over following a plan

That is, while there is value in the items on the right, we value the items on the left more.

This simple statement strikes fear in the hearts of order-loving managers everywhere while simultaneously energizing their teams. What if you actually believed this? The possibilities open up:

  • Developers could spend their time writing code instead of documents
  • Analysts could actually talk to customers instead of guessing what they might want
  • Stakeholders could actually see an application in action before code freeze (or, in some cases, launch)
  • The most important features in a project could be live in production and serving the customers in half the time it would otherwise take, with additional features following at regular intervals
  • The inevitable change requests and additional features could become a point of conversation instead of conflict
  • Business people and technical people could work together on the same team, instead of lobbing paper grenades at each other over a wall of organizational dysfunction
Of course, there’s a potential dark side: endless release cycles, a never-ending feature list, constantly changing code with no credible launch date in sight, foosball, skateboards, hacky sack in the halls and ripped T-shirts worn to work on Thursdays… it could be a horror show! Even the names of some of these programming methodologies sound scary: Scrum, Extreme Programming, Non-Linear Management. It sounds like what you’d get after a Star Trek convention mounted a hostile takeover of a neighboring management consulting summit.

No wonder the managers in those big companies are nervous. The potential competitive advantage is clear, but they have no desire and little authority to turn the world upside down in the name of better software. Software isn’t their livelihood; it’s just a tool to get the real work done. So how can they get there from here?

Fortunately for them, there is an answer: Agile for the Enterprise. The trick here is to recognize that a large financial services firm can't pretend that it's a small software startup, nor should it. The answer lies in fitting the Agile methodology to the environment, not in making the environment Agile-friendly. When you recognize an organization's constraints -- distributed teams, offshore resources, separate teams for development and maintenances, project audit requirements, etc. -- then you can craft a solution that fits within the culture, or even takes advantage of it. Rather than saying, "Build your business around our development efforts," you say, "Let's make our development efforts actually serve our business." It's still a change, and it's still scary, but it's no longer doomed to fail.

Get ready: we’re taking the plunge.

Want more information on Agile Development? Start here: