Monthly Archive for: ‘March, 2009’

Explaining the business value of incremental development 3

Here is the second of two posts on iterative and incremental software development. My previous post focused on explaining the business value of iterative development while the objective of this one is to explain the value of incremental development.

Incremental Software Development Applied to Business Intelligence

Incremental Software Development Applied to Business Intelligence

Starting with the decision of using an incremental development approach as opposed to a sequential approach for the development of a BI solution results in 3 immediate outcomes:

  • Reduces overhead: Once the development team determines it will be using an incremental approach, this decision allows it to focus on small tasks and build on them. As such, it is no longer required to plan upfront for every component to be built which would be the recommended approach if the team only had one attempt at building the right software. By developing the application in increments, the team can focus its efforts on the tasks at hand within the known context and not worry so much about figuring out all possibilities at the beginning of the project.
  • Allows continuous integration: Building incrementally is a good step in the right direction but if the incremental components are not continuously integrated to make a whole, the development team wouldn’t achieve all the expected benefits. As such, the team would be building many items that could fit into a bigger whole without making sure all the pieces actually fit together. By continuously integrating the components, the development team ensures that throughout the development cycle, an integrated “application” can be tested and possibly demonstrated to the business community.
  • Allows test-driven development: Using TDD as a development practice forces the development team to prepare their test cases before starting their development. In addition, every time news conditions to be tested need to be integrated, the tests are documented before the code is written and then executed once the components become available.

In turn, these 3 elements lead to 3 clear outcomes:

  • Improved software quality: Preparing test cases before starting the development, enhancing the test cases with new possibilities as they occur, and continuously executing the test cases on the incremental components as they continuously get integrated within the global build improve the overall quality of the software being developed.
  • Reduced overall cost of the project: By spending less time on overhead activities and delivering better quality software, the overall cost of the development project is greatly decreased.
  • Increased ROI of the project: Combining the impact of the various outcomes increases the overall ROI of the project.
Posted on: 03-10-2009
Posted in: ROI

Do we really need defined timeboxes? 0

Wikipedia defines time box as “In project management, a timebox is a period of time in which to accomplish some task. (…) If the team exceeds the date, the work is considered a failure and is cancelled or rescheduled“.

When using an Agile approach to software development, this is exactly the dynamic we are looking for. We use time boxes to ensure commitment by the project team to meet the defined time lines. As such, the objective of time boxing is to limit the efforts and activities of the project team to fit to an agreed upon time frame. The longer the time box, the least commitment you will get from the team.

In addition to commitment, time boxing has the amazing effect of creating a sense of urgency. We have all seen development projects
scheduled to be completed in 12 or 18 months with a big time box – a milestone – to deliver the complete application.

When this happens, the project team typically has a more relaxed approach during the early stages of the project only to spend nights and
week-end toward the end of the project to complete their tasks.

Implementing shorter time boxes forces a different team dynamic. If a team only has 2 or 3 weeks to complete their iteration, they cannot delay their activities too much and potential delays will more quickly come to the surface. Time boxing has the benefits of increasing the visibility of such situation.

Short time box also can be used as motivational factor allowing the team to frequently see the result of their work instead of waiting until the
end of the project.

In addition when using Scrum, time boxing also forces the team to work backward to accomplish their objective. In order to deliver working software, the team cannot spend superfluous efforts on the analysis and planning phases and need to start on the development tasks early. Since the development approach is iterative, the team doesn’t have to worry about every single details up front but can address them as they move forward.

Of course, there needs to be control mechanisms to ensure the team delivers working software since meeting time lines with incomplete components would defeat the purpose of time boxing.

In combination with other engineering practices, time boxing is a great way to get the entire team focused and motivated and achieve better results with your software development projects.

Posted on: 03-3-2009
Posted in: Timebox