10 Signs that you are really Wagile

 digg it |   delicious |   StumbleUpon |  reddit 

Yes, Wagile. For years now I have been going around as a certified agile Scrum Master thinking I was being humorous by introducing the term "Wagile" to those customers who thought they were agile but had fallen into a variation of agile that is best described by Wikipidia...

"Wagile software development is a group of software development methodologies that result from slipping from agile back into waterfall, doing a lot of short waterfalls and thinking it is agile, Waterfall model masquerading as Agile software development, etc."

OK, so I didn't introduce the term, but it is out there in abundance. Wagile usually comes about because a team or IT group is attempting to migrate to an agile methodology but they are either not given the autonomy to do so, the resources to perform in an agile manner or, worse still, they are bound by the old world of delivering huge Business Requirement Documents (BRD's) to stake-holders and are bogged down waiting for that elusive approval.

Don't get me wrong - I am not saying that I believe in the myth that Agile Methodology = Poor or non-existent requirements. The fact is, requirements are a critical part of running an agile development process, but one just takes a different approach when developing them. User Stories replace high level business requirements and the requirements being defined in one sprint will drive design and coding in a subsequent sprint. The net effect is that all these disciplines are active in every sprint of the lifecycle, but the relative emphasis changes depending on what stage you're at in the project. For example, Requirements tasks are being performed in all sprints, but they are emphasized more in the earlier sprints.

Compare this to the Wagile implementation where the team realistically is still performing a Waterfall methodology, just in a shorter timeframe. A lot of projects don't start out as Agile, they are in fact Waterfall and due to unrealistic deadlines and potential failure, deliverables are demanded in a shorter timeframe in order show progress. Teams simply have the same SDLC but are forced to deliver something short incremenets - e.g. 3 weeks or so duration. In this approach, requirements are usually being developed by the BA weeks ahead of a sprint starting. For example requirements for sprint 10 are being written while the coding and testing for sprint 7 is still being done. So how does this fit into the Agile Manifesto? Well, it really does not. The Agile Manifesto states "Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage". This simply can't be achieved if the BA's are not fully engaged in the current sprint but are instead focused on 2 or 3 sprints into the future.

So in the spirit of Jeff Foxworthy and "You might be a Redneck if", let's consider "You might be Wagile and not Agile if:"

1. Your Scrum team consists of 20 people
2. Your sprints have "Phases" such as Requirements, Design, Implementation, Verification and maintenance.
3. You have a Project Manager and he manages you via MS Project and a Gant Chart.
4. You are assigned work and asked for daily status reports instead of letting the team learn how to manage its own work.
5. You never push back, "This is what the product owner wants in this sprint, so we have to get it done".
6. Velocity is simply the speed you achieve when you are late for work.
7. Your daily stand-ups (if you have them) consist if Chickens, Pigs, Lions, Tigers and Bears...Oh my!
8. You are still required to produce a large BRD to communicate requirements rather than "Just Enough" to get the point across. Ideally this is managed in a tool with traceability and simulation to help in the communication process.
9. You are pulled off your current sprint to work on that "other project" you used to be on.
10. It is 1am and you have a new release being implemented and the whole team is not involved.