{"id":663,"date":"2018-06-04T21:33:58","date_gmt":"2018-06-04T19:33:58","guid":{"rendered":"http:\/\/agilerasmus.com\/wordpress\/?p=663"},"modified":"2018-06-04T21:33:58","modified_gmt":"2018-06-04T19:33:58","slug":"design-your-organisation-for-agility","status":"publish","type":"post","link":"https:\/\/agilerasmus.com\/wordpress\/design-your-organisation-for-agility\/","title":{"rendered":"Design your organisation for agility"},"content":{"rendered":"

Working agile and designing teams that can transform customer needs and demands into awesome features swiftly is a difficult task. In many cases Scrum and agile training is brought in to an existing organisation in an attempt to solve the puzzle. This is the first step into building an agile organisation but the transformation should not end there.<\/p>\n

Next step could easily be a redesign of your organisation to increase agility. Before doing so, let’s review some awesome examples from the real world:<\/p>\n

    \n
  1. Spotify<\/a>. We all know about the engineering culture<\/a> that Henrik Kniberg promoted few years back. He helped the organisation to work in squads (team), tribes (department), guilds (network) and chapters (center of excellence). But some of the key elements that most misread is that the teams work\u00a0autonomously on a single product that can be deployed in separate releases. They have the mandate to decide what to build, how to build it, and how to work together while building it. To acknowledge that certain parts of the application requires different skills they have divided into three segments: feature, client app and infrastructure.
    \nGoing back to the organisational design of Spotify: Employees are organised in chapters by their competencies and work in a squad. This means that all web developers belong to the same chapter and refers to the same chapter lead, but their daily work is conducted in their squad together with the rest of the members.<\/li>\n
  2. Amazon.<\/a>\u00a0In recent years Jeff Bezos and his thoughts have grown in popularity in the agile community. One of his “rants” target the organisational design with the “two-pizza teams”<\/a>.\u00a0 One of the elements of the “two-pizza teams” is, naturally, the size of a team (6-10 persons), however another point is about building autonomy and accountability. Each team has a single success metric called “fitness function” which could be profit\/loss on the product they produce. The team is empowered to take actions to maximize the outcome of the “fitness function” by any means necessary. This heavily relies on a divisional structure<\/a> in the organisation. Each product is a company within the company. Their primary goal is to bring results to the table.
    \nIn addition to the “two-pizza teams”, Jeff Bezos also issued a     mandate<\/a> in early 2000’s. This briefly describes that all development teams must deliver software as service that interact with other services. One of the effects of this mandate was that teams were responsible for the full stack of their services: they own the source code, they own the data, they own the databases and they only depend on well documented interface from other teams and their services.<\/li>\n
  3. Lunar Way<\/a>. Very few have yet to hear about Lunar Way. They are a small Danish fin-tech startup that strives to make everyday banking easier. Even though they are a young company, they have made some mistakes in the beginning which they are trying to solve<\/a>. One of the issues is organisational design. Over a short period of time they found that silos were sneaking into their organisation and decided to act on it: they took great inspiration from the Spotify engineering culture and organized into squads – migration, topup, credit, kpi, push notifications, rules and UX. Each squad being cross-funcational consisting of backend developers, app developers, business developers and marketing people.<\/li>\n<\/ol>\n

    \"\"<\/a><\/p>\n

    You might read the above references and think that they don’t apply to your specific organisation. You are wrong. No matter how big or small your organisation is it is crucial that you change the design into divisional structure aligned with the products that you have on display. If not, any effort towards being agile will be sub-optimisation.<\/p>\n

    My thoughts on organisational design are:<\/p>\n