When working software is not enough
A team that followed agile practices still finds itself in trouble.
http://www.infoq.com/presentations/A-Story-of-Project-Failure-Mitch-Lacey
Points that stand out a.k.a note to self
Signs that project was in trouble but got ignored - starting 35 minutes
- a statement of work that took 6 months. [requirements were unstable]
- team was blind to complexity of customer organization Having a customer representative does not actually mean he or she represents the real customers
- customer IT organization was not involved
- customer thought of agile in terms of waterfall development
- No accountability on side of customer
Common thread I see is a breakdown in communication. What people missed big time was the assumptions both sides made. Customer assumed everything they wanted would get built. The dev team assumed the customers understood that the product backlog determines what gets built, that its a finite bucket.
Lessons Learned - starting 50 minutes
- customer representative did not take accountability for their decisions. Business users changes requirements that was validated by the customer rep
- Team failed to hold customer accountable for their decisions
- Having the data does not mean you are right
- No true project owner. One was concerned with time/money. Another was concerned only with functionality. [Two headed monster]
- Team did not learn about the real project approvers until later
Takeaways
- If you know the true project cost - don't fool yourself in believing you can cut it down but moving work to the customer.
- Customer education is paramount. There has to be a plan for continuous education.
- Raise uncomfortable truths - takes courage [an agile value]
- Build an escape plan. [Each building has a fire escape]
--------------------------------------------------------------------------------------------------
Questions it raises in my mind
- Should there be an agile-fitness test/assessment for dev teams and organizations - before you start out an agile project?
- How much controls should be in place to stay agile without descending into chaos/anarchy?