If you talk to any project team, you will find varying range of opinions regarding the best methodology for development – all very passionately putting their points of view across. Barring the occasional accident, most of these teams have given considerable thought to what is most applicable to them and have followed that course. When each of them argue in favor of a different methodology, it is well founded in facts. However, the one thing that is missed in all these discussions is that the challenges facing all the different teams are not the same. Let us consider various scenarios.
Follow this scenario … an organization realizes the need for a new system. They go through an internal requirements gathering process and invite tenders for the system, to be implemented by a certain date. You are a professional services organization. You are required to estimate the effort required to design and implement the system. In your response, you have to provide a price, as that would undoubtably be one of the selection criteria. You happen to win the tender. What is your status? You are now locked into a fixed deliverable to the client, to be completed by a date within a cost you have specified. Is there any room for agility? When you think about the triangle of constraints, effectively you can move none.
You can legitimately ask why not estimate to do the work following Agile principles, that would solve this dilemma. Let us then review how business is done in the real world. For all of us IT professionals that like to think we’re God’s gift to mankind :o), the reality is that we’re a support cast in most organizations, that only utilize IT as a means to achieving their business goals. In business, everything is driven by supply and demand. Think of it this way … if you bought something from a store, you may be able to take it back and get something else that is in a slightly different color, or size. However, if you ordered something custom to be made, and then changed your mind on the size, would you expect that to be accommodated? This is the difference between a product sale and custom work. Software development is no different.
When you are developing a product, or are in a development or support team within the organization, you have a steady commitment to resources. You have the ability to select your sprint schedule. Your costs are also therefore fixed. You have some leeway on scope. In such scenarios the organization has already accepted the cost of this continued effort and therefore scrutiny on the resources (and by extension cost) is not the same. The scrutiny is likely to be more along the lines of value for money … is the overhead we have agreed to getting us the improvements (or new functionalities if it is a product development) we’re after.
Custom development is an entirely different beast. Here uncertainty reigns. Most likely reason the organization is getting you to do the project is they do not have the resources or capability to do it themselves. At the same time many of the users will also not have the understanding of what is possible to achieve. In such scenarios you will end up spending significant effort in communicating possibilities and success criteria for your work to be accepted. Encouraging change of requirements, even at late stages like Agile methodologies will ensure you never come in on budget or are forever locked into a change control battle.
The second key when considering using Agile methodologies is the likely size of the project team. In essence the Agile teams are self organizing teams that work based on a given set of requirements and set their own schedule. The emphasis is on responding to change over following a plan. This works really well and reduces overheads. However, this is only true for a small team. When the team size goes to beyond six or seven, this becomes more and more difficult. Adding each new team member adds many new lines of communication necessary to keep this self-organization working efficiently. Bigger the team lesser the chance of success using Agile methodologies.
If you have been landed with an Agile project because no-one knows the requirements, think again. That is a guarantee for chaos. Agile is not a substitute for requirements gathering. In fact, Agile requires a continued emphasis on requirements through product backlogs and user stories. There is a constant requirement to refine user stories, even for items that do not make it to the current sprint. Many a time customers will not object to time spent writing code and testing it. They will object to this continuous refinement and management efforts. Before you jump in, consider if your client is inclined this way.
Does this mean that you cannot use Agile principles at all in some of these scenarios? No, that is not necessarily the case. You can use Agile principles in your teams, but will most likely struggle to run the entire project using Agile practices. You will need something overarching to ensure adequate control and communication. Agile is best suited for product development and in-house support teams.