Tag Archives: Planning

Effective On-Task Time

, ,

Software development is knowledge work. We use knowledge, take input as knowledge, and the output we produce is knowledge. Our output is executable knowledge. According to Peter Drucker, the 21st century’s defining characteristic is knowledge work. We, software engineers, are right in the middle of it. Drucker writes that manual worker productivity during the 20th century increased 50 times. He admonishes us to improve knowledge worker productivity during this century as much as we improved manual worker productivity during the last century. He postulates that the developed nations of the future will be those that will make their knowledge workers productive.

Unfortunately, we seem to have a hard time measuring productivity. Economists have a straightforward measure of productivity: the value of the output divided by the time required to create it, expressed in dollars per hour. We need to figure out how to make this definition operational for software developers. A component of this measure is time.

Let’s start with Effective On-Task Time or EOT. This is the time that you spend creating the deliverable that is the target of your task. You keep this number pure, devoid of anything that didn’t directly contribute to the output. Your objective is to measure the time that the task took. You can find references to the concept of “Task Time” in a number of places. Watts Humphrey writes that “task time is what engineers spend working on scheduled tasks.”

And herein lies the heart of the matter: EOT is about working on something that you planned to work on. It is about your ability to meet a commitment. The plan is your commitment. The time that it took to complete the task is reflective of your ability to understand the work required to meet that commitment.

EOT doesn’t include time for any activities that don’t matter to the work of creating that deliverable. The interruptions from your co-worker, phone calls, and breaks don’t count. Some of the activities may tangentially work toward it, but your objective is not to account for every minute, but rather to count those distinct minutes when you know that you are moving the needle forward.

At the end of the day, EOT matters first and foremost for you. It helps you understand how good you are, how well you understand your work. It builds your confidence. When you repeatedly make aggressive plans and meet them, you know that you are becoming the engineer that you always wanted to be: outstanding.

References:

Build a Rough Plan for Your Work

, ,

Planning is a topic that I find myself coming back to time and time again. I’m asked enough questions about it so I decided to write down some of the answers. Folks who have not had to do any planning are stumped when asked to make a plan. I found that planning can be rather intimidating until you start with writing down what are the deliverables and what is the time frame. This will get your thinking started in the right direction. This and upcoming notes are here to help you get started on planning your own work.

Consider this scenario: you get assigned to a project, but instead of being the one you dreaded, this is one that you are excited about! The technical lead held an effective iteration kick-off meeting. You picked up work on a couple of features that you thought were really cool. You are expected to make a commitment to deliver the features at the end of the two-week iteration. Can you do it? How sure are you? How do you begin to build a plan for your work?

The first step is to decide how much time you can afford to spend on each feature.

  1. Kickoff (1 day)
  2. First feature (4 days)
  3. Second feature (4 days)
  4. Wrap up and demo (1 day)

Next, estimate how you intend to spend the 4 days you budgeted for each feature. You must think of your time as money. Spend it well. Let’s suppose that your technical lead had done a good job coming up with granular features, and you can indeed implement each feature in 2-4 days. Here is how you can “spend” your time during the iteration:

  1. Iteration kick-off meeting (1/2 day)
  2. Plan the iteration (1/2 day)
  3. Design the first feature (1 day)
  4. Implement the first feature (1 1/2 days)
  5. Test the first feature (1/2 days)
  6. Prototype the second feature (1 day)
  7. Design the second feature (1/2 day)
  8. Implement the second feature (1 1/2 days)}
  9. Test the second feature (1/2 day)
  10. Fix the defects found in integration & system test (1 day)
  11. Demo the iteration results to the team. (1/2 day)
  12. Buffer (1 day)

That’s it. This is your rough plan for the iteration. If you wish, you can call this a time budget and not a plan. If you are to deliver the features at the end of the two weeks, this is all the time you have. The key point is that this plan, even with its limited details, shows you what time can you afford to spend on each feature. The presence of the buffer in your plan is the clearest acknowledgment that you don’t yet know enough. When new things come about, you won’t have to replan your entire plan. You can just eat into your buffer. However, once your buffer gets exhausted, then you need to rework your plan.

Looking at this plan you might think that you won’t be looking at times at both features. That should not be the case, especially if they are related. It just means that now you have a way to get the work started. As you get into the details of the work, you will refine this plan. For ideas on how to move forward take a look at What do you know? and Guidelines for Detailed Planning. There are many other aspects of planning, e.g. getting some data on how you are doing, and how to improve your planning skills. For now though, just get started. As the old Chinese proverb puts it:

The one thousand mile journey starts with the first step.”

Ready! Set! Plan!

Mastering Deadlines

, ,

In Living with Constraints, I touched on a topic that is on the mind of software people: managers and developers alike. The time constraint, also known as “The Deadline” is of particular angst for some technical people.

Many people have a fear of deadlines. They are as frightened by them, as they are of speaking in public. For developers, the mastery of both can be a critical success factor. For managers, they are a survival skill.

What happens if you have a problem with deadlines? Maybe right now you have difficulty meeting the deadlines thrown at you, and you have given up on being able to meet them. Not meeting deadlines can be detrimental to your business and your career. So, how do you get out of this?

The age old advice is right on the mark: start out by setting small deadlines that you can meet. Get early wins. The only way you can get better at meeting deadlines is… by actually setting and meeting deadlines.

Along the way it helps if you remind yourself as to why are you doing this: you are getting better at meeting deadlines, because deadlines are nothing more than commitments. The world runs on commitments. Both your business and personal life depend on commitments. Your ability to succeed depends on your ability to make and meet commitments. Other people count on your output. You shouldn’t let them down. And you count on commitments from others. Once the chain reaction of missed commitments and deadlines starts, the endeavor can spiral out of control.

What is a good first commitment? Select a deliverable that can be done in 30 minutes or less. Make a commitment to yourself at the beginning of the day that you complete the work by the end of the day. That’s your first deadline. Here is an example: “I provide feedback to John on the white paper by 5 pm today.” Repeat this for a week.

Once you successfully meet your deadline every day for a week, then set yourself a slightly more ambitious goal. Make the next deadline one that involves between 5 to 10 mini deadlines to deliver on a more complex deliverable (requiring about 5 hours of total work). Then work yourself up to 20, 40, 50 hours of commitments involving many intermediate deadlines. Meet each one, and see your confidence grow.

As you set and meet commitments the word will get out that you are a person to trust with projects. You will become every more successful. And you will see your career take off.

______

PS: The Deadline is a book of fiction by Tom DeMarco. The author illustrates many issues surrounding software development. The main character of the book, Mr. Webster Tompkins, the project manager, sets up three teams for each product to develop the same system with different methods. Make time to read it.

What’s So Hard About Planning?

, ,

In the software business where most people don’t seem to agree on anything it seems that everybody agrees that planning is hard. (The only thing that seems to be even harder is tracking to the plan and regularly replanning, but that’s another story.)

Why is it that we have such a hard time with planning? Our thinking about the goals and benefits of planning seem to stay in our way. Here are four mistaken beliefs that many folks have and what can be done about them:

1. “It is not worth planning, life’s changing too fast.” Life is changing fast, but that doesn’t mean that it is not worth planning. It just means that we need to evolve the plans as things change. A plan at best represents your thinking in a moment in time. As you learn more, you need to improve on your plan.

2. “The only reason to plan is to figure out what the end date is, but they always give me the end-date anyway.” “They” might be the management, client, architect, team lead or that “other” team; you pick. Knowing the end date is good, but you still don’t know what’s included. Of course, you respond to this that: “they” also tell me what I have to build. However, “they” are unable to specify how much of those things to build. That is still up to you. It is up to you to figure it out how to make it happen. If you cannot find a way, at least you can tell “them” early that you will not be able to make this happen. And, you will be be able to back up your statement with a detailed plan that shows that you had thought through the problem.

3. “I cannot create a perfect plan.” Nor can anybody else. You need a plan at the level of granularity that can help you perform your work. You are creating this plan for yourself (or your team), hopefully not for others. Create something quick, then updated it “early and often.” The plan needs to represent your best knowledge at the moment you created it. Accept the fact that you will learn as the project progresses. Learn to live with incomplete data. These are key to your success as a software engineer.

4. “I don’t know how to plan. I am not given the opportunity to go to a class to learn it.” Nobody was born with perfect planning skills. You may have the natural talent to think through problems with incomplete data (which helps), but everybody can learn the mechanics of planning and everybody can become pretty good at it. It is your responsibility to seek out learning opportunities. Let’s face it: nobody has your interests at heart more than you do. So, it is your job to find ways to improve your skills. Once you learned the basics, then keep practicing.

To sum it up: A plan is a roadmap to project completion. Just like any other map: “when the map and the terrain don’t agree, trust the terrain” and update the map. Planning is an acquired skill. With practice you can get good at it and you will derive benefits to make it worth learning it.

Living with Constraints

, ,

Life, especially software development life, is never without constraints.

Time Constraints

  1. The software has to be released on a certain date, set well in advance. The only option is to plan based on the time budget.
  2. Given that I have this much time, what can I fit into this time?

Software Correctness (or Incorrectness) Constraints

  1. The software that you work with has flaws in it.
  2. How many flaws?
  3. Are the flaws of the software making it unusable? This is not any different than any other software you are trying to use. Windows has flaws in it, however once a problem is discovered, you are always trying to use the program in a way as to avoid that particular flaw.

Incomplete Knowledge Constraints (Requirements -> Problem -> Solution)

  1. The understanding of the requirements will evolve as you move through the project. More so, even the understanding of the folks who specify requirements will evolve.
  2. Your understanding of the problem evolves.
  3. Your understanding of the solution evolves.

Each constraint requires a different treatment. Each poses risk, therefore each needs to be dealt with, or the project will get into jeopardy. The questions to ask about each are:

Time Constraints

  1. What can I do in 2/20/200 hours?
  2. What % of my time should I spent on a given activity?
  3. What is the activity that only I can do?
  4. What is the activity that I can do that is visible?
  5. What are those activities that I can do to reduce other’s dependencies on me?
  6. What can I finish now to unblock to others?

Software Correctness

  1. Do I have proof in form of running code that this API I want to use works in the way I want to use it?
  2. Given that I found a problem with this API, is there a workaround that I can use?

Knowledge Constraints

  1. What are the requirements that are at risk to change because of real or perceived lack of clarity/definition/etc.?
  2. Is the problem formally described? If not, why not?
  3. Is the solution presented on paper proven to be correct (empirically or mathematically/logically)?
  4. Does the solution provide flexibility to cover for the risk of changing requirements?

People’s Skill and Knowledge Constraints

  1. What are the skills available in the team?
  2. What are the growth goals for the people on the team?

There is no constraint-free state. Our job as software engineers is to figure out a solution that can be completed within the constraints of time, people, money, etc. that we have. It is not an easy task, but that’s what makes it fun.