Time Management for the Agile Practitioner

I-Agile Time Management Implicit and Explicit Requirements

Agile methodologies require for the team members to be highly organized and conscious respecting  their time management habits. It will be impossible to estimate things like velocity, story points and other metrics used on projections and estimations, if the team is not working at a regular peace.

Agile explicit time management requirements

Under this category we can put all formal ceremonies for the specific methodology used. Taking Scrum as example you have: the [Daily] Stand Up Meeting, Sprint Planning, Sprint Review (Retrospective), Scrum of Scrums among others. These formal activities require certain level of commitment from team members: punctuality and respect for others time. Although they are not easy to avoid or forget because of group's pressure; it can happens to you if you have one or more of this problems: laziness or poor organized/erratic in terms of your work rhythm.

Agile implicit time management requirements

There is always time, a big par of it, for you to work alone: coding, documenting, doing research and other activities that not require team or group work.

Credits to dilbert.com

So you are working alone, in front of your PC full of potentially distracting elements: YouTube, music, social networks, email (both personal and corporate), your work phone, your cellphone, among others; and still need to implement that interface, code a unit test, document some past work all before the next delivery. You start doing your job but find yourself switching between phone calls, incoming emails, twitts, mentions, photo tags, your favorite song and by the end of the day you feel like you waste the last 8 hours and produce almost nothing.

In any Agile environment you need to respect all team work and also be very efficient and conscious about your time working alone.


II-Traditional Time Management vs. Agile Needs
Here I present you some examples of behavior commonly founded on IT personnel respect time management.

Architects and the ivory tower

Architects use to go “up” to their ivory tower and go down after talking to God with a bunch of specs, designs and diagrams. They work completely alone, leaving room for all kind of distractions; and also given the sense that they are like a black box. A box you only can ask and sit down to wait for the results  knowing noting about the time required for their job to complete.

This practice carries out other problems. One is the lack of understanding about the process for the other members. Other is the lack of transparency one core requirement of Agile software development. also it encourages team division: "they" and "us". Also introduces a sense of elitism.


Developers withing flow state 

These guys also work as black boxes, but their mayor problem is that they think the only way to work is under the Flow State. So they need to have music, toys, tons of coffee, no interruptions, a game console and any other gadgets used to loose themselves into the flow.

The problem with this method is that is not accurate, repeatable or time framed. Also it does not allow for team work.

What is the Flow State?
Yeah, if you are asking what is the flow, allow me to briefly describe it and point you to a good reference.

“Flow is the mental state of operation in which a person in an activity is fully immersed in a feeling of energized focus, full involvement, and success in the process of the activity.
...
One cannot force oneself to enter flow. It just happens. ..."  Flow (psychology) (Wikipedia)

Endless re-factoring

Credits to sourcemaking.com

Developers often put themselves into a rat wheel when trying to deliver “the perfect solution”. After they just code and do some minor tests over the functionality, start re factoring because they got a divine message with a much better implementation in it. But remember Agile is time boxing.

The root problem is that the clock is still ticking and eventually your leader is going to come by and ask you for the solution and, because of our friend Moore, in that particular moment you will be on the middle of a re-factoring with the code broken. And it gets even worse, because you were in “flow” doing your code-”test”-re-factor iterations you just forget to commit your changes.

The same could happen to architects, when they get stuck reviewing their blue prints and after the death line they end with a very complex and partially defined solution. An architecture that if just could be built, will support millions of transactions and concurrent users, when the real need is just for a few hundreds. Did you get it?


III-Time Management Techniques and Practices to Avoid Time Waste
Be willing to change your bad habits
Yes, I had placed this requirement at first because for the following tools to work you need to be disposed to take action. No manager, lead or boss will be chasing you if you do not use them. It is completely up to you. That said, lets begin...

The pomodoro technique 

• Type: individual and group 

• Description: this technique allows you to be highly focused on a given task for a long period without felling tiered. Also it will arm you with the weapons needed to confront all kind of task from big  to small ones using a systematic approach.

• Benefits: overcomes procrastination, be aware of time used on every task, manage and avoid interruptions, give a sense of control over your daily work and time. Know your real performance: pomodoros per day, week, month, etc. Finally you will be able to identify the mayor disruption sources and take action, just be aware that the first guilty could be yourself.

• References: The Pomodoro Technique website. Web based timer Tomato Timer.

Pair programming

• Type: couples or very small groups.

• Description: this practice consist on a pair, usually of developers, sitting together in front of a single computer to do their job in conjunction. To avoid boredom the couple must have two roles: a driver and an observer. The first is the one writing the code an the second is observing the big picture, making suggestions and corrections. Think of this as a real time spell checker, bug finder, compiler and judge all in a single bundle. It is vital that the members switch roles on  a regular basis to avoid both for getting exhausted.

• Benefits: when doing pair programming the time needed to complete a task could be reduced to 50%, enforces the collective ownership of the code, bugs and defects rate decreases as result of the constant review. PP also increases knowledge transfer (to see your partner doing a shortcut you did not know about and will save your tons of typing in the future: priceless). Boots you when sick or tired because of the casual conversational style.

• References: All I Really Need to Know about Pair Programming I Learned In Kindergarten (PDF), The Costs and Benefits of Pair Programming Programming (PDF), Pair programming (Wikipedia).

Coding dojo

Note: If you already know this technique please let me explain why I mixed it up with time management practices, where is not formally one. If you did not know it, just ignore the previous note.

• Type: group 

• Description: let me start with some examples to illustrate this tool.
• Chess masters: The average master (rated 2257) had 7.0 years of serious practice.  The average expert (2174) had 1.03 years of serious practice.  It took an average of 11,000 hours to reach 2200. 
• Sport master, musicians and other artists: these guys require, on average, ten year of serious practice to master their domain.
  
  Where can you dig more about it?
  Here are some very useful references about the deliberative practice and the impact of it on mastering a field:
  - Ericsson, K. A., Krampe, R. Th., & Tesch-Roemer, C. (1993). The role of deliberate practice in the acquisition of expert performance. Psychological Review, 100, 363-406. Summary by: David Zach Hambrick, 1998, gt8781a@prism.gatech.edu
  
  - What it takes to be great (CNNMoney).
  
  - Dr. K. Anders Ericsson (Wikipedia)

So the key idea on Dr. Ericsson's work, and other researches, is deliberate practice, not just playing around or doing repetitive tasks. Deliberate practice, means practice a lot of time (of course); but also (and this is the important thing), to set goals, reach them, review your performance (retrospective), adjust your technique and after reaching your goals move the bar up with new ones.

A good note here is this: practice (yes again); but in the sense that when you are practicing you are not doing the real thing. But remember is not playing, your are serious about it, the difference is that you are not doing the final job; just polishing out your tools.

Let me use well know case of Tiger Woods, and to quote the CNN Money article,

Tiger Woods is a textbook example of what the research shows. Because his father introduced him to golf at an extremely early age - 18 months - and encouraged him to practice intensively, Woods had racked up at least 15 years of practice by the time he became the youngest-ever winner of the U.S. Amateur Championship, at age 18. Also in line with the findings, he has never stopped trying to improve, devoting many hours a day to conditioning and practice, even remaking his swing twice because that's what it took to get even better.

OK, now you could be arguing that your are “practicing” 8 hours a day at your workplace. But in other words, your are practicing by messing up with the real thing. Spending customers money and doing it bad with the real product!

Will you let your children go out on a bike with no previous practice and supervision?
Will you get into a commercial flight knowing that all crew members are interns?
Will you feel comfortable with armed police officers around without target practice?
So why we, IT people, want to manage that million dollar project without previous practice experience in team work?

Getting back to the coding dojo, you probably already know what it is about. 

“A Coding Dojo is a meeting where a bunch of coders get together to work on a programming challenge. They are there have fun and to engage in DeliberatePractice in order to improve their skills.” (codingdojo.org). 

In essence is a practice meeting to get proficient on any other agile technique. Doing it wrong but in a controlled environment. Is a mix of concepts borrowed from martial arts practice room (dojo) and the Dr. Ericsson's work (deliberate practice). I will not dig into the details of Coding Dojos, rather point you the core concept: practice all your tools (Katas) with certain regularity and discipline (deliberate practice).


• Benefits: they are implicit on the illustrations and description but to repeat the mayor one: practice, fail and learn A LOT, in a controlled environment. Going back to our main subject, a coding dojo will help you manage better your time by letting you practice your skills knowing your limitations and reducing anxiety caused by lack of knowledge or practice.


• References: codigdojo.org, How do you put on a coding dojo event? (Youtube), Coding Dojo (WPI, Computer Science department), The Cognitive Psychology of Chess (www.chess.com).

Time box yourself and always do a retrospective

• Type: individual

• Description: this is a core Agile concept. If you really want to deliver some value to your customers always remember: a part of the solution is better than nothing, and better yet if is the most important one.  So whenever you start feeling out of time bring up your red flag, negotiate the scope but never the due date. No matter what customer argue at the end they will be happier with a partial solution than with nothing.
  
  And, what about retrospective?
  Retrospective is the way for you to improve your excellence revealing obstacles, disruptions, flaws on estimation and other problems; causing you to fall short. No matter what happens, always ask yourself: Why was that way? It could have been better? How? ...

• Benefits: keep people focused on what's most important. Don't lose time to perfectionism (endless re-factoring),  overcome complex tasks. 

• References: 10 Principles of Agile Project Time Management, Time Boxing is an Effective Getting Things Done Strategy. 

IV-Conclusions

Agile methodologies expect team's members to be very proficient with their time management skills but traditional software development practices, corporate culture and bad personal habits (like procrastination and perfectionism) are directly opposed to that goal.

We need to be aware of that and use all techniques possible to increase our skill on time administration until they become natural, effectively changing our culture.