February 4, 2012

BigVisible Blog

Agile Doesn’t Work For…

Ever run across these guys?  People whose lack of experience or fear of change cause them conjure up all kinds of reasons why agile won’t work for their project?

Let’s bust those myths!

 

Myth: Agile Doesn’t Work for Projects in the Highly Regulated Medical Environment.  (The reason usually given is that FDA regulations require detailed requirements prior to project approval; hence, waterfall.  However, in reality, you can develop in phases, with small incremental sets of requirements and the FDA requires only enough documentation to demonstrate your process.)

Truth: Abbott Labs overcame medical device regulation and stringent Class 3 certification and developed the m2000 Real-time PCR Diagnostics System, a human blood analysis tool, with four agile teams.  Compared to the prior methodology in use, this project resulted in a less cumbersome process, fewer defects, a reduction in costs of 43%, and a reduction in cycle time of 25%.

(Rasmussen, R., Hughes, T., Jenks, J. R., & Skach, J. (2009). Adopting agile in an FDA regulated environment. Proceedings of the Agile 2009 Conference (Agile 2009), Chicago, Illinois, USA, 151-155)

 

Myth: Agile Doesn’t Work in Government

Truth: The FBI overcame a CMMI level 3, ISO 9001, government-mandated document-driven waterfall life cycle and developed the Domestic Terrorist Database & Data Warehouse with three agile teams.  Compared to the prior methodology in use, this project resulted in significant improvements in release planning, developer satisfaction, and a focus on the true goal: “to catch bad guys.” [Read more...]

You’re only as good as your feedback loop

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. [Read more...]

The Truth About Fixed-Fee, Fixed-Scope Contracts – Part II

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. [Read more...]

Pages: 1 2

The Truth About Fixed-Fee, Fixed-Scope Contracts – Part I

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. [Read more...]

Pages: 1 2