Time to Learn More

Via Steve Norrie’s weblog, I found Kovitz’s “Hidden Skills that Support Phased and Agile Requirements Engineering”. In phased development, projects promise large feature sets to a customer for future delivery. In agile projects, the requirements are refined over numerous little conversations with the customer, day in, day out. Kovitz claims the skills required for agile projects are different than the skills required for phased development projects.Kovitz is correct. The skills are not mutually exclusive, and they are different. Here’s my take on those skills:

  • Large chunk thinking (top down) vs. Small chunk thinking (bottom up): In phased projects, we’re used to break requirements into large chunks. We work on continuing to break down the large chunks (top-down requirements, design, implementation) into month-long or even a week-long chunk. Instead, in agile projects, you start with the smallest possible thing you can imagine. It should take a few minutes to implement. This is a huge stumbling block for many developers. The smallest thing they can imagine is weeks of work. Instead, it should be minutes of work. (okay, so maybe it’s 40 minutes of work, but it’s *way* less than a week)
  • No code ownership. In phased projects, a developer or several developers own modules. Each developer works as an individual. Each developer is responsible for his or her code. On the other hand, in agile projects, there is no such thing as code ownership. You work with other people, either as pairs, or choosing to refactor whenever and wherever necessary. If you’ve never pair-programmed, I highly recommend trying. It’s completely different from developing alone. I found it energizing and all-consuming. I was tired at the end of the day.
  • Write tests first. In phased projects, developers prototype and discuss prototypes with others (hopefully). In agile projects, developers write tests first, to see “What would have to be true for this piece of functionality to exist?” Too many developers don’t know how to test. (Too many testers don’t know how to develop, but that’s fodder for another blog entry.)
  • Conversation is expected. I’ve worked on phased projects where some people never talked to anyone else in real-time. They emailed, but they didn’t speak. That’s not possible in agile projects. If nothing else, the daily 15-minute standup meeting requires everyone say something. And, when you start building bottom-up, not top-down, you have more opportunity for conversations about how things could work.

Kovitz goes on to say that phased development requires representation of the system and excellent writing skills so that you can discuss what the product should look like and how it should work. And, the project needs to be able to negotiate deliverables, the customer needs to prioritize their needs, all things that are difficult to do.Does that mean we should never used phased delivery lifecycles? No. But it does mean that right now, many of us don’t have the skills to successfully complete phased delivery projects, nor agile projects. It’s time to learn more skills.

Leave a Reply