strat-e-gy: a plan of action or policy designed to achieve a major or overall aim.
The New Oxford American Dictionary
The dictionary definition points us in the right direction. The software development strategy is your highest level plan for achieving your software project’s objectives. According to Watts Humphrey, the strategy is “the order in which product functions features or requirements are defined, designed, implemented, and tested.”
What does this mean? This means that the plan of action part of your strategy lays out what you build first, what you build next, and so on. It also lays out how are you going to validate the strategy. The strategy also lays out the policies for risk mitigation and decision making. Sections of the strategy may exists both along the developer – customer continuum and also along the system abstraction levels continuum. For details about these continuums see: Multilevel Planning and Component-Based Development.
The System Architect is responsible for the overall strategy. The strategy has to be sound enough that designers and implementors working on parts of the system receive from it the necessary guidance to aid their technical decisions. A well conceived strategy pushes the decision making down to the lowest possible level, closest to where the problems are encountered, while at the same time provides for the oversight necessary to build a coherent system.
Accompanying the development strategy is the testing strategy. The testing strategy focuses on the various testing activities, including the system validation and verification activities. It is constructed similarly and serves the same purpose as the development strategy, only for testing. The owner of the testing strategy may be the System Test Architect, if there is one, otherwise this is also owned by the System Architect.
Why do you need a strategy? Without a strategy it is difficult, if not impossible, to execute an iterative, incremental development process. The strategy ties the iterations into a coherent whole, and allows the team to move confidently toward the goal. Your first attempt at creating a strategy may feel awkward, but with practice you’ll get better at it. Why don’t you get started today?
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.
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.
- Kickoff (1 day)
- First feature (4 days)
- Second feature (4 days)
- 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:
- Iteration kick-off meeting (1/2 day)
- Plan the iteration (1/2 day)
- Design the first feature (1 day)
- Implement the first feature (1 1/2 days)
- Test the first feature (1/2 days)
- Prototype the second feature (1 day)
- Design the second feature (1/2 day)
- Implement the second feature (1 1/2 days)}
- Test the second feature (1/2 day)
- Fix the defects found in integration & system test (1 day)
- Demo the iteration results to the team. (1/2 day)
- 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!
Back in the second half of the eighties I have been using some agile practices, but we didn’t call it agile back then. We regularly pair programmed because my friend and I shared one computer; neither of us wanted to just sit and do nothing. Our workflow also included writing test programs (much like unit tests today).
In the early nineties I read “Managing the Software Process” by Watts Humphrey. This was my first introduction to the CMM. I found many of the concepts valuable, even though, I was working alone. The knowledge presented was applicable to my software engineering work, with the necessary adjustments for a group size of one.
Many years later, after the agile movement got traction, I was surprised that so many people had such strong feelings about the CMM given my positive experiences with it. In time I understood that there were many organizations that got their CMM implementations off track. They focused on paperwork, instead of changing the day-to-day work of practicing software engineers.
After over two decades of CMM & CMMI and over a decade of agile, the software engineering community is realizing that a sensible strategy is to integrate the best of both worlds. A recent paper published on the SEI website by Hillel Glazer, Jeff Dalton, David Anderson, Mike Konrad, Sandy Shrum urges us to do so: CMMI or Agile: Why Not Embrace Both! It seems that I am not the only one thinking so. Scott Ambler wrote a review of the paper at DDJ called: Agile CMMI: Complimentary or Oxymoronic? Read the paper, read Scott’s review, and decide for yourself.
This week at Agile Austin the conversation veered toward a familiar topic: each problem is different therefore we cannot apply the same process to them. We, software developers, want to believe this. Why? Because this can be used as a convenient excuse: we don’t have to follow a process if all problems are different. After all, we are on a quest to find the one true process that fits all programming problems, right?
Reality is more nuanced: when we look at each problem in its entirety, then indeed each problem is quite unique. When we divide a big problem into a series of smaller problems, then many of the smaller problems turn out to be run-of-the-mill everyday problems. We have seen them, and we have processes (not necessarily written processes) for solving them. Maybe we need to tweak a processes slightly because of a minor variation, but we can comfortably identify the pattern and follow the associated process.
A few of the constituent sub-problems, mostly the ones that provide the unique value proposition of the application, require unique treatment and attention. For these we need to create new processes. These are processes that are custom fitted to the new problem. These, however, are a small fraction of the overall problem.
It might help if we think in terms of process building blocks. Some of these building blocks are already available. We only need to create some new processes to custom fit a the new parts of the problem. As early as 2002, in my talks I have been proposing the following:
- The problem needs to determine the process required to solve it.
- A team that worked on a few problems together already has some processes that they used more then once. Let’s call these software process building blocks.
- When faced with a new problem, the project team assembles the exact process that solves the overall problem.
- For the brand new parts of the problem, the team creates new processes.
The “One Right Process” that solves all problems doesn’t exist. A “process framework” that contains concrete processes for “smallish” problems can be useful. Based on the framework we can create an instance of a process that fits the problem we have to solve. Then, we have to follow the process that we just created to solve the problem on hand.