ScALeD - Principles Over Frameworks And Processes

Submitted by Peter Beck on 02/06/2014

"Values and principles scale, but practices are context sensitive." - A statement by Ken Schwaber, one of the founders of Scrum. One also could say: Every organization is unique because its products and services are also unique. This also means that each organization has its own practices (= processes) to deliver these products and services. What can be compared between organizations are certain basic patterns that we like to call principles. Agile is defined by a collection of such principles, which have been immortalized here: Agile Manifesto. This remarkable manifesto was created in the context of software development, first of all to organize not too large working groups in a, for that time, revolutionary way and thus make them more powerful. The authors were so brilliant and didn't go into practices, because they knew that many roads lead to Rome, and it is an idea of Agile approach, not to set the way from the outset.

About a decade later, Agile has grown up - in the truest sense of the word - and has grown togehter with the idea of Lean production. The task now is to holistically implement these ideas in very large development organizations. We know innumerable success and failure stories of great organizations that use Agile and Lean as their development approach (e.g. Spotify by Henrik Kniberg ), but many still lack a clear picture of how this can look for their organization. Here the Agile Frameworks come into play. Instead of thinking ahead everything in detail, a minimum possible set of activities, roles and artifacts should ensure that certain principles are implemented. The principle of ' Inspection and Adaption' should ensure that the proper process is created and constantly further developed. Scrum is such a framework and it is amazing that the Scrum community has achieved it, not to inflate the framework with more rules over the years, but even to slim it down. According to the motto: everything that is not absolutely necessary, can be thrown away (corresponds to the Lean idea). Kanban is a framework, which again has too little activities in my oppinion. The Scaled Agile Framework (SAFE) in turn is in my eyes a too big pill for an organization to be able to swallow it at once. And 'Inspection and Adaption ' is too little present in both of them to my taste . But that's just my personal taste and I will not go into the discussion about the best framework, as it too often happens when the basic understanding of Agile and Lean is lacking.

Actually it depends on where and how a certain Framework is used, and that those who use it to steer the team or the organisation in a certain direction have well understood,“what“ they are doing and more importantly, „why“ they are doing it. So that they have a response to:

„What does Agile and Lean mean for us why do we, with our large company, want to be like that?“

In response to this question I, within a team of five experienced Agilists, have written down the principles of Agile and Lean development with regard to the scaling in large organizations (scaledprinciples.org). The result is a collection of 13 principles divided into 5 areas:

  • Enthusiastic Customers
  • Satisfied Productive Employees
  • Global Optimization
  • Supportive Leadership
  • Continuous Improvement

Please note, we do not claim here to have invented these principles. We've merely formulated them and we believe that many experienced Scrummers, Agilists, Lean and Kanban users think the same way. Are you also one of them? We appreciate if you support this statement.

Perhaps you will say: "This is all quite nice, but it's not enough. How will this look like in practice?" More thoughts, ideas and proposals for practices you can read here. And if you have suggustions yourself: Just do it - write down your stories and practices and link them to us.

Peter Beck

About the author

Peter Beck

Peter has set himself the task of creating companies that deliver value for their customers and employees. That was also the motivation behind his decision to found DasScrumTeam. Peter is a passionate Scrum Trainer (Certified Scrum Trainer, CST) and consultant with a solid background in engineering. Since 2007, he has trained and advised a wide range of development teams, specialist departments, project managers and those in leadership positions, helping them to apply the Scrum framework, agile planning methods and software engineering practices. Peter is a graduate engineer (Dipl.-Ing, TU) specialising in electrical engineering and information technology.

  • Experience with Scrum since 2004 as Team member, Scrum Master, Product Owner, Coach and Trainer.
  • Served as ScrumMaster in internationally distributed Scrum Teams
  • Co-founder and Product Owner at DasScrumTeam AG
  • Key interests: Agile companies and Scrum beyond Software