Of all the virtues within Agile software development, none are more important than the numerous means of receiving feedback layered into the entire Agile life cycle. The team shares a quick checkpoint at the daily stand up, the scrum master fosters earnest discussions of team effectiveness with periodic retrospectives, project stakeholders can clearly see and interact with potentially shippable code at regularly occurring show and tells and ultimately the entire community can offer feedback due to frequent releases. This is a powerful cycle as early and frequent feedback can help move a product in a positive direction, keep a team excited, and ultimately lead to more business value. But this entire structure is predicated upon the team receiving valuable and relevant feedback. Having such a structure is not enough, we need to make sure the quality of our feedback loops is sufficient too. more »

Time Wasted Managing Contract Changes
Technology projects are dynamic. Change is inevitable. Change comes as a result of many factors: shifting priorities, changing opinions, new learnings, volatile markets, shrewd competitors, emerging technologies - just to name a few. So how are changes dealt with on Fixed-Fee, Fixed Scope (FFFS) contracts? Enter the super-charged change-control process. more »

Right around the time the dot-com bubble burst, large companies began focusing their technology almost exclusively on cost-cutting initiatives. It makes sense: it was time to reduce the bloat that had been accumulated during the hay-days of the bubble. It was at this time that the Fixed-Fee Fixed-Scope (FFFS) contract became a wildly popular vehicle to control project costs. Companies and vendors would agree up-front to delivering a predefined set of functionality or requirements for a set price. Any future changes to scope would be negotiated and agreed-to (in writing) by both parties. This is the first in a multi-part series on why Fixed-Fee, Fixed Scope projects are bad for customers. more »