I stumbled across a document describing the government's approach to agile software development.
I didn't read it really closely, because I was just looking for some of these bullet lists at the time.
However, I think that they may have nailed it with the 14 Challenges.
GAO identified 14 challenges with adapting and applying Agile in the federal environment:The problem seems to be largely one of unlearning the way that software was done in the days before agile. People got used to working alone, being told what to do, being held individually accountable for work items, working with customers in a continuous way, not having big design up front.
- Teams had difficulty collaborating closely.
- Procurement practices may not support Agile projects.
- Teams had difficulty transitioning to self-directed work.
- Customers did not trust iterative solutions.
- Staff had difficulty committing to more timely and frequent input.
- Teams had difficulty managing iterative requirements.
- Agencies had trouble committing staff.
- Compliance reviews were difficult to execute within an iteration time frame.
- Timely adoption of new tools was difficult.
- Federal reporting practices do not align with Agile.
- Technical environments were difficult to establish and maintain.
- Traditional artifact reviews do not align with Agile.
- Agile guidance was not clear.
- Traditional status tracking does not align with Agile.
Way down in the list were challenges with technical environments and new tools. Two items out of 14.
The rest is cultural.
What lesson did you take from this?
No comments:
Post a Comment