Speculative design

Thu, 09 Feb 2006 10:59:58 GMT

From Agile Answers comes the following paragraph (emphasis added), which is pretty timely given the conversations I've had recently.

Do the simplest thing for the task at hand

Originally a pushback against speculative development (particularly in code frameworks), this guideline is very easy to distort if you want to attack agile methods. Developing incrementally does not (in my opinion) mean taking your brain out before starting. I generally have an idea of where I'm going when developing, based on knowledge and experience. I use that mental roadmap to decide how to write the next test. Sometimes I'll skim through and try a quick implementation of part of a feature to see if it looks right (quick meaning minutes, not days). Then I'll write the tests that exercise my intended implementation, which will probably change it slightly to make it more testable. Code is clay, not marble. Or at least it should be.

For me, the logical extension to this is to talk about iterative and incremental development in general. Take a common component. With a traditional waterfall methodology, common components are typically planned, designed and built upfront before being baselined as complete and ready to use. While this works, problems can arise later on in the project when you realise that the common component doesn't quite support what you need or, worse, provides functionality that you're never going to need. This happens because you speculated what was needed too early.

Iterative and incremental development provides a way for you to "do the simplest thing for the task at hand", yet it's easy for teams to fall into the trap of doing speculative design because they like to have a fully planned out schedule before starting off on the project, which is contrary to the adaptive planning approach recommended for iterative/agile development. As Darren says, you don't take your brain out before starting an incremental project - you still need to know where you're going.

Those common components will get built, but they'll be built when they're needed and, as a result, they'll support exactly the features that are needed. If you do build common components outside of the context in which they will be used, what do you say when somebody asks you whether they're finished? How do you know when you're finished?

How long is a timebox?

Mon, 23 Jan 2006 16:52:26 GMT

One of the most common questions about timeboxing relates to the length of timeboxes. How long should they be and what factors influence this decision?

While there are many recommendations out there, some of which are strongly tied to the development process you've adopted (e.g. Scrum recommends a month), the factor I would like to talk about is the skill of the team. Or rather, how much relevant experience they have. By relevant experience, I mean experience with whichever development process, team structure, technologies, tools, etc that are in use on the project. Based upon this information, you should be in a good position to find the ideal length of timebox that suits your project.

For very experienced teams, a short duration (say 2 weeks) allows for some very aggressive timescales and some very quick feedback loops, assuming that you would plan to do a release at the end of each timebox. On the other hand, a longer duration (say 4-6 weeks) is more suited to projects that are larger, more architecturally challenging or where the team is on a steep learning curve with the process, technologies, tools, etc. From experience, problems arise when you put a team that's on a steep learning curve into very short timeboxes and expect them to deliver. It's just not realistic to expect them to take onboard lots of new technologies *and* expect them to deliver something that's production quality.

The ideal length of a timebox for any particular project will vary and deserves some careful thought. Of course, adopting an iterative approach means that you have the flexibility to tweak the timebox duration throughout the project based on your growing experience.

Here at The Pragmatic Architect, we're interested to see what you you have to say. What are experiences here? What timebox duration works for you and why?

Coding the Architecture - iterative tag

Speculative design

How long is a timebox?