The principles behind the Agile Manifesto documents well the initial promise the agile proponents were giving.
- Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
- Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage.
- Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
- Business people and developers must work together daily throughout the project.
- Build projects around motivated individuals.
- Give them the environment and support they need, and trust them to get the job done.
- The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
- Working software is the primary measure of progress.
- Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
- Continuous attention to technical excellence and good design enhances agility.
- Simplicity--the art of maximizing the amount of work not done--is essential.
- The best architectures, requirements, and designs emerge from self-organizing teams.
- At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.
As can be seen in these principles the agile approach is focused in building a co-located team and in seeing the benefits though the eyes of the team. Much of the project management tasks can be reduced to minimum due the co-location, and remaining tasks can be integrated seamlessly to the development work. Agreeing the tasks, reviewing the results, setting and striving for the task goals, solving the rising issues and other such tasks become a part of the teamwork. Similarly, external parties become an integral part or contributors of the team.
It is more difficult to achieve similar benefits in larger organizations (Kettunen, 2009) where the number of people leads to the existence of many teams and the distance between people grow bigger, even global in many occasions. Inevitably the external parties will become more distanced as well. So the agile benefits for larger organizations cannot be expected to be the same or on the same level as for small organizations. Yet the expectations are that an agile organization is responsive to the customer needs, even when the customer has difficulties in deciding on his/her own needs and changes his/her opinion frequently. In large organizations this kind of changes often have the "whip effect", similar to that in a supply chain (Lee, Padmanabhan & Whang, 1997). It creates variance and bottlenecks throughout the development and the delivery process. Keeping focus in tasks that are delivering value to the customer in the customer satisfying manner and removing the rest becomes a major challenge.
The promise of better quality is to be deemed as well (Abbas, 2009). Thought the quality in a team level means improving in a team level that does not build linearly up to better quality in larger organizations. On the contrary, the local quality optimization may lead to deterioration of overall quality due to different understanding of the optimum and conflicting implementations of the quality related practices. Having a large number of people allows the development of larger software, but requires also growing attention to the non-functional characteristics, like reliability, usability, maintainability, and other "ilities". The traditional means for the quality control, like a separate quality organization or quality gates in the process can easily lead to additional effort that may not add value to the customer.
Parallel to obtaining the customer value and the quality benefits there are business stakeholders, like owners, partners, and top management of the organization to be satisfied as well (Power, 2010). In a larger organization their distance grows to customers and also to satisfying the customer needs. Each group defines and focuses on their own interests. It becomes a challenge to achieve the customer-supplier win-win in practice. The effectiveness of an organization from its stakeholder point of view compromises the pure customer value creating interests. Particularly for the product development organizations where the product manager is "a proxy customer" distance to the customer grows bigger than what is stated in the initial agile principles.
The third interest group to satisfy is the developers and the development organization in general (Cockburn & Highsmith, 2001; Melnik & Mauer, 2006). In a large organization they easily drift away from the customers but from the business stakeholders alike. It becomes challenging to foster the customer and business knowledge, the technical and development competence, and the large-scale teamwork in a partial isolation. Consequently the demand for customer co-operation, productive self-organizing teams, growth of essential competences, and the like agile promises are not fulfilled. Yet these are the essential characteristics of an agile software development organization.\
In short, the expectations have grown that the agile approach can be transformed from a team level methodology to the working and management practice of a larger organization and still retain the agile benefits. So the model of a small, co-located self-organizing team, consisting of skilled and apt people, working closely together with a customer fulfilling customer changing needs can be mapped to large organization that provides (Highsmith, 2007; Schwaber, 2007):
- Increased customer satisfaction
- Reduced time-to-market (better "time-to-benefit")
- Increased quality
- Improved project portfolio and product management (project types, features)
- Improved product development investment management (control and flexibility)
- Reduced "waste" (increased efficiency, productivity, development cost)
- Better predictability (visibility)
- Better risk management (risk reduction)
- Better workforce morale (developer satisfaction, well-being)
The two main strategies for expansion are inside-out and outside-in. The inside-out strategy means not just expanding from the team level to the management structure but also adjusting to and with the surrounding practices, that is, expanding the agile and agile compliant principles to cover more areas of the software development life cycle as well as to the managing of the software development organization. The outside-in strategy means amalgamating the agile development with the traditional software development and the organization management sustaining both as much as possible.
