06. Juni 2016

The End of All Projects, or: Taking Agile to the Next Level

Taking Agile to the Next Level

Imagine a world without projects, project leaders and product owners. Imagine a broader product definition, a larger backlog and multiple feature teams all working on the same effort. In this article, ti&m's CTO Martin Fabini explores an organizational design based on LeSS, the framework for scaling agile software development to multiple teams.

Let me share some ideas to reduce dependencies and management overhead in software development as it gets addressed by the Large Scale Scrum (LeSS) framework. LeSS promises scaled agility in software product development – not through a prescribed remedy, but by refocusing on Agile principles to put the “teeth of Agile” back into software development. This may sound boring and obsolete, but as I can confirm, the more Agile goes mainstream, the more the principles of Agile get diluted.

I want to shift your attention to the organizational design of a scaled Agile environment, as it is discussed within the LeSS framework. The key points are:

  • Respect and do not dilute Agile principles.
  • Get rid of projects; their contractual nature is poison for Agile.
  • Use a much broader product definition, within which up to 100 people may work self-contained.
  • Use feature teams – each team should be able to work on the whole product, which is shipped as a whole. There should be no team branches.
  • Get rid of project leaders, project boards and synchronization managers.
  • Use bi-weekly releases, which allows you to get rid of bug branches or a maintenance team.

Sounds too good to be true? Let’s take a closer look at some typical implementations of Agile. Here is an example of an organization with three Scrum teams working on three projects:

Huh – looks complicated but familiar? The basic pattern of the organizational design is the “copy-pasting” of Scrum teams wrapped into a project structure. One Scrum team was successful, thus you start another one, and so on. In short, you start duplicating a lot of unnecessary things, which is a direct result of Scrum not addressing the scaling issues. The typical flow to change a piece of software might be the following:

  1. Projects start off by reaching an agreement on a budget and the scope.
  2. A project defines the organizational home base – usually the software component to change and a team.
  3. The implementation team generally is a Scrum team, which has often managed to collaborate with its PO and business analysts quite closely.
  4. The PO and the Scrum team manager are expected to deliver software in bi-weekly increments onto the test platform, where stakeholders approve the work. Dependencies (e.g. interfaces) must be carefully managed and the deployment of a dependency must be synchronized.
  5. After a couple of months, the increment is put into production.

Let’s look at the same organization after implementing feature teams and DevOps according to the LeSS framework: 

The key of this approach is to use a broader product definition and apply Scrum with several teams on a new and large product backlog, which is backed by new/broader product definitions. What is different if we scale by the product definition and thus create a much larger backlog for several teams?

  1. The scope of a project is much wider. Actually, projects do not exist anymore and thus, the need to track a budget for such disappears. Instead, you have teams of up to 100 people (with a burn-rate) assigned to different components. The allocation of the budget is determined by the priorities in the backlog and its share fluctuates freely between components.
  2. We talk about a wide product definition, which incorporates all components of picture one. We are using only ONE backlog and only ONE product owner instead of many product owners per project.
  3. The original Scrum teams depicted in picture one are attached to one component. In LeSS, the teams are mixed, which means that any team should be capable to work on any component. Thus, dependencies on other teams should disappear.
  4. Continuous delivery of the overall component is biweekly or even ad-hoc (feature driven). Inter-dependencies are dissolved within a team, because a team may work on all components and because of automated unit- and integration tests.
  5. The team (not the testers) is responsible for the productive instance and decides about the release quality of the current product development. Remember, all team members (up to 100) contribute to the same product. Testing is done within the team and not by a testing department.

Now, which benefits might you expect from such an organizational design? Firstly, there are no projects. It might be hard to imagine a world without projects, but give this thought a chance: Right at the moment when you get the green light for your project, your focus is on delivering what is in the contract of said project. This is your definition of success and you stick to it until the project is done. With a broader product definition, and thus a larger backlog where several teams are involved, you focus and prioritize on user stories and – if done right – on the VALUE of each story. It can be viewed as a flexible program management, implemented in a big backlog. If the value is justified, all the teams may also work on just one component at the same time, even just for a few weeks. As a consequence, the organization has more flexibility and the capability to deliver more value in a shorter amount of time. Projects with their “contract thinking” put the focus on just one aspect or component, which means that you are trapped optimizing software development locally.

Secondly, LeSS means a dramatically reduced management overhead. There are less product owners, no project leaders and operations are transformed to resemble a software team, which provides the right self-service tools for developers.

Thirdly, priorities drive the effort. The product backlog determines where the effort and the money goes. This may change quickly, which is also the cornerstone of Agile and a reason why projects hinder scaled agility.

And last but not least, since there is a regular release planned every two weeks, there is no need for developers to work on feature- or bug branches. It is very rare that bug fixes can’t wait two weeks for delivery.

Of course, many questions are still open. But if you made it to the last line, I have probably caught your interest. If you want to learn more about implementations of “LeSS”, contact me, come to one our free meetup sessions or look into a LeSS training in Zurich.

Martin Fabini
Martin Fabini

Martin Fabini ist seit mehr als 20 Jahren in der IT tätig. Bei ti&m führt er Kunden an neue Business Cases mit neuen Technologien heran.

Related Articles

Digital first! Jetzt wirklich?

Wie man Digitalisierungsinitiativen zum Erfolg führt, indem man den Menschen miteinbezieht. Der Energiedienstleister ewz überträgt Verantwortung in die Teams, um den sich verändernden Kundenbedürfnissen gerecht zu werden.

Mehr erfahren
Richtig digitalisiert? Dazu braucht es starke Produkte

Produkte // Was zeichnet zukunftsweisende Digitalisierungsprodukte aus? Die Antwort darauf findet sich in den drei Stichworten: Offenheit, Modularität und Innovationskraft. Nur wenn diese eng zusammenarbeiten, entstehen starke Produkte, die auch den Herausforderungen der sich beschleunigenden Digitalisierung und den Veränderungen am Markt gewachsen sind.

Mehr erfahren
Eine neue Möglichkeit der Art Direction bei responsiven Bildern
Eine neue Möglichkeit der Art Direction bei responsiven Bildern

Das Jahr 2015 markiert ein Meilenstein in der digitalen Medienlandschaft. Zum ersten Mal verwendeten mehr Leute das Internet über mobile Geräte als über Desktop-Browser. Die Webseitenbetreiber haben deshalb ihre Webseiten responsive gestaltet. Je nach Gerät und Bildschirmgrösse wird das Layout der Seite anders dargestellt, so dass der Inhalt immer optimal sichtbar ist.

Mehr erfahren
Single Sign-On als Authentisierungslösung für Microservice-Architekturen

Eine der wichtigsten Säulen der IT-Sicherheit jeder Applikation ist die zuverlässige Authentifizierung eines Benutzers und seine Autorisierung für einzelne Operationen. Während bei monolithischen Systemen oft eine einfache Loginseite und eine Session-ID in einem Cookie ausreicht, um dies sicher und benutzerfreundlich umzusetzen, ist dies in einer modernen Microservice-Architektur nicht ganz so einfach.

Mehr erfahren
Marc Bühler<br/>
«Ich will ti&m als Trusted Brand in Singapur etablieren»

Marc Bühler hat im Juni die Leitung der ti&m-Niederlassung in Singapur übernommen. Seit mehr als zehn Jahren lebt und arbeitet er in Singapur. Wie er in die IT kam, was er in seiner Freizeit tut und wie er seine Start-up-Erfahrung für die Niederlassung in Singapur einbringen will, erzählt er im Interview.

Mehr erfahren
Smartes Loginverfahren ohne lästiges Abtippen

Zusammen mit ti&m hat die Luzerner Kantonalbank AG (LUKB) eine neue Stufe in puncto Sicherheit erreicht. Gemeinsam brachten die beiden Unternehmen die aktuell wohl innovativste Authentisierungslösung der Schweiz an den Start. So bequem und sicher konnten sich E-Banking-Kunden noch nie einloggen! Doch: Wie funktioniert das genau?

Mehr erfahren