A look back at the best from a year ago.
Different people approach the same goal very differently. When we don’t truly identify our users, we end up with software that dehumanizes, waters-down, and otherwise fails to succeed at anything more than grudgingly tolerated functionality. Even worse, we may ignore the needs of our key demographic, resulting in software failure. When we use personas instead of generic use cases, we can avoid both the misery of a failed product and mediocrity of marginal success.
Tarun Upadhyay wrote a fair criticism of our previous post on why incremental delivery is good on his blog today. It is great that he is extending the conversation, and he makes a couple valid points. We definitely missed a big benefit of incremental delivery, and will cover it in this post.
Here are the main points from Tarun’s critique:
The analysis is rather simplistic and does not assume any additional gains from having all four pieces working together (typical in many but not all projects) and also does not take into many other benefits from agile iterative releases like:
a) creating a release structure forces good habits like: continous integration, automated build management and consistent configuration across development, QA and production
b) many releases forces customer to see the product early which reduces surprises and produce better alignment around what customers want vs. what the team is developing
c) earlier releases brings out many feature requests from the customers earlier in the cycle (causing fewer design changes and less rework) reducing the overall costs.
d) estimates are better when deliveries are iterative.
We like incremental delivery. We don’t promote it because of the correlated benefits that often happen when we do incremental delivery. We promote incremental delivery because of the two big benefits that are caused by incremental delivery.
Should we adopt an agile process for our team? Methods and Tools has posted a two part article titled Adopting an Agile Method. In thier article, they explore five areas of consideration. We provide our thoughts on each area.
Five areas to consider (from the article)
- Our organization’s culture
- Our customers and how they prefer to interact with us
- The types of projects we do
- The tools and processes that we currently use
- The strengths and weaknesses of our software-related staff
They go on to make points in each area. Here are our thoughts on them