Tag Archives: Software Process

Agile & CMMI & me

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.

The “One Right Process”

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:

  1. The problem needs to determine the process required to solve it.
  2. 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.
  3. When faced with a new problem, the project team assembles the exact process that solves the overall problem.
  4. 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.

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.

More on Prototyping

, ,

To convert the unknowns into knowns, you need to aggressively prototype.

What to Prototype?

Here are some examples:

Prototype the use of an API. Create a prototype to see if the API that you need to use works the way you think it does. This includes confirming that it can be called with parameters of the type and range that you can provide. The API may belong to a component that one of your team mates wrote, or it may belong to a third party library. Either way, you want to be absolutely certain about how to use it. No amount of documentation reading will substitute for a well pointed prototype.

Prototype an algorithm. Create a prototype to prove to yourself beyond reasonable doubt that you can implement the solution to a problem.

Prototype an interaction. Create a prototype to show that the interaction sequence or method that you want to use in your application actually works for the intended use. You can take the prototype and usability test it, incorporate the feedback, and then place it into your application.

What should the prototype look like?

Since we are talking about software development, your prototype should be a software program. A small program. As small as possible. A program that answers one or two critical questions and that’s it.

The prototype should be like the small program that you write to prove to the API writers that their API has a defect. It has to be small and prove one point. Your objective from the prototype to learn something that you didn’t know, or confirm something that you suspected.

How to Prototype?

Pick one or two key questions that you want your prototype to answer and focus your small program answer them. Keep in mind common software engineering and experimentation principles as you decide on how to proceed:

  1. divide & conquer: write multiple prototypes as needed
  2. reduce scope: keep the scope of each prototype to a minimum
  3. isolate concerns: separate the concerns so that you can establish root cause
  4. confirm behavior: confirm that an API behaves exactly the way you had thought that it would under the conditions that you anticipate
  5. validate assumptions: validate that what you think is true, it is indeed so
  6. validate invariants, pre- and post-conditions: half the battle is to identify these; you get extra credit for validating them

I have noticed that after a while some prototypes that started out with the best of intentions, become monsters. Don’t be tempted to stick another one or two topics into an existing prototype. Your prototype will become so complicated that you cannot confirm root causes for outcomes. Then you lost your ability to know things for sure.

Lastly: the most important rule is a well worn one: KISS=Keep It Simple & Sufficient.

Why Prototype?

, ,

Every once in a while I am surprised by somebody who says that prototyping is such a waste of time. For quite some time I have taken for granted that prototyping is a fact of my software engineering life. Maybe it is worth asking: what is the problem for which prototyping is the answer? Or, in other words: why should you prototype?

You should prototype when you don’t know enough about about the problem. Which is almost always. When your knowledge is lacking in some aspect, then it is time to write a prototype. When you don’t know enough about an API, some requirement, the operating system that you are designing for, the libraries that you want to use, and so on. When you feel that you have to answer a few clarifying questions, then it is time to answer them with a prototype.

The short answer is that you prototype because you don’t know enough to proceed with the project at an acceptable level of risk.