An early experience I had with a development shop trying to incorporate the Agile concepts did not quite work out as thought.
Some background (with a few changes to keep the team anonymous). We had a typical organization structure for a small software product company. Separate groups for Marketing/Sales, Product Management, Development, and Quality Assurance. The Development team was also responsible for all product packaging and deployments. PM was responsible for customer support and handed most issues off directly to development. There was one person that documented requirements for the larger items, while smaller ones where written up in tickets.
Our challenge was a huge backlog of defects as well as major pressure to incorporate new functionality from the sales staff. Our biggest gap was reporting, which as is not unusual, was left to the end.
In an effort to pacify the customer, and a true desire by the development staff to improve and use new techniques, the release cycle was shortened from months to weeks. Nothing else in the process changed other than compressing both dev and QA time. While fixes where provided to the customer more quickly, the backlog reduction pace did not improve, and if anything, quality suffered.
My point in all of this is to make sure I SHOUT from the rooftops – going Agile does not equate to just reducing each phase of a waterfall process – if it looks like Waterfall, acts like Waterfall, provides results like Waterfall, then it probably is Waterfall.
One last thought so as not to leave an incorrect impression – there are some cases where sticking with a Waterfall process makes sense, if done correctly. But don’t expect to achieve the Agile value proposition.
I am sure that there are some of you with the same experience, please share . . .