Here are my thoughts on the use of Agile methodologies for project management and product management.
Although a lot of companies implement and practice Agile methodology in its purest form, it makes sense for a lot of companies to pick and choose what parts of the Agile manifesto make the most sense, given their specific situation, where they want to go and what they are looking to achieve.
In my opinion, the Agile way of working can provide a lot of benefits in the requirements definition. The use of personas, scenarios and stories are a very effective and engaging way for the product owner to convey the details of what is expected from the product. The discussion of acceptance test cases during the elaboration of stories is also very useful for both the product owner and the implementation team (developers and testers). This method of product definition is far more effective than writing long, boring requirements documents in MS-Word with chapters, sections and formal language trying to describe what the product owner is thinking.
In addition, the concept of a backlog that combines user stories for new features as well as enhancements and bug fixes results in a clear model for prioritization from the product owner's perspective.
Now, on to the not-so-good or the complex part. On the development side, there is a lot of churn. Figuring out the number of stories that can be accommodated in a sprint or what to do when a story takes longer than a sprint or what happens when a story is deprioritized in the middle of a sprint or what happens when the estimate for a user story is found to be grossly inadequate can be extremely difficult. All these are tough questions and are difficult to tackle without a really good team with a really strong leader. It's not for the faint of heart. Test Automation and Continuous Integration can help to mitigate a few of the difficulties but I don't think it's enough. The next best thing to do is the factor in the time spent on refactoring, bug fixes, research and other "sundry" activities when the development capacity for a milestone or sprint is computed. This will also help in computing the velocity of the team which, in turn, helps more reliable and consistent predictions of the amount of work that can be taken on by a team in a sprint/milestone
On the development side of things, implementing Agile will necessitate certain prerequisites. For instance, it would need a team that is filled with generalized specialists. People who can do a lot of things well and also one or more specific things really well. It also needs teams with a certain amount of stability in terms of change. In other words, teams with members that stay together for long periods of time.
So, in a practical world, the above requirements are usually tough to ensure. Therefore, a hybrid approach to Agile adoption is needed. One area that Agile can cause a lot of misunderstanding is in the emphasis of working software over documentation. People misinterpret this to mean that Agile frowns upon documentation. However, I would like to look at it differently. I feel that Agile's recommendation is that greater priority should be given to developing or creating the software rather than documenting the requirements, the design and other such artifacts. In their opinion, the time is better spent developing the actual software that satisfies the requirements.
However, against this, we must take a realistic look at the way teams are organized and function over time. In most cases, teams get built and break up as members join and leave the organization or move up or down in their career. Teams also change in the amount of expertise they possess in a specific area, domain or technology. So, a truly Agile team is difficult to build and sustain over any great length of time. Also, as teams change in their composition and experience, it is important to continue the momentum of software development. This is made easier if the new team members have access to some form of documentation that would help them ramp up and start being productive sooner. So, documentation in some form is essential to build productive, scalable and sustainable Agile teams.
Although a lot of companies implement and practice Agile methodology in its purest form, it makes sense for a lot of companies to pick and choose what parts of the Agile manifesto make the most sense, given their specific situation, where they want to go and what they are looking to achieve.
In my opinion, the Agile way of working can provide a lot of benefits in the requirements definition. The use of personas, scenarios and stories are a very effective and engaging way for the product owner to convey the details of what is expected from the product. The discussion of acceptance test cases during the elaboration of stories is also very useful for both the product owner and the implementation team (developers and testers). This method of product definition is far more effective than writing long, boring requirements documents in MS-Word with chapters, sections and formal language trying to describe what the product owner is thinking.
In addition, the concept of a backlog that combines user stories for new features as well as enhancements and bug fixes results in a clear model for prioritization from the product owner's perspective.
Now, on to the not-so-good or the complex part. On the development side, there is a lot of churn. Figuring out the number of stories that can be accommodated in a sprint or what to do when a story takes longer than a sprint or what happens when a story is deprioritized in the middle of a sprint or what happens when the estimate for a user story is found to be grossly inadequate can be extremely difficult. All these are tough questions and are difficult to tackle without a really good team with a really strong leader. It's not for the faint of heart. Test Automation and Continuous Integration can help to mitigate a few of the difficulties but I don't think it's enough. The next best thing to do is the factor in the time spent on refactoring, bug fixes, research and other "sundry" activities when the development capacity for a milestone or sprint is computed. This will also help in computing the velocity of the team which, in turn, helps more reliable and consistent predictions of the amount of work that can be taken on by a team in a sprint/milestone
On the development side of things, implementing Agile will necessitate certain prerequisites. For instance, it would need a team that is filled with generalized specialists. People who can do a lot of things well and also one or more specific things really well. It also needs teams with a certain amount of stability in terms of change. In other words, teams with members that stay together for long periods of time.
So, in a practical world, the above requirements are usually tough to ensure. Therefore, a hybrid approach to Agile adoption is needed. One area that Agile can cause a lot of misunderstanding is in the emphasis of working software over documentation. People misinterpret this to mean that Agile frowns upon documentation. However, I would like to look at it differently. I feel that Agile's recommendation is that greater priority should be given to developing or creating the software rather than documenting the requirements, the design and other such artifacts. In their opinion, the time is better spent developing the actual software that satisfies the requirements.
However, against this, we must take a realistic look at the way teams are organized and function over time. In most cases, teams get built and break up as members join and leave the organization or move up or down in their career. Teams also change in the amount of expertise they possess in a specific area, domain or technology. So, a truly Agile team is difficult to build and sustain over any great length of time. Also, as teams change in their composition and experience, it is important to continue the momentum of software development. This is made easier if the new team members have access to some form of documentation that would help them ramp up and start being productive sooner. So, documentation in some form is essential to build productive, scalable and sustainable Agile teams.
