Getting Started
Learn about the importance of adopting the Agile process for projects and understand the scaling issue.
We'll cover the following
Why agile
Big stone is hard to throw.
– German proverb
Suppose we have to develop an application that supports traders in the front office of a financial institution. The traders must be able to buy and sell products and calculate the risk of each transaction. One major difficulty with this is that the products available for trading are constantly changing.
If we focus on the current product market of options, we will see that almost every other day, a new product (option) is available to trade, which is traded differently than the others and whose underlying risk must also be treated differently than the others. Therefore, if we ask our clients for their system requirements today, we will probably get a different answer than if we were to ask them tomorrow.
Furthermore, they will inform us they cannot trade these new options without the application. With each day that passes without the application, the company loses several hundred thousand dollars. As if that isn’t bad enough, they point out that the competition can already trade these options. They assure us that any support our application can provide for these products would help reduce the loss because they can perform some of the steps manually. So, they do not insist on having full trading support for the new products, although that would be a plus.
A similar situation can occur in the telecommunications sector or any domain focusing on e-business. The big difference between these more modern and traditional applications is that the modern ones must be available in the market quickly. Otherwise, the application might already be obsolete when it’s first used, or the company might go out of business.
Note: Sometimes it is more important to serve the customer’s basic needs quickly than to fulfill all the requirements later, which might end up being too late.
Heavyweight processes of the 80s and 90s have difficulties dealing with these new requirements. They have instead occasionally been successful in domains with stable requirements. In these domains, everything can be formalized, and a detailed plan can be set up at the very beginning. Furthermore, every project can “blindly” follow this plan without worrying about updating or modifying it.
Some examples are defense projects or projects from the airline or nuclear power plant industries. In addition to stable requirements, these projects often seem to have limitless cost and time budgets. Because of this, it is more important to fulfill all the requirements than to deliver a subset of them on time and within budget. However, this objective is also changing in these domains. For instance, in the defense sector, processes that support changing requirements are becoming increasingly important.
Note: Agile processes promise to react flexibly to these continuously changing requirements. That is why agile processes are a panacea for successful software development.
Is agile development in large possible?
Agile processes are almost always recommended just for small projects and small teams, which might be bad news for those large teams that have to deal with speedy changes in requirements. However, the good news is that this course deals with agile processes in large projects.
Questioning scaling agile processes
Software engineers tend to question agile software development in the large, not only because most agile processes claim to work mainly for small teams, but also because most projects that fail are large. Most (large) projects fail because of a lack of communication among teammates, between a team and its manager, between a team and the customer, and so on.
Communication is one of the focal points of agile processes. But can effective communication ever be established successfully for large teams? The popular opinion is that it can’t; this leads to the idea that if we have a hundred people on a development team, we should get rid of at least 80 and keep the top 20 or (preferably) fewer. The chances for project success will rise significantly.
However, generally we can’t avoid large projects. Sometimes we will face constraints that force us to run a large project with a large team. For instance, there are projects with such a large scope that it is impossible to realize them with a small team in the defined timeframe.
If we want to take advantage of agile processes, several questions arise: can agile processes scale? That is, can they be amplified to support large projects? Moreover, are they able to support large projects? And what kind of problems occur when an enterprise decides to use an agile process for a large, perhaps even mission-critical, project? This course tries to answer these and many other questions about agile software development. But, before we go into more detail, let’s first clarify what is meant by large projects.