Agile programming works for the solo developer

Agile programming, a.k.a., extreme programming (XP), has a lot to offer the lone developer. Learn how agile programming's practices can bring order to solo development efforts.

You may not realize it, but if you’re a software developer who works alone, you may already be using a lot of the concepts behind agile programming, also known as extreme programming, or XP. Of course, certain agile programming practices, such as pair programming, simply don’t apply, but the organic nature of the agile methodology easily lends itself to rapid application development, even for the solo programmer.

I’ll step through the relevant practices of agile programming and how they can facilitate application development in the one-man shop.

Agile programming overview

The agile programming methodology is divided into four activities and deployed with an iterative style. Planning, designing, coding, and testing are all performed in bite-size pieces. These steps are revisited when needed or according to schedule.

When you’re developing alone, it’s easy to just dive in and assume that you’ll be able to handle whatever problems arise. Agile methods can facilitate the process, however, and will actually help you avoid the lag that comes from struggling with a less organized approach.

I’m an independent application developer, as are many in the current economic climate. As of this writing, I’ve got four separate projects. While I can easily manage requirements and progress status for each of these endeavors, I’ve found that the time needed for sourcing, ramp-up, and development is greatly reduced simply by applying a little order to the chaos.

Borrowing relevant agile programming methodologies has worked quite well for these projects. For one thing, agile programming isn’t heavy and doesn’t require an inordinate amount of overhead. Also, every piece of planning is immediately useful, and my clients get a sense of constant contact and the instant gratification of regular updates. The practices defined by agile programming help me put a simple structure behind my work. This lets me focus on getting things done, but it also supplies the environment I need to adapt to and incorporate changes without disrupting progress.

When you’re working alone on a project, planning is easier with the agile methodology than with spiral development or the other methods I’ve worked with. In fact, much of the process comes naturally to the lone-wolf developer. By picking and choosing the pieces that fit, these practices are well suited to working alone.

Agile planning

You may find that you’re already using many of agile programming’s planning practices, although perhaps in a more informal manner. Try tweaking your diligence slightly, and you’ll discover some of agile programming’s tremendous benefits in this area.

User stories

User stories are a way of capturing what I call “the flood.” This is similar to requirements gathering in traditional development methodologies, but it differs in that technical details are omitted and work to be performed is described in plain English, broken out into two- to three-week sections. Each user story is written onto an index card and used to plan releases.

Since one-man projects tend to be small, I generally break the user stories into shorter duration blocks. Of course, this goes against the rules of the “planning game” and ultimately quickens the iterative rhythm; however, the same basic principles apply.

Releases

A release consists of user stories grouped together based on dependencies and business need. Agile programming releases are not partial deployments but rather represent completed, logically grouped portions of functionality. Scope or duration can determine a release, and functionality is chosen by common sense and priority.

As with team projects, keep releases short. Each release comprises several iterations and is largely determined at the beginning of the project. Organize releases by grouping the user story index cards together. This allows you to keep the customer satisfied with frequent deployments, and it helps keep the focus on the big picture.

Just-in-time planning

Once you have an idea of the releases, determine your iteration length. An iteration should be one to three weeks in length, and there should be three or four iterations per release. Even with shortened user stories, I’ve found that sticking to the low end of this guideline works on lone projects, as long as I make sure that all iterations are about the same length. Otherwise, it’s too easy to break away from the agile model.

Define iterations by selecting the most important user stories and breaking them down into programming tasks. Involve your client in deciding what task has the highest priority, and always plan to complete it first.

Iteration planning should be done at the start of that iteration and not before. This may seem somewhat shortsighted, but it keeps you focused. Discrepancies will be resolved in future iterations.

Designing the solution

Designing your solution with the agile methodology is simple. It’s spread out over the course of development, rather than being completed up front.

Class cards

Create index cards representing objects and classes. Use the cards as you would boxes on a diagram to demonstrate the objects’ relationships. Keep it simple, and refine the layout with additional detail when planning an iteration.

Refactoring

As you move through the project, take time to clean up your code and consolidate functionality. This is called refactoring, and it allows the system architecture to develop logically and organically. Every iteration should include time for restructuring; the class cards can show where it may be necessary.

Spike solution

When you encounter a tough problem that lacks an immediately apparent solution, create a spike solution. This is where you try out different approaches in code to make the correct solution more apparent. This happens all the time in independent development, and it may not require the level of formality that agile programming calls for.

Other design principles apply as well, but many are somewhat inherent when the team is a single person. For example, it’s a good idea to name objects and other system elements consistently, but as an individual, you probably don’t need to formally create a metaphor.

Coding guidelines

Much of the coding guidelines for agile programming refer to management of teams, but a few concepts are worth adopting.

Client contact

Frequent contact with the client is crucial for the deferred planning of this methodology. Not only does frequent contact help clarify details and prioritize tasks, but it’s also a great management tool when you work alone. It gives the client confidence in your ability to deliver and keeps the client abreast of your progress.

Testing framework

Create unit tests before writing code. This might seem a little like overkill for small projects, but it actually keeps the scope in focus and limits development to the requirements. Code enhancements and additions must be completed in a separate iteration, facilitating quality assurance.

Even though it’s a good idea to create a testing framework, less formality is required for one-man projects. Since I usually wind up writing code and interfaces, I use preliminary interfaces with debug flags as my test mechanism for back-end functionality. Although this isn’t as stringent or long-lasting as the agile methodology’s preferred practice, I’m comfortable that it meets my needs.

As extreme programming enthusiasts are quick to point out, the process is designed to be modified to fit your needs and changed when it isn’t working.

Test before moving on

Once you’ve completed coding a particular piece of functionality, make sure it works before moving on. This is one of the ideas behind creating unit tests up front. When the relevant code has passed the unit test, it can be integrated. After completing all tasks for a user story, apply functional tests to ensure all requirements are met. When you find serious bugs, modify your testing to check for them after they’ve been fixed.

When you’re working alone, this is pretty much the natural progression of testing code anyway. By creating formal tests before writing code, it’s evident whether a piece of functionality works or not.

Bringing structure to the soloist

These are some of the principles of agile programming that apply to solo development. I picked up these habits on a recent project as an experiment to see if I noticed any improved efficiency. It took about a month to really get into the habit of not solving problems before their time and being diligent about refactoring, but my productivity increased once I got a rhythm going.

I really like the way the client took an active role through continual contact, and forcing myself to create test cases before writing the code facilitated development. If you’re a single developer, agile programming can give structure to your process.

HR Online Recruitment Mashup

Do you recruit using naukri.com or Monster or any online recruiter? Do you want a way to automatically post your jobs internally and externally? We have a very competitive offering that can help you do just that.

This business mashhup combines the implementation of an internal recruitment process with different kinds of job services, which are available in the internet or a company's intranet. These (online) services enable to find, recruit and/or retain potential candidates.

Every organization has continuous or recurring staff requirements. This Mashup can help to optimize and standardize the entire application and recruitment process.

In some cases there is a lack of human resources - not enough/unsuitable job seekers. Hence, it is very promising to integrate different kinds of job service, e.g. sourcing of candidates through Job-Boards or other stored date - into the recruitment process.

This mashup supports the enhancement of the quality of resources recruited and the reduce the time it takes for the whole application and recruitment process.

For details and further discussion contact businessmashupsllc[at]gmail.com

Mashups: The next major new software development model?

Even a cursory examination of what people are doing every day on the Web right now tells us that mashups — also known as ad hoc Web sites created on the fly out of other Web sites — are indeed happening in a large way, albeit in simple forms, by the tens of thousands online every day.

But inside our organizations, both in the IT department and in business units, mashups are a much rarer phenomenon. And in fact, this is one of the classic hallmarks of the Web 2.0 era; the much larger community of the Web as a major source of innovation and leading edge behavior that subsequently moves across the firewall and into our workplaces.

However, the topic of this blog is aimed at the application of Web 2.0 to the enterprise and so whether mashups will be a significant new model for application development inside our businesses anytime soon is still somewhat of an open question.

Since the mashup story is primarily being driven by spontaneous activity at the edge of the Internet, an accurate and updated picture of what's actually happening with them is harder to make out than if it was being driven by a centralized industry effort. And as it turns out, this makes what's happening richer and more exciting than it would be otherwise while at the same providing significant challenges for those that want to take these compelling ideas and apply them deliberately to solve business problems.

To bring folks that are just joining the mashup conversation up to speed on why mashups are so exciting, I'll start with my take on the key aspects of mashups from a value proposition perspective.

Key Aspects and Benefits of the Mashup Approach

• Effective leverage of Web parts and the Global SOA. Mashups are generally built out of the bits, pieces, and services of other Web applications that already exist, adding code only when it can't be sourced from internal or external suppliers or to provide integration "glue" between the parts. This reuse can quickly and easily leverage millions of dollars in previous investment and results in a "building on the shoulder's of giants" effect. Like the visual component marketplace successfully built around ActiveX in the late 90's, mashups are a form of reuse that actually works but on a much larger scale than ever before. See ProgrammableWeb's open API cloud and WidgetBox for a good example of the vast array Web parts that are now widely available.
  

• Simple, lightweight software models and services. By focusing on the simplest possible techniques and formats, Web mashups appear to be successful and widespread primarily because just about anyone can and are creating them. Mashups are typically built using techniques like cutting and pasting snippets of Javascript, using feeds and XML to connect the various parts together, and even one-line Javascript inclusions that can pull in and integrate an powerful external component, such as Google Maps or a YouTube video player, that originally required a massive investment from its creator. There sometimes seems to be no limit to the effort to lower the barrier to consumption of these Web parts. Both Google and YouTube are poster children for easy Web part consumption and have reaped corresponding rewards. Google makes its AdWords and Maps widgets incredibly easy to install and deploy while YouTube even puts the hosting code next to each and every video on its site. Finally, mashups are 100% pure Software as a Service (SaaS) and require no installation, updates, plug-ins, admin rights, or anything but a garden variety Web browser and the mashup's URL to run.
  

• A focus on self-service and DIY. As I alluded to above, mashup development can be just as much for everyday Web users as it is for professional software developers. Like so many things on the Web that put the power of publishing and participation into everyone's hands, mashups have the potential to give all of us the ability to create real, useful software. And while end-user mashups will remain in the bottom half or one quarter of the software complexity spectrum, it means that applications that could never have been justified on a build-vs.-buy perspective (and took too long to acquire to help) are now possible These apps can now just be created by users — and groups of collaborating users — on the fly as they need them. This has the potential to further enable the productivity of knowledge workers as well as release The Long Tail of IT demand. It could also reduce the application backlogs that continue to bedevil IT departments and their customers everywhere. And to re-emphasize, it's because mashups use such simple techniques that jsut about anyone can now create the views, dashboards, and even real software apps that let them get their work done better and faster without unnecessary bureaucracy (some bureaucracy is required as I indicate below). I've been collecting real-world examples of this in the workplace and will share them in an upcoming post.

There are numerous smaller, ancillary benefits of mashups including the fact they are Web-oriented and 1) can leverage link structure, 2) tend to be more open and visible which results in more transparency and information sharing, and 3) their content can even be discoverable by search if some care is taken. In this way, they become part of the Enterprise 2.0 story as well, particularly if they are socially enabled. Fortunately, a good number of widgets, such as those from txtDrop and MyBlogLog, make it easy to add simple social aspects to mashups to enable their full power.

This, however, doesn't mean there aren't challenges and a few drawbacks to mashups which I'll highlight below. For now, it's enough to keep in mind that the three major benefits including high-levels of reuse and leverage, models that support rapid, easy development and integration, and a focus on DIY by anyone from expert developers to newbie Web users.

The Challenges and Opportunities of Mashups

Mashup Challenges

• Deconflicting the two major mashup models. Right now mashups are happening mostly "in the wild" with users taking their blogs, wiki pages, FaceBook profiles, and even ordinary Web pages and covering them with badges, widgets, and gadgets from elsewhere on the Web. On the high end of the complexity spectrum, there are over 2,000 developer created mashups presently available. There is also now a growing body of tools from commercial software vendors that also try to bring the apparent advantages of mashups to the business world, both on the Web and in our intranets. In general, these two mashup models are quite different from each other. On the consumer Web we have the natural, emergent mashup phenomenon as numerous Web parts suppliers and their consumers try different strategies out and sometimes hit upon the models that work best (which appears to be things like one-line includes, cut-and-paste, and smart widgets that make integration easy, with Google Maps being another great example.) On the vendor side, enterprise mashup tools try to add missing enterprise context like security, support for local SOAs, and so on, as well as a mashup development model, usually by choosing a particular Web component standard and providing a visual IDE that makes it easier for the non-HTML savvy to create mashups. These commercial mashup application models try to a priori figure out what will work best and in this they may be making the mistake of ignoring the vast laboratory of the Web that is already proving out highly effective models for mashup parts and integration strategies on a large scale. There is also a skill and open/closed barrier between these two approaches that tends to prevent the movement or migration from model to the other. My best guess is that the commercial mashup tools that will succeed the best will eliminate this barrier or at least greatly reduce it.
  

• Too many widget formats. Both Microsoft and Google have their own gadget models, NetVibes has the compelling Universal Widget Architecture (UWA), and OpenAjax has no component model per se but vital strategies for making Web parts work together in the same mashup. Even the venerable and respected W3C has gotten in the act with a first draft of the Widgets 1.0 specification. Visual tool support is important to fully enable mashup development and realize the productivity potential and this support requires a consistent widget format. But the proliferation of widget models (both ad hoc and formal specs) makes visual tooling expensive and time-consuming to implement. And though the greater Web has been relatively successful so far without them, enterprises are not yet anxious to start figuring out which widget models are the most important. Unfortunately, no obvious solution is on the horizon though some early techniques have formed including wrapping the different component models into a standard widget wrapper.

• Not enough Web services exist in our enterprises or on the Web. While the number of open APIs on the Internet continues to grow quickly, there just aren't enough Web services available to supply the data and back-end functionality to mashups. Most data on the Internet and our intranets are still in static Web pages in the form of HTML. While the growing adoption of XHTML helps a little, the greater service-enablement of the Web will take years and years. In the meantime we need to quickly service-enable our silos of Web-based information if we are to fully exploit it. Fortunately, this challenge can now be partially mitigated with companies like Kapow and Yahoo with Pipes, which are providing just such tools to make this possible. Also note that this challenge is one reason why widgets have grown so popular, since they offer both a data connection back to the server they came from as well as a visual aspect that allows the information to be seen and integrate with. Thus widgets are ideal for consumption by providing a sort of easy-to-use "visual SOA."
  

• Security and identity need to be sorted out. The most useful mashups will involve Web-based creations that are powered with our personal and business information. For now, most mashups don't require (or support) logins that allow it to collect information from your private repositories of information. While initiatives like OpenID have the potential to resolve some of these issues, there is a lot of work to be done before the average user will trust a mashup with access to their private information. This shortcoming fundamentally limits the real value that mashups have the potential to provide.

• No common creation metaphor. Other major Web 2.0 platforms such as blog and wikis have very simple, well-known usage models. There is a save button, an edit button, and either a reverse chronology of posts (blogs) or a series of page revisions (wikis). However, other than the aforementioned simple cut-and-paste model, nothing has really emerged in a similar vein for the creation of mashups. This will resolve itself slowly as some widgets now have configuration popups or easy code generators to get what you need done without needing to be a Javascript expert. However this is a far cry from having a development model that is generally well understood by most people and well documented. I often say that spreadsheets and Microsoft Access are the end-user development tools most of us have today and they offer some insight, as well as blogs and wikis, into what a workable model might look like. Offering some hope, mashup vendors are exploiting the near ubiquity of the blog and wiki model and IBM has merged mashup development with wikis with QEDWiki and Dan Bricklin has done something similar with wikis and spreadsheets with WikiCalc.

Mashup Opportunities

• Defining the essential ingredients of a successful mashup ecosystem. This is about conveying a clear conception to the marketplace that we really are moving more from green field development to a world where we assemble our software out of the rich content and functionality we now have ready access to on the Web and our SOAs. Other ecosystem questions: What kind of Web services do you need? How about adapters to legacy systems and content? Should you encourage mashups to be the foundation for other mashups? How do we guarantee compatibility and interoperability? These and a lot more issues about how to create a successful mashup ecosystem need to be better articulated than they have been to date.

• Addressing the tension between the two major styles of integration. Most integration today is done up front with lots of testing and configuration control and baselined code from your external suppliers. On the other hand, mashups rely on live pulls of code from your supplier and are a much more extreme form of combining our systems together. The very word "mashup" conveys how ad hoc this really is. This new live model of integration has security, testing, and version control issues written all over it. Google and some of the larger suppliers are getting a handle on some of these but market leadership on this could go a long way.

• Providing effective "enterprise context." Mashups are a creation of the consumer Web and are not always ready to "play" in the enterprise space. To even get a foot in the door, enterprise mashup tools need to have solid stories around single sign-on (SSO), LDAP, JSR168 (portals/portlets), legacy integration, management, monitoring, RSS strategy, etc. Most enterprise tools are still falling short in these categories and will likely not get broad adoption until they address them.

• Distribution and consumption. Many of the ideas that the consumer Web has come up with for Web parts to be highly viral, easily distributable, and eminently consumable are also important strategies that we must think seriously about moving into our SOA initiatives. That's because our internal SOAs are smaller versions of the very same ecosystem that we have seen form on the Web. Getting services adopted and used in the enterprise has been entirely too hard up until now and even many companies out on the Web are falling short of in terms of applying the latest low-barrier, viral distribution techniques for success and uptake.

• SEO, analytics, page views are all challenged by the mashup model. Just like Ajax and Flash, mashups turn single Web pages into entire applications and all three of these Web application models have been slow to address some of the more important models and monetization strategies that power business on the Web. There is ample room for companies that let mashup creators address the loss of these important aspects of Web usage.

As I read through this list, it's a clear that I've tried to address both consumer and enterprise mashups, two very different beasts with a somewhat different audience. I say somewhat different since the consumerization of the enterprise as younger workers bring their Web 2.0 skills and habits to work has already begun. For now however, it's seems clear that whatever the adoption speed, mashups are here to stay as one of the most compelling and efficient ways to turn time and money into working software and solve business problems in new and innovative ways.

Mashups are so easy to create that they should be used as a preliminary litmus test for a startup's business model.

Leader vs. Ruler: Which One Are You?

When I was trying to search for "leaders vs. rulers" on Google, I found many references to governments, royalty, and the military, throughout history. But the strange thing is that none of the articles seemed to distinguish between leaders and rulers. As if leaders and rulers are the same kind of people.

They are not.

Leaders

Last week I was reading the book Tribes, by Seth Godin. In his book Seth says that never in history has it been so easy for anyone to be a leader. These days, with the use of social media, each of us is able to attract our own followers. And on Twitter, this is exactly what we're doing (quite literally). Seth explains that a crowd becomes a tribe when it has a leader that the people are following out of their own free will. And the interesting thing is that people can follow different leaders for different causes.

In software projects it is the same. Some people can take the lead on an architectural level, while some have the lead on a functional level. Still others may be the first ones to turn to when people need advice about tools or processes. A complex system does not need a single leader. In fact, I believe a cross-functional team functions best when it has multiple leaders, each with his own area(s) of interest.

Rulers

In social systems the rulers are of an entirely different breed. While leaders use the power of attraction to convince people what to do, rulers use the power of authority to tell people what to do. Ruling people's lives is the very purpose of the ruler's job. With ruling comes law-making, enforcement and sanctioning, also called the trias politica (legislature, executive, judiciary).

Unfortunately, rulers have gotten a bit of a bad name over the centuries. (Much of it deserved, by the way.) But ruling isn't all that bad. Laws, enforcement and sanctions are necessary evils, and in many social systems rulers can peacefully co-exist with leaders. For example: in any football (or soccer) match you will find leaders (one in each team) and rulers (the referees). They all play their parts in making the game work for everyone.

Are managers rulers?

There's no doubt in my mind that managers are rulers. They are (usually) the only ones with the authority to hire and fire people, and to place them in (or remove them from) teams or departments. They are able to tell people what software to use, what clothes to wear, and how much to pay for a place at the parking lot.

Are managers leaders?

This is a more interesting question. Lots of management book have been trying hard to turn managers into leaders. The last one I read was Good to Great, by Jim Collins. In his book Jim listed a 5-level hierarchy:

• Level 5 Executive: Builds enduring greatness through a paradoxical blend of personal humility and professional will.

• Level 4 Effective Leader: Catalyzes commitment to and vigorous pursuit of a clear and compelling vision, stimulating higher performance standards.

• Level 3 Manager: Organizes people and resources toward the effective and efficient pursuit of pre-determined objectives.

• Level 2 Contributing Team Member: Contributes individual capabilities to the achievement of group objectives and works effectively with others in a group setting.

• Level 1 Highly Capable Individual: Makes productive contributions through talent, knowledge, skills, and good work habits.

The problem I have with Jim's hierarchy is that it suggests a linear progression to "higher" levels (where a leader is on a "higher" level than a manager). This doesn't fit with my observations of how social networks operate.

In a software project, or any other social network, there can be many leaders, each with his or her own goals and desires. Some are taking initiatives for better architectures, some are leading the way to better user interface design, and some are guiding their followers towards better customer service, better processes, better software tools, or better coffee.

To be a leader is not the next step for managers
It is the manager's job to give room to leaders

There are thousands of leaders on Twitter, and they all have their own huge numbers of followers. But who are the managers of Twitter? Only Evan Williams, Biz Stone and Jack Dorsey are. It's their platform. It's their game. They are the referees, making the laws, enforcing them, and sanctioning, while thousands of leaders and tribes are running around trying to score.

Sure, it's ok when managers are trying to be leaders. Nothing wrong with that. Evan, Biz and Jack have a large number of followers themselves too. But they don't have the largest tribes.

Managers are on top of things, but they are not on top.

Rulers don't need to have the largest tribes themselves. Being a great ruler is hard enough already. If you think you need to be a great leader too, you're just making it hard for yourself. Referees contribute to great football/soccer games by being great rulers. They don't attempt to lead. It's not their job. They are in charge, but they are not the ones with the biggest egos.

In his presentation Step Back from Chaos Jonathan Whitty shows that managers are often not the hubs in a social network. It's the informal leaders in a network through which most of the communication flows. It's the managers' job to make sure that leadership is cultivated, and that the emerging leaders are following the rules.

So, you can be a leader, or you can be a ruler. And if you're exceptionally talented, perhaps you can be both.

Which one will you be?

By Jurgen Appelo

What's Really Behind The Talent Gap

It's been a long-running complaint that there aren't enough young people entering the IT field. But judging by the list of experience and skills some employers demand from IT job candidates, you have to wonder if young people just starting out their careers even have a shot at being hired.

Employers aren't just looking for folks with technical skills, they're seeking strong communication ability, business know-how, vertical industry background -- and, in many cases, hands-on experience with a variety of specific technologies and track records of successful deployments. It's one thing to seek the "full package" from someone who's been in the field for years, but much more difficult to find that in people newer to the profession.

So what does that mean? If there really is a shortage of the "full-package" people you're looking for, as employers you've got to be willing to help develop those folks. But apparently, many employers aren't willing to do that. Many companies just don't have the time, money, resources, patience, or vision to cultivate future talent. So, they'll look outside their organizations for ways to bring in "new" people quickly. Or they'll outsource. Or they'll seek foreign workers with H-1B visas. The problem with all of that is this: Often those people don't have all the "right stuff," either.

There's a big gap in what's going on. There's a mismatch in the demand for talent many IT organizations are seeking -- and the degree to which these companies are providing the appropriate training and career development opportunities to build up their bench strength internally. Plus, when it comes to younger folks entering the field, there also are disconnects between what many universities are offering to help these students "align business with technology" with what employers expect from tech workers today. Universities are slow to adapt.

What is your organization doing to nurture its IT talent?

How to Mitigate the Urgent to Focus on the Important

Reading good books, magazines, journals or simply the newspapers in the past has been a very important aspect of my learning life. These days most of the time allotted to reading is when there is a power outage during the daylight hours of the weekend, when there is nothing else to do or on in the nights if there is no access to the internet. However although there has been a deterioration in my reading habits, browsing on the internet has become a replacement. Whether it is good or bad I do spend a lot of time on the internet doing researches, etc. Recently on one of my browsing session on time management I stumbled on an article written by Gina Trapani which caught my attention. It has some interesting facts which I would like to share with you.

Busy people have two options when they decide how their workdays will go: they can choose to be reactive to urgent demands on their time, or proactive about focusing on what they decide is important. The only way to actually get things done is to mitigate the urgent to work on the important.

Let's differentiate between what I call urgent and important.

Urgent tasks include things like that frantic email that needs a response RIGHT NOW; a sudden request that seems like it'll only take two minutes but often ends up taking an hour; a report you've got to write up before a meeting. More often than not "the urgent" is putting out fires, or busywork, or tasks that you'd rather do first because they're less intimidating than your current project list.

Urgent tasks are usually short-term and we're drawn to them because they keep us busy and make us feel needed. (If we're busy people, we must be important people.)

But dealing with a constant stream of urgent tasks leaves you wrung out at the end of the day, wondering where all the time went, staring at the undone actual work you've got to complete.

On the flip side, important work moves you and your business towards your goals. The important stuff doesn't give us that same shot of adrenaline that the urgent requests do. It can involve thinking out long-term goals, being honest about where you are and want to be, and just doing plain hard work that feels boring and tedious. On a personal level, important stuff may include making time to get to the gym every day. On a business level, important stuff may be devising your yearly plan, breaking it down into quarterly and monthly deliverables, and evaluating your current performance against last year's plan. (Doesn't the mere thought of going to the gym and deciding on this year's goals make you want to check your email? Still, that's the work that will help you meet your goals.)

If your workplace encourages that frantic vibe of headless-chicken running and constant urgency, it can feel impossible to focus on what's important versus what's urgent. Still, an awareness of the difference and a few simple techniques can help.

Choose three important tasks to complete each day. Write them down on a slip of paper and keep it visible on your desk. When you have a moment, instead of checking your email, look at the slip, and work on an item. Keep the list to just three, and see how many you can complete.

Turn off your email client. Shut down Outlook, turn off new email notifications on your BlackBerry, do whatever you have to do to muffle the interruption of email. When you decide to work on one of your important tasks, give yourself an hour at least of uninterrupted time to complete it. If the web is too much of a temptation, disconnect your computer from the Internet for that hour.

Set up a weekly 20-minute meeting with yourself. Put it on your calendar, and don't book over it — treat it with the same respect you'd treat a meeting with your boss. If you don't have an office door or you work in an open area that's constantly busy, book a conference room for your meeting. Go there to be alone. Bring your project list, to-do list, and calendar, and spend the time reviewing what you finished that past week, and what you want to get done the following week. This is a great time to choose your daily three important tasks. Productivity author David Allen refers to this as the "weekly review," and it's one of the most effective ways to be mindful about how you're spending your time.

Be The Change:

Put in practice one of the three tips in the article above.

Greased Lightbox

→←+-↻

Loading image

Click anywhere to cancel

Image unavailable