Agile / Process Improvement / Software development

Code Debt: Neither A Borrower…

Posted on:

Code Debt is the debt we incur when we write sloppy code. We might do this to rush something out the door, with the plan to refactor later. Agile methodologies focus on delivering functionality quickly. They also invoke a mantra of refactoring – “make it better next release.” This can create pressure to “get it done” that overwhelms the objective of “get it done right.” Taking on code debt like this is about as smart as using one credit card to pay off another one.

Requirements / Software requirements specification

Joel Spolsky Speaks Specs

Posted on:

It seems that specs are like flossing: everybody knows they should be writing them, but nobody does.

Another for the wish I had said that list. Joel Sposky wrote a four part series on writing functional specifications in Oct 2000. Joel’s opening position is that all projects lasting more than a week, or with more than one developer, will be completed faster with specs than without them. He presents three giant reasons to use a requirements document as part of developing software
Three Giant Reasons

Consulting / Process Improvement / Product Management / Project Management / Requirements / Software development

How To Use Timeboxes for Scheduling Software Delivery

Posted on:

Roger had a great suggestion in the comments to our previous two-part post on scheduling requirements changes based on complexity. Roger pointed out that we had not explained what timeboxing is, but implicitly used the principles of timeboxing in our proposed process. In this post, we explain timeboxes and how they are used.

Agile / Communication / Consulting / Process Improvement / Project Management / Requirements / Software development

Scheduling requirements changes – part 2

Posted on:

This process goes against agile principles on paper, but makes teams more agile in practice. Scheduling delivery of a project is an exercise in managing complexity. Scheduling changes to the requirements on the fly is really only marginally more difficult. The key to managing changes is to set expectations with our stakeholders. By defining rational deadlines for change requests, we assure ourselves that we can manage the changes. We also demonstrate responsiveness to our stakeholders. Rational deadlines are not arbitrary deadlines nor are they unreasonable deadlines. Deadlines that vary with the complexity of the changes are rational, easy to communicate, and easy to manage.