Waterfalling Agile

You can be pure Agile, you can be pure Waterfall, but have you ever been Waterfalling Agile? I have seen Waterfalling Agile, and it’s not a good scene. Essentially, when you are doing the worst of both worlds, thinking you are on top by taking the best of both, but you are wrong.

Where are the Requirements?

Requirements in Agile can be fluid, but they should always be thought out. A Developer can start with 80% of the requirements, as long as those 80% are the key, manageable, anchor requirements that aren’t going to shift another 17 times in the course of the sprint. If your 80% requirements consist of the small stuff, the priority 3 requirements that have a propensity to get pushed out, you might find yourself having completed “lots of stuff” but it not being the right stuff.

The converse is true as well, having your team wait and wait for requirements to be complete and not starting on anything or getting started on the notion of what they think they are building is just as bad as if they were working on the wrong 20%

QA is Special

When I work with a new development team, I’m constantly surprised at how often QA doesn’t know how long it takes to regression test a particular feature or the suite, or that they will get involved with testing when everything is done and completed…