Are you disappointed with your Agile rollout?
Not seeing the benefits the Agile zealots promised?
Don't pay attention to the Agile zealots!
Smart execs leverage empirical evidence. Mediocre managers get sold. Don't be mediocre!
So what is the empirical evidence? As it turns out, some organizations gain significant benefit from Agile. Some do not. Why?
Human nature. People who lack confidence tend to resist change, while confident professionals thrive on change.
Lip service Agile is a term frequently associated with an IT group who attempts to create the appearance they have adopted Agile yet continues using legacy development practices. A common strategy is to pepper communications with word "Agile" hoping management will confuse that with actual Agile adoption. (I've seen this a number of times.)
Fortunately there are good ways to understand whether your organization is really Agile. Here is a list of some of the most common symptoms:
- Agile novice syndrome. Agile can be quite appealing and the IT world is rife with stories of well meaning folks who've read about Agile and talk their boss into letting them try it. However Agile is very difficult to "get". If your staff is running an Agile project without an experienced coach, it is almost certainly going to fail to realize Agile benefits.
- Half Agile. When organizations adopt Scrum but retain legacy development practices. Scrum assumes the use of industry best development practices. The safest bet is to adopt Scrum and Extreme Programming.
- Fragmented Agile. Well meaning managers who do not personally agree with specific Agile practices pull the plug on critical activities. Fortunately identification is simple: quiz the team. They should be doing all of these activities:1. Pairing at least 6 hours per day
2. Writing unit tests first
3. Attending no more than one, daily, 10 minute stand-up meeting
4. Engages at least one full time product owner and acceptance tester
5. Estimates are expressed in story points, and not associated to an amount of time
6. Iterations are with 1 or 2 weeks long
7. Runs ALL the various Scrum meetings (retrospectives, iteration planning, etc.)
8. Does NOT have status meetings
9. Maintains a burndown chart
10. Calculates the velocity each iteration
11. No one assigns tasks to other people
12. Performance testing starts early in the project
13. Requirements are specified by user stories (that fit on an index card)
14. The continuous integration server runs all day at approximately 20 minute intervals
15. Delivers user observable results in every iteration for every story
16. All stories are small enough that they can be completed within an iteration
17. Stories are not done until the product owner agrees they are done
18. Detailed requirements are not captured until the associated story is scheduled to be worked on
19. Technical documentation (other than architecture) exists solely in executable tests
20. Failing tests receive top priority; 100% of tests generally pass
21. Test coverage is nearly 100% (some trivial code can be excluded)
22. Bug detectors (like FindBugs) are run as part of continuous integration
23. No more than the minimal amount of code needed to complete a story is written
24. Code is committed to a source code repository daily
25. Every member of the team takes ownership over the entire code base - Cowboy Developers. Strong willed developers sometimes try to skip specific practices they personally don't agree with. For example, if your architect laments that not everyone is writing tests, you need to fix that.
- Assertiveness Challenged Leaders. Sometimes leaders decide it's easier to bend to a strong willed developer than enforce standards. You need to fix that ASAP.
- Unsupported Agile Coaches. Agile coaches must have the final say.
- Insufficient Buy-In. Upper management must be 100% behind the Agile effort.
- IT Isolation. Everyone in the organization associated with the project must agree to Agile processes. Agile is implemented by the entire organization.
