Planning for Developers from Knowledge Worker Perspective
Planning is a controversial topic in software development. There is a feeling that we, software people, we don’t want to plan at all. The outsiders might have a point. Even though lack of planning arguably makes our lives harder than it should be we still don’t want to plan. There are steps you can take to get past these preconceptions and derive immediate benefits. Read more to find out how.
Why We Don't Like to Plan
Let’s start with why we don’t like to plan: (1) we believe that our work is so creative that it cannot be planned and (2) we don’t like to plan because we tried it once and it didn’t work for us. We rarely think about what’s so hard about planning, though when we do, we will conclude that while it may be hard, it is not impossible. It can be learned, and we can get better and better at it.
The first one is a doozy: our work has many creative elements. And any given project is only about 10 to 20% new, the rest is stuff that has been done before, and can be planned with fair accuracy. Once we plan that out then we have more energy left to focus on the creative part of the project. Usually though by the time we get through the drudgery, we are no longer able to focus, and our creativity suffers.
The second one is true about all new activities: at first we are never good at anything. It takes practice. When we give up on planning right away, we deny ourselves the chance to ever get better at it.
Deep down we don’t want to plan. But the world of business conspires against us: businesses run on commitments and without plans we cannot make reasonable commitments that we can keep. So we end up making lousy commitments that we miss and that make us look bad. The stigma becomes hard to shake.
How can we get past this? Software development is knowledge work, and we should think of it that way. Here is how we can look at planning from a new perspective, as defining work. And here are some practices that can help us when we are performing the work. Taken alone these might not make a big difference. Taken together, each building on the other, will measurably improve your and your team’s software development performance.
Software Development is Knowledge Work
Knowledge work is done in at least two distinct phases—though for some people these meld together, severely limiting their learning: (1) Define the work, and (2) Perform the work. Because they are distinct, you can improve them only by separating them. They each require different parts of your brain to do them.
Define The Work
Given the unique nature of knowledge work, this can only be done by the person who will be doing the work. Others are not in a position to define the work for a knowledge worker. There are some exceptions, for example when a more experienced person defines the work for a less experienced person.
What does it take to define the work? The knowledge worker must think through the problem they have in front of them. Decide what is known, what is unknown, devise the steps to solve the problem, and write the tasks for those steps. For each of task it might also be helpful to identify what knowledge and input is required to successfully complete the task.
The steps often belong to iterations, where certain steps are repeated until a condition is met. We are ill prepared to capture processes that contain iterative steps. Our mind works by thinking of activities in sequences and not loops.
A tricky aspect of planning is separating research work from development work. Research can only be time boxed while development can be estimated. For a research task, when the time is up, then we take stock of what we learned and make a go/no go decision. If we learned what we were after, then we define development tasks to be included in the next iteration, but if we still didn’t learn enough, then we decide if we invest more time into learning, or we cut our losses and look for a different way to solve the problem.
Good task definition is done from the perspective of the knowledge you expect to learn. This learning occurs as you work on tasks one after another, and with each one you learn more and more of the current problem domain and the current development environment, the API, and the tools you use. Something that might have been difficult and time consuming to do when working on the first task can become routine when getting to the 10^th^.
Start by building a rough plan for your work. Then, using the guidelines for detailed planning, elaborate your draft further. Estimate each task by thinking only in terms of Effective On-Task Time. Keeping the time pure of noise, makes it possible for you to improve how you do things. If the time that you record includes other variable time periods, then it is difficult to decide what really contributed to the completion of the work.
Perform The Work
You’ve got the tasks defined, it’s time to get the work done. At first, your biggest problem might be that your time is fragmented, you are getting interrupted a lot, either by others, or by yourself. Or that you are trying to multitask between competing priorities. We are not used to focusing for 60 to 90 minutes and as a result, our work suffers: it takes us much longer to get anything done. If we can find our "flow" we can get our work done with ease.
Next there is the unavoidable “cold start problem.” Every morning we must build up the context for doing the work in our head. The afternoon before we had an awesome context, but now it’s gone. We must figure out a way to externalize our context at the end of the day, capture it, and reload it the next day so that we can be productive again.
As you perform the tasks, take notes:
- Record your thought and observations about the software work you are doing.
- Validate the assumptions that you captured during task definition.
- Record how things actually worked out versus what was planned.
- Record the time that it took to get the work done and compare it to your estimate.
- Identify any forgotten tasks. Note them down and think about how come that they were forgotten. Calculate what percent of the tasks were forgotten and plan for forgotten tasks next time.
Why Track Time?
The simple answer: so that you'd have some data and know how long things take. We seem to be awash in data, yet have little to no personal data about our own process.
Recording how long something took helps us estimate similar tasks in the future. Our goal with time tracking is to be "close enough" and get better at estimating similar work that will invariably come up.
Recording time alone will not be enough, though. We also have to get better at task analysis, at identifying when a task is truly similar to another one, or in most cases, what part of a given task is the same as another task.
Summing It Up
It is possible to get better at planning. It is a skill that we can improve by practicing and collecting data on how it went. We can improve planning just like we would improve any other skill. Get started today.
References
- David Allen. Getting Things Done: The Art of Stress-Free Productivity. 2002. Amazon
- FranklinCovey. Project Management for the Unofficial Project Manager. 2024.
- Mihaly Csikszentmihalyi. Flow: The Psychology of Optimal Experience. 2008. Amazon