Do you remember those 12 Agile principles written a loooong time ago? Well, the whole Agile thing is kind of based on them.

1. Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
2. Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.
3. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
4. Business people and developers must work together daily throughout the project.
5. Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
6. The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
7. Working software is the primary measure of progress.
8. Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
9. Continuous attention to technical excellence and good design enhances agility.
10. Simplicity–the art of maximizing the amount of work not done–is essential.
11. The best architectures, requirements, and designs emerge from self-organizing teams.
12. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

Of course, after such a long time these could be outdated. Since we love continuous improvement, the same could be applied to principles too right!? Well, a funny aspect of really good principles, is that they do not change easily.

I don’t have a good reason to suggest any change. Although there are few words here and there that could be different (e.g. overemphasis of projects instead of just product development), the reason to suggest Agile principles 2.0 would be too weak.

Nevertheless, a lot is written about how Agile Manifesto is outdated, something that was hot in 2001, but world has changed in last 10+ years. Therefore some improvements are suggested.

So, this is all great. Good discussions. But, what really bugs me are the compromises.

There is usually an implicit assumption that above principles do not scale when tried to be implemented in a large project / organisation. What I mean with “scale” is multiple teams working together to deliver a product within a large (complex) organization.

A friend of mine participated a SAFe training where trainer tried to teach him that many of the Agile principles cannot be scaled. The reasoning behind such teaching is that since they don’t scale, complex organisations need a complex framework such as SAFe. In other words, SAFe explicitly brakes with many of the above principles in order to accommodate the needs of existing organisational complexity.

Just to provide one example among many. About principle 12, this is a quote from SAFe website:

As Agile practices matured and became adopted by larger teams and teams of teams, however, there comes a point at which emergent design is an insufficient response to the complexity of large-scale system development. Simply, it is not possible for teams to <summarized: deal with architecture>

Since the above principles are the best reference we currently have what Agile development means, we should ask ourselves if SAFe can be called Agile.

How do principles work in a scaled context?

Since answering this question could lead to a whole book, and not a blog post, I will provide only clues and references. A very short answer is Large-Scale Scrum (LeSS) which deals directly with organisational change required to make above principles a reality. Nexus framework has a similar approach, although it deals with organisational change implicitly through explanation how teams work together.

So, the 12 principles definitely scale, therefore stating otherwise is at best an opinion. One I disagree with.

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.

These strongly relate to frequent feedback loops directly between customer and teams that deliver software. Also, early and continuous delivery translates into making sure that lead time is weeks or shorter, and not 3+ months. Therefore, having translators between teams and customer, gatekeepers, approvals, management layers, silos / functional departments (Architecture, BA, Dev, QA, Operations, etc.) is not an effective organisational form. This requires restructuring into cross-functional teams that are capable of delivering features autonomously in order to achieve continuous delivery and capability of any team member to talk to customer directly, and inspect and adapt. In other words, it requires organizational descaling, reduced complexity where self-managing, cross-functional, long-lived team is the basic building block.

Business people and developers must work together daily throughout the project.

A large organisation that applies this principle will distinguish between decision making on priority and who talks to who, since a major worry in a corporate world is a mess if the collaboration between many teams and business is not “controlled”. The applied framework and/or practices should encourage people to work as closely as possible, while prioritization (what shall teams deliver and spend money on?) is centralised in form of a product owner, which has to come from business.

Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.

This principle requires Theory Y way of thinking, where management changes behaviour, where people who collaborate and deliver value are placed at the center. The processes, roles, and responsibilities become secondary. This implies reduction of roles and complex so-called supportive structures such as PMO, program and project management. Different way of dealing with portfolios and budgeting (e.g. Beyond Budgeting), work is assigned to stable long-lived teams and not resources assigned temporarily to a project or program.

The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.

Obviously! Nevertheless, large organizations have often resourcing model (available people are assigned to a project), and not teams model. This produces so called teams that are dispersed, sometimes over multiple continents. Face-to-face conversations over internet is at best very cumbersome, especially with timezone differences. A large organisation needs to switch from this resourcing model to stable long-lived colocated teams model. Also major projects are assigned to already existing teams, and not anymore other way around (resources found and assigned to this large project).

Working software is the primary measure of progress.

This principle is probably one of the most compromised of all. “What does ‘working’ even mean anyway?”. Well, it means going “all the way”. Working means it works in the hands of a user and / or produces actual value for the customer. A product that is so called “finished” by a team, but still needs to go through e.g. final testing or integration with some other product is not “working”. If we compromise with this, then basically any piece of software can be called working.

Therefore, development teams that deliver their stuff (e.g. a component or not completely tested product) is secondary to a really working product. In order to embrace and implement this, a large organisation requires system thinking. Seeing the whole, the end result is the primary focus. Continuously improved Definition of Done is a powerful tool in this process.

Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.

This one implies:

• Long-lived teams instead of resource pools
• Development stops only when product is no longer valuable.
• Overall quality and operations are integral part of Agile development. It is otherwise not sustainable.

Continuous attention to technical excellence and good design enhances agility.

For large organisations this means a craftsmanship culture. One where career path includes continuously growing technical expertise. Where highly skilled developers are respected, valued, and paid accordingly. A culture where these teams with these highly educated people decide how much time is required to do things properly. Also a culture where to perform also means to learn a lot, learn what good design means, since software development is essentially a knowledge creation process.

Simplicity–the art of maximizing the amount of work not done–is essential.

This principle encompasses much more than what we often assume. It is  challenging to achieve this in large organisations. At the same time, reducing complexity in organization, requirements, development process and architecture results in one of the biggest waste reductions typically encountered. This requires lean and system thinking tools, lean startup practices. Also, feature teams (instead of component teams) that are at least much more capable of looking at combination of components in order for simplification to start to happen. A team that deals with a single component might see the problem, but it is not empowered to resolve it.

The best architectures, requirements, and designs emerge from self-organizing teams.

There is a tremendous amount of articles and blog posts related to tension and compromise between these two worlds. At the same time, there are also large companies that do embrace this principle and in the process have discovered nice practices. Many of them are explained on LeSS site, and none of them requires someone outside to define and deal with architecture:

• Initial, overall, and per team Product Backlog refinement
• Design workshops with whole team (not only tech leads or architects)
• Multi-team design workshops for broader design issues
• Architects and engineers are regular team members and write code
• Tiger team
• Design / architecture community
• Component mentors
• Product vision workshops (with everyone)
• 1-hour decision making
• Architectural concern wall
• Spike
• etc.

At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

In case of multiple teams, representatives of teams have an Overall Retrospective together with ScrumMasters and managers. They discuss cross-team and system-wide aspects.

Conclusion

While many tell me that something is not possible, I prefer making things happen especially if they seem impossible. In this case, it is not even a question if it is possible or not. It happens already!