Why Agile?

About 10 years ago, when Agile started its expansion also in big corpos I was very sceptic about that. Then we have well known procedures, processes, type of documentation, project status metrics and tracking. We were happy, I would say.

Competition

Then product development was one big dependency. There was well defined chain of people

responsible for different phase of product development (Business 

Analyst -> Architect/Designer -> Developer -> Tester). Everyone would like to be Business Analyst or Architect because this was cool to create and design new things. Developers were rather bored – because of very strict design they didn’t have creative job. Testers were at the end of the chain still need to wait everything is finished and were frustrated because usually development were delayed.

Testers and developers were separate teams, having usually different managers not shooting to one gate. I remember this time as a
constant competition between tester and developer.

Having Agile gives everyone chance to prepare a design, preparing a demo to customer so everyone in scrum team is equal. No competition inside the Scrum team.

Evaluation

Before Agile team were usually big (about 30-40 people) and during 6-month period could develop many features. This was one big release from time to time, upgrades were usually very tough. Feedback from customer was not really appreciated because when it arrives team need to rework very complex solution, maybe change the complex design.

In Agile we would like to show new feature (maybe not complete yet or prototype) as early as possible. Having early feedback help the teams in delivering real value to customer – not only new fancy feature in documentation.

Constant quality

I was working in test department from the beginning and waterfalls’ time I remember as a constant fighting with quality. Our quality was good at the end of the product development (near GA) however with first feature developed in new release quality dropped down dramatically. This was well known and we had special quality metrics where we projected number of defects in different cycles. This was crazy because we treated product code as a sandbox in the middle of the development! At one my project at some point of time we had 100 severity 1 defects (potential blockers) so development manager asked us to prioritize which one are more important than others  J  Yes that was crazy!

Agile gives us strict requirement – quality need to be at the same level for the whole sprint. With no exceptions.

No support line

Probably last crazy think was having separate support line(s). When Product was developed, we released v1. When development team is working on new version (v2) support team is responsible for preparing fixes for v1. Some time there were no interaction between development team and support team so that development was not even aware of defects found by customer in their code!

Agile and Continues Delivery fix this gap and we have common development code (yes, not backport fixes!) and development team is responsible for fixing problems from field. Thanks to this they can learn on their mistakes to avoid similar issues for future.