This week’s chapter of Monotasking by Staffan Nöteberg. is Progress Incrementally. I was first exposed to the idea of incrementalism and timeboxing by my mother while helping (or voluntold) with the housework. I would vacuum rugs for about 5 minutes, have the work inspected, and then, invariably do some rework before moving off to the next timebox. As a child, I just assumed you should get feedback early in the process. I later ran into timeboxes in Champy and Hammer’s book Reengineering The Corporation. The idea was a revelation in the work environment I was in at the time.  In both cases the duration timebox was different, but the message was similar. If you break work up into smaller pieces you can assess progress, get feedback, can change tact or do something more important (this is where I ask Lakein’s question – “What is the best use of my time right now?”) much sooner than if you wait until your think you are done. On top of all of those benefits, increments also help people and teams to achieve focus. This week I have succeeded in turning off all my interruptions (Slack, Text, Teams, Twitter, email, and others) as I am doing my monotasking sessions, a type of incrementalism . . . at least in the morning. I do pop many of those apps back on briefly at the end of each panorama session to make sure no emergencies have occurred. Afternoons are tough due to meetings and other hardscape activities, therefore I moved as many of my focus activities earlier in the day (as a morning person, this suits me) when I can quietly timebox.

There are several problems many people have fitting work into timeboxes. One of the most common is that they do not break work down into smaller pieces. Whether user stories or tasks, people often jump into the work without establishing the purpose, a clear understanding of who they are doing the work for (hey, my manager assigned it to me – I have heard more than a few times), and then they don’t chunk it up. There are all sorts of reasons not thinking through these three steps is problematic. The first two are that if we don’t understand the purpose, then we can’t know when we are done and we can’t live by the agile principle of “Simplicity–the art of maximizing the amount of work not done–is essential.”  More importantly is that the larger the task, the longer the amount of time before we can get feedback. Slow feedback leads to rework and irritated clients. Very early in my career, I was tangentially involved in a huge capital project. The plan, budget, and architecture were generated two years before the first line of code as contemplated. The “plan” broke the work down over five years culminating in a big reveal and implementation. The project failed, both what the stakeholders needed and what the technical infrastructure would support had changed. The real tragedy was that three years of blood, sweat, and tears were expended before the work was canceled. All because no effective feedback was generated until the work had hit a long-term phase gate. Had the work been broken down it would have appeared sooner (FYI I understand they tried the same approach again with the same results before breaking the work down – crazy, right?)

Regardless of your model (agile, lean, fragile, or waterfall), break projects down, break tasks down, and use the short feedback loops to validate your approach and direction. I understand that there is some gray line where the cost of breaking work down is equal or greater than the information you will gain, however, most people stop well before that line.  One option (my favorite) is to break work down just enough to both ensure understanding and just enough to test the approach before executing. The “just enough” concept forestalls analysis paralysis.  Based on the feedback, iterate the process until done or move on to something more important.

Doing the work that is the most important at any point in time is critical to delivering the most value. As we have noted in past entries, importance and urgency are often falsely conflated. A friend and colleague recently told me that they performed best when they had a deadline. Over a virtual beer, they confided that they often created scenarios to generate the urgency of a deadline for themselves. Which they noted mostly worked. Staffan points out in this chapter that false deadlines are a trap that leads to poor performance. Prioritizing a task’s importance and then using the combination of timeboxes and Lakein’s Question is a better approach. Also, not trying to lie to yourself will reduce stress and cognitive dissonance, which will improve your stress level.

This week’s experiment will focus on the concept of operacy (coined by de Bono of Nine Thinking Hats fame). I am going to evaluate each task as I load my short list for simplicity, practicality, and effectiveness. I believe this will yield more productivity, and might help me identify where I need to know more before I dive into the task (perhaps do a spike).

Previous Entries in  Monotasking by Staffan Nöteberg

Week 1 – Logistics, Game Plan, and Preface – https://bit.ly/3x1oVap 

Week 2 – Introduction – https://bit.ly/2TXVfwt 

Week 3 – Monotasking In A Nutshell – https://bit.ly/3gGMb72 

Week 4 – Cut Down on Things to Do – https://bit.ly/3wt1ENL 

Week 5 – Focus on One Task – https://bit.ly/3hK2XDU 

Week 6 – Never Procrastinate – https://bit.ly/2UXPDDp