Kevin W. Gisi

Jan

2010

Applying Agile to Time Management

Note: Earlier this week I wrote a post on The Problem With Pomodoro, where I described my own concerns with the Pomodoro Technique. This post is designed to discuss positive alternatives that still employ an agile perspective.

While shrinking your time into 25-minute focused chunks might not work for you (whether because of your work environment, or the way you manage focus), there are certainly techniques that you can apply to improve the way you spend your time.

Determining Features

As a young kid, I used to have a terrible time keeping my room clean. We’d have long weekends where I’d sit in my room, unable to make any progress because the work to be done was so daunting. The floor was buried in clothes; the clothes were buried in toys; and the toys were buried in books. It was almost impossible to get anything done. But once my parents suggested “Just get your desk clean; worry about the rest later,” things started to click.

I hardly knew it at the time, but I was beginning to take an agile approach to the room-cleaning project. And that strategy continues now – when I’ve got a long email to write, it can be intimidating. Instead of trying to spend a long chunk of time struggling through, I hit “Compose”, and quickly write out:

Dear Jack,

THANKS

WHAT I TOOK AWAY, NEED FOR MORE INFORMATION

REQUEST

Thanks so much for your time and consideration. I look forward to hearing from you,

-Kevin W. Gisi

Effectively what I’ve done here is divided a large “project” into three key “features”, just like you would with an Agile project, but on a micro level. I now have three small features that need to be completed – specifically, writing three paragraphs, from the small caps-lock cues I gave myself. These tasks themselves will take only a few minutes to complete. While I may not complete them all at once, I will get a sense of satisfaction each step of the way.

The central conceit of this technique is that we are always pleased when we get something done. Unlike the Pomodoro Technique, where the achievement is the completion of an arbitrary quantity of work-time, we instead have a deliverable (be it a paragraph of an email, a passing test in an application, or a clean desk), that we can take satisfaction in.

Managing Focus

I find that trying to control my mind can be stressful – we are actively bombarded with new information every day, and are passively trained to have a very short attention span. Actively trying to force ourselves to focus on a solitary activity can be a real and damaging additional stressor. Focus is important, but balancing it with an Agile approach to time-management can result in a less stressful lifestyle.

When you choose to divide your projects into micro-tasks, consider whether or not you get distracted. To what extent can you effortlessly focus? Some of us can write a chapter of a book without distraction. For some, writing an email is the best we can do. Some of us get distracted mid-tweet. The key to successful Agile task-management is a good understanding of how much you can focus before it becomes a stressful challenge.

Divide your tasks into chunks that you can handle. Personally, I’m quite scatterbrained, and so dividing emails into paragraphs gives me the flexibility I need to avoid fighting with my own thought process. The key is to objectively look at the times when being focused becomes a stressful activity, rather than a productive one, and to adjust your tasks accordingly. To the extent you can work at a consistent, yet comfortable pace, you can be productive, without having to force yourself into mental habits that go against your regular brain activity.

Agile Time Management—A Misnomer

The lesson here is that time-management does not offer us an intrinsic reward. As humans, we get intrinsic pleasure from accomplishing tasks, and so the real term should be task-management. So make sure to follow these steps if you’re looking to improve your productivity:

Consider your ability to focus without stress
If anything is beyond your focus range, split it into smaller features
Take pride in having deliverables whenever you work
Enjoy the focus you have, and keep things stress-free

Enjoy your work, and keep it manageable, and you’ll be productive!

No comments »

Jan

2010

The Problem With Pomodoro: A Perspective

The Pomodoro Technique, for those unfamiliar, is a method used to improve productivity throughout the day. I encourage you to visit the site to find out more about the process, but to oversimplify: you work in 25 minute cycles (called pomodoros), taking short breaks in between. After several of these, you take an extended break.

This sounds like a perfectly reasonable way to try and improve our productivity at work, and it’s seems in line with many newer techniques in the field of software development and human resource management. The number of pomodoros completed is the metric for successHowever, the Pomodoro Technique focuses on the completion of it’s own unit, the pomodoro, as the metric for success. While some struggle with productivity, often this stems from a lack of motivation – which can result in intentional, or even unconscious procrastination. Finally, what side effects can result from micro-management of our time?

Is Pomodoro Agile?

The Pomodoro Technique seems to fit quite nicely with Agile project management trends – Pomodoro creates a micro-form of the agile timebox, and treats that as an atomic piece of work.

Pomodoro also falls in line with Scrum practices – being honest about where time is being invested, catching issues early, and understanding that the rate of work is constant. You should never be inclined to “work a harder pomodoro”, but you should consider whether your goals are too ambitious for your available time.

However, there’s one key distinction – at the end of a pomodoro, you might not be done. You record that you completed 25 minutes of work, whether or not the task you were working on is complete. Pomodoro requires no deliverablesIn a traditional agile development, the goal is that there is a deliverable product each iteration. The client, and the programmer, can take a small pride in having fully completed a certain set of features. This is not always the case with the Pomodoro Technique – the focus is on boxing the time, not the product.

Is Pomodoro Motivating?

One of the reasons for implementing the Pomodoro Technique is that “excitement decreases when complexity is high.” This happens to come straight out of the Pomodoro Technique Illustrated. This seems like a strong argument for the Pomodoro Technique as a tool to help fix a motivation deficit.

Dan Pink, argues that “Rewards can deliver a short-term boost—just as a jolt of caffeine can keep you cranking for a few more hours. But the effect wears off—and, worse, can reduce a person’s longer-term motivation to continue the project” in his latest book on motivation, Drive.

The completion of the pomodoro is just such a reward – while completing one can provide a sense of satisfaction, it is an abstract concept that has no intrinsic value. We are intrinsically motivated to complete tasksWhat Pink discusses in his book is the concept that we are motivated to complete tasks, independent of artificial or substantial rewards – perhaps the Pomodoro Technique can do harm by overemphasizing the need for another abstract reward system. The accomplishment of tasks alone can be great motivation in the right environment.

What is the cost?

Andy Hunt, in his book Pragmatic Thinking & Learning, discusses the importance of right-brain thinking, especially with regard to increasingly creative fields like computer science. It’s no coincidence that so many successful developers in the perceived math-laden, algorithmic field are also accomplished musicians and artists. Because the right-brain is responsible for the creative solutions we so often need to perform our jobs, it is vital that we encourage creativity.

The Pomodoro Technique can threaten this need. Andy tell us “Answers and insights pop up independently of your conscious activities, and not always at a convenient time…you need to be ready to capture any insight or idea twenty-four hours a day, seven days a week, no matter what else you might be involved in.”

While focusing on the task-at-hand is important, an exclusive focus can prohibit creative thinking. The Pomodoro Technique needs to be used with caution, so that it does not prevent the spontaneity and free-form nature of the creative process.

What To Apply

While the Pomodoro Technique might have some flaws, it does encourage some very good practices, namely:

Really examine where you spend time
Make sure to take honest breaks
Record your time investments objectively
Use trends to illustrate places to improve
Spend your time deliberately (like your money)

Consider the usefulness of good time-management, but take caution not to allow it to limit your own process.

Note: I have a great deal of respect for Francesco Cirillo’s work, and highly recommend that you take a look over at http://www.pomodorotechnique.com. I also recommend examining Staffan Nöteberg’s Pragmatic Bookshelf release, Pomodoro Technique Illustrated for more information.

6 Comments »

Dec

2009

Go is a Series of Tubes

Go, the brand-spanking new language from Google that arrived November 10, 2009, is a compiled, concurrent, threaded systems language — the first systems language of this decade!

The intent was to produce a language that had performance comparable to C, but developer satisfaction comparable to that of Python or Ruby. The language features some impressive ideas, including type inference, shorthand for declaration, initialization, and assignment, and interfaces, but I’d like to talk about my favorite features – Go routines and channels.

“Hey Joey, look at the f***in’ tubes!”

~George Carlin

Go Routines
Rather than using threads, Go supplies a mechanism called a Go routine. While these operate in a similar manner to threads, they have the benefit of being load-balanced internally across real threads by the Go language.

func threadedThing(){
  // Do some stuff
}

func main() {
  go threadedThing();
  // Continue without blocking!
}

Go routines can also be declared anonymously, like so:

func main() {
  go func() {
    // Do some stuff
  }(); // <- parentheses to call the function
  // Continue without blocking!
}

Channels (Tubes)
Go calls them channels, I call them tubes! Channels form the basis of how we can communicate between Go routines. Take the following example:

func printer(input chan int){
  var a int;
  for {
    a <- input;
    fmt.println("Receieved: ",a);
  }
}

func main() {
  tube := make(chan int);
  go printer(tube);
  for i:=0; i < 10; i++ {
    tube <- i;
  }
}

In the above example, the printer will block until it receives an item from the input channel (a <- input), and then print it out. Meanwhile, the main send values through the channel (tube <- i) - and it also blocks. However, if we change the declaration of the channel to include a buffer...

tube := make(chan int, 10)

...the main can continue to loop, simply dropping things into the channel buffer.

When is a tube not a tube?
Consider the following example:

func main() {
  killswitch := make(chan int);
  go server(killswitch);
  // Do some work
  <- killswitch;
}

Here we see an example of how you might "join" another "thread", but in Go terms. Rather than using the channel to communicate data, we simply await any communication from the channel, and then quit. Since reading from the channel is a blocking operation, the server Go routine can simply write any value to the killswitch channel, and the main will read it, discard it, and terminate.

Channels can be used for a variety of different purposes - to transmit data, to acts as a termination signal, and even as semaphores. The flexibility of a language like Go makes it a treat to work with, and I encourage you to head over to http://golang.org and take a look for yourself!

3 Comments »