- Big stone is hard to throw.
- —German proverb
Imagine you have to develop an application that will support traders in the front office of a financial institution. The traders have to be able to buy and sell products and calculate the risk of each transaction. One major difficulty is that the products available for trading are constantly changing. If you focus on the options market, you will see that almost every other day, a new product (option) is available for trade, traded differently than the others, and whose underlying risk must also be treated differently. Therefore, if you ask your client for the system requirements today, you will probably get a different answer than if you were to ask her tomorrow. Furthermore, she will let you know that without the application, she is unable to trade these new options. With each day that passes without her being able to use your application, her company loses several hundred thousand dollars. As if that weren’t bad enough, she also points out that the competition is already able to trade these options. She assures you that any kind of support your application can provide for these products would help to reduce the loss, because she can perform some of the steps manually. So she does not insist on having full trading support for the new products, although it would definitely be a plus.
A similar situation could occur in the telecommunications sector, or in any domain with a focus on e-business. The big difference between these more modern applications and more traditional applications is that the modern ones must be available in the market quickly. Otherwise, the application could already be obsolete by the time it is first used, or the company might be run out of business. Sometimes, it is more important to serve the customer’s basic needs quickly than to fulfill all her requirements later, which might end up being too late.
Heavyweight processes of the 1980’s and 1990’s 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 needing to worry about updating or modifying it. Examples of this are defense projects, or projects from the airline or nuclear power plant industries. As well as 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 in 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.
Agile processes promise to react flexibly to these continuously changing requirements. That is why agile processes are currently treated as a panacea for successful software development. However, agile processes are almost always recommended for small projects and small teams only—bad news for those large teams that have to deal with speedy requirements changes.
That is the reason this book deals with agile processes in large projects. But before we discuss this topic in detail, I would like to further define the focus and target audience of this book. First, it is necessary to explain the terms large, agile, and agile process and the context in which they are used.
Questioning Scaling Agile Processes
Software engineers tend to question the feasibility of agile software development in the large, not only because most agile processes claim to work mainly for small teams, but also because most of the projects that fail are large. The reason most (large) projects fail is a lack of communication: among teammates, between team and manager, between team and 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, leading to the idea that if you have a hundred people on a development team and get rid of all but the top twenty or (preferably) fewer, the chances for project success will rise significantly.
However, you can’t generally avoid large projects. Sometimes, you will face constraints that force you to run a large project with a large team. For instance, some projects have such a large scope that it is not possible to realize it with a small team in the defined time frame.
If you want to take advantage of agile processes, several questions arise: Are agile processes able to scale? That is, Can they be amplified in order to support large projects? And, 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 book tries to answer these and many questions relating to agile software development. But, before we go into more detail, I should better clarify what I mean by large projects.