Our blog series on Agile Organisation – which was started mid-2017 – was kick-started due to a constantly rising demand for support in this field. For further details please have a look at the articles of the blog series (only available in German): „Agile Organisation: Vom Buzzword zur Realität (Teil I – III)“ or refer to the short summaries below.

So far, this series has been focusing on the so-called Prepare phase, as any Agile Transformation should be started small to be grown increment by increment in an iterative fashion. After briefly summarizing the blog series to date, we will outline some of the challenges facing an Agile Transformation once we move beyond the first phase into the so-called Apply phase.

The first blog article of this series established the core principles of an Agile Organisation so it can react faster to changes and adopt proactively according to the VUCA:

  • Team autonomy: Multidisciplinary, independent & self-governing teams
  • Product focus: „Customer centricity“ through end-to-end feature orientation
  • Governance: A lean innovation process as prerequisite for an agile answer to internal and external change triggers in combination with the “Agile Trust Handshake”, which consists of empowerment as a core promise to ensure that decisions are made at the optimal organizational level and transparency as the counterpart to empowerment to produce both vertical and horizontal transparency within the Agile Organization

In the second blog article, three steps for the evaluation of scaling agile frameworks are clarified, as these contribute significantly to the success of an Agile Transformation:

  1. Market overview as a starting point: Which Scaling agile frameworks can be identified based on the recent market developments and what are their general characteristics?
  2. Checking for individual client needs: Which bottom-up requirements exist towards the frameworks, which then are converted into evaluation criteria to reflect the client situation?
  3. Short-listing and selecting a Scaled agile framework: Which short-listed framework best fulfills the identified evaluation criteria, especially given the scaling level to be achieved?

The third blog article describes on the one hand the mission-critical dimensions:

  • People – Introduction of the „Agile Way of Working“: Consists mainly of a transparent collaboration between Business & IT
  • Process – Agilization of the Governance Model: Rethink existing structural levels, functional departments, areas and roles
  • Technology – Development of the „Agile Development Toolbox“: Focuses on people & process enabler to build an Agile Development Toolbox

On the other hand the four-phases-approach towards an Agile Transformation is detailed, as it was introduced above: phases to prepare, apply, expand and integrate.

After completion of the Prepare phase, including the associated agile maturity level of the organization and to conceptualize the agile target operating model together with (senior) management , the second phase follows: Depending on the organisation’s original degree of maturity, our customers are currently in the Apply or Expand phase and are establishing additional agile incubators which are based on existing teams or taking the next step and developing the „proof of concept of organizational agility“. In this phase, it is particularly important to uphold the motivation for change even after the first measurable successes and at the same time to establish continuous improvement processes. However, scalability challenges will not be avoided.

Based on our experience of having performed Agile Transformations in various industries, the following five focus areas have emerged, with their interfaces often being especially critical. In the following paragraphs, we will take a closer look at these focus areas and highlight typical challenges and potential solutions:

  • Program leadership
    Addressing impediments on program level, consistent benefits tracking and stakeholder management are a key insurance for a stable development environment. Supporting the achievement of these factors can be leveraged by best practices on Agile Leadership and a gapping of deviations regarding actions and behavior.
  • Product ownership
    For many individuals new to a product owner role, challenges arise from being inconsistent with regards to how they document decisions and how they communicate and negotiate with stakeholders. This can also lead to another issue with regards to quick decision-making in case of critical situations. Additionally, backlog refinement issues can lead to development teams not using their full capacity due to a lack of ready user stories.
  • Architecture
    The last issue outlined for the product owner also has significant relevance when it comes to building a bridge between stakeholder requirements and (the rest of) the feature teams. Hence, optimizing the Flow-to-Ready process steered by the business analysts in close interaction with solution architects increases in importance as team interactions and interdependencies become more complex due to the level of scaling.
  • Feature teams
    Since feature teams by definition are “self-organizing” entities, it is important that they have a north star of what they continuously strive to achieve as a team. If the feature team is lacking such a defined aspiration level and at the same time the expectations towards the team were never clearly articulated by program management, a dangerous vacuum is created. Often times, this becomes noticeable by feature teams becoming overly defensive about their level of productivity and quality, while program management continuously doubts that feature teams are doing their best. This deadlock can only be overcome by one of the core principles of Scrum: a brutal level of transparency which in its very nature removes assumptions and replaces them with clearly observable facts which in return create trust.
  • Support teams
    Especially at the beginning of an Agile Transformation, not all activities that are required to create a potentially shippable product increment can be moved into the feature teams, which is reflected by a less than perfect Definition of Done (DoD). For this reason, a few specialist teams will remain with their job being to support – hence their name – the support teams in getting things to “done”. Their work has to follow a pull principle based ultimately on the backlog prioritization by the product owner. To get this pull principle to run effectively and efficiently, is usually one of the great challenges, as also the Support teams normally only recently moved toward self-organization.

For more insights, we also recommend our recent publication „Agile Organization – from buzzword to reality: How to make it a success story„, which will become available on our website soon. Please also stay tuned, for further blog articles of this series to also address key insights of the latter two phases: Expand as well as the Integrate.