Article

The importance of processes

– in the journey towards organisational agility
Published

26 April 2021

In a series of articles, we aim at casting light on Implement’s approach to agile transformations. One of the five elements that we will explore is “processes”. In an agile context, we often derive our processes from the methodologies within the topic as these methodologies intend to describe an optimal flow for teams and for the wider organisational context.

At the core of Agile, we find the methodologies describing the way in which teams and organisations collaborate. When an organisation is on its journey towards achieving organisational agility, a critical element is the agile process which the organisation chooses to adapt.

In this article, we will present our view on what agile practices are, and how you can start working to find the best fit to your organisational context.


The article is split into three parts:

  1. The first part will focus on the agile process landscape.
  2. The second part will provide a suggestion as to how you can identify the agile processes (i.e. methodology) that are best suited for your organisation.
  3. The third and final part will focus on the importance of continuously adapting your agile processes.

In today’s turbulent world, more and more companies are looking to stay relevant by delivering better and faster solutions than competitors. An often applied approach to achieving these benefits is to implement agile practices. These should, if implemented appropriately, enable organisations to develop at a faster pace both internally and, equally importantly, also towards customers (externally) which in turn will lead to improved time to market and higher quality solutions.

As an organisation embarks on the journey of creating an agile organisation, it will encounter several agile methodologies to get inspiration from, and each of them will bring unique and useful elements. But it may be a jungle to identify the solutions that are best fit for your organisational context – and in most cases, a hybrid solution will likely be the best starting point for any organisation.

Often, however, organisations are faced with the challenge of focusing too strongly on a standard framework and trying hard to implement this into their organisation. Yet we have worked with several organisations on developing organisational agility, and to us it is evident that a single framework can rarely be applied successfully in any organisational context (i.e. there is no “one-size-fits-all” in the world of Agile). This poses yet another challenge as it is hard to identify the methodology that suits your organisational context best (and this is especially true in contexts outside IT).

So, organisations should indeed try to explore how they can identify and adopt agile practices that are best fit for their organisation instead of trying to squeeze all the elements of a given agile methodology into their organisation.

Articles in the series0 3

1. Agile processes


It may sound a bit odd. Processes. It is something usually coined with “Lean”. Yet the business processes and related activities are a core element in all agile methodologies. The processes are the elements that describe how organisations best share information, prioritise activities and coordinate vertically (from leadership to team) and horizontally (across the team and other teams).

At the heart of agile organisations, the agile team lives (sometimes referred to as a squad, Scrum team etc.). It is in these teams that the value-adding activities are being executed on a daily basis, and it is as such from here that the organisation makes its raison d’être come live. Therefore, it is at team level that most processes start, and so it is also a place where you can start your agile journey.


Agile processes at team level


In most organisations, the agile processes at team level are inspired by classic Scrum.

Scrum is a methodology that was introduced in the 1990s in the software development industry. Thus, today, a lot of the Scrum practices are applied in agile teams in various contexts.

The process steps and activities in a sprint

Scrum is formed by three core elements: roles, ceremonies and artifacts.

The “role” section describes three distinct roles present in the team:

  • The squad member who brings a unique skill set to the team.
  • The product owner who acts as “the voice of the customer” and facilitates prioritisation of activities in the team.
  • The Scrum master who ensures effective and focused facilitation of all Scrum ceremonies.

The “ceremonies” describe specific meeting structures (incl. frequency and fixed agendas). These meetings should all occur in a sprint (which is a repetitive cycle of a defined period of time, e.g. two weeks. The cycle repeats itself after each sprint).

The ceremonies occur in the following order:

  • Refinement, which is the organisation, prioritisation and preparation of activities to be executed in the forthcoming sprint (occurs before a sprint begins).
  • Sprint planning, which is the first session in the sprint where the team agrees on activities in priorities.
  • Daily stand-up, which occurs daily throughout the sprint to ensure that the team is aligned and coordinated in terms of activities and to identify challenges.
  • Review, which occurs at the end of the sprint to assess what has been delivered in the past sprint. Everyone presents their completed work.
  • Retrospective, which is the last meeting in the sprint. The main focus is on assessing the collaboration within the team, and specific improvement areas are identified and assigned to ensure continuous improvement at team level.

The agile “artifacts” are the elements that the team is working around or with. It is a sufficiently detailed description of activities that need to be carried out and a visualisation of progress and priorities.

The agile artifacts include (high-level):

  • The product backlog, which is a long to-do list of all the activities that the Scrum team needs to complete. The product backlog should always be prioritised so that the activities mapped at the top are the ones that are the most important and most valuable to execute.
  • The sprint backlog, which is a smaller to-do list consisting of all the activities that a team has committed to delivering in the sprint. The sprint backlog is developed at the beginning of the sprint during planning.
  • The product increment is the specific customer deliverable that has been achieved by the team at the end of the sprint (it is defined at the beginning of the sprint during the planning session).

We believe that any team can benefit from introducing elements of Scrum to their day-to-day work, as the setup will nurture closer collaboration, focus on incremental deliverables and continuous improvement. However, to achieve full organisational agility, your organisation must scale the processes across the organisation – both horizontally and vertically.



Agile processes at scale


To scale your agile practices, you can choose from numerous scaling methods. The nature of these methodologies and designs will vary greatly depending on your organisational context. Yet, there are specifically three core elements that are relevant for all organisations regardless of the scaling model.

Agile processes at scale – a fixed heartbeat across the organisation

Fixed and shared heartbeat(s). You should unify the rhythm in events across the entire organisation to enable the ability to change direction and shift priorities faster.

An organisational heartbeat may often start with an annual planning session where strategic priorities are outlined for the year. This is followed by quarterly planning sessions where the initiatives are broken down into elements in a broader organisational context which is then followed by functional area/departmental planning sessions (also quarterly). Within these functions, monthly planning will take place to track and (re)prioritise efforts towards the goals set in the quarterly planning sessions. In each monthly cycle, the teams will have their respective planning sessions where they prioritise and organise activities on, for example, a biweekly basis.

Common language and transparency. You should apply a uniform approach to the naming of sessions and roles to the extent possible.

Having a common language will enable a stronger sense of belonging across the organisation whilst also making it easier to communicate and collaborate, as roles, titles, platforms, meeting forms and prioritisation activities are standardised and shared. Furthermore, it will also lead to a higher level of transparency, as initiatives are prioritised and reviewed in shared cycles, giving the teams an opportunity to observe progression and learn from other teams.

Built-in learning loops. As outlined under “Fixed and shared heartbeat”, the strategic priorities are developed in annual, quarterly (and sometimes monthly) planning sessions before trickling down to team level. Yet, it is of paramount importance that you implement a feedback loop that flows the other way (upwards if you like).

By creating a feedback loop, you ensure that the initiatives being launched will incorporate the organisation’s learnings identified at team level (e.g. direct customer feedback, team observations, market movements etc.). This will enable the organisation to learn faster, make more informed decisions and eventually evolve at a faster pace.

Regardless of the scaling model and related processes that you implement, you should revisit the three elements and ensure that your design can be checked off against each of them.



2. Identifying the right processes


So how do you start the journey towards identifying the agile processes that are most suitable for your organisation?

You should apply the following three steps to start identifying what processes are best fitted to your organisation before launching it in a wider organisational context.


1. Design workshop(s) (early)


The first step would be to involve relevant parties in your organisation in a number of design sessions together with agile experts. The sessions should be facilitated by the people with agile expertise as to support the advancement towards an MVP setup that can be launched in a pilot. The sessions will start with a focus on current processes, limitations/challenges and areas of opportunities as well as introductions to the agile practices. The final sessions will settle on a preliminary design (MVP) that is ready to be tested with one (or more) pilot team(s).



2. Pilot team


The pilot team will be a frontrunner in the organisational transformation, as they will be testing the initial design. The pilot team will support you in identifying critical flaws in the design and allow you to adjust core elements before scaling to a broader scale. It is possible to launch a new organisational structure without testing it in pilots (only possible in smaller organisational contexts). However, in this case, you must expect a higher degree of resistance and an increased requirement for ongoing adjustments within the teams. This will have to be communicated clearly to the organisation.


3. Adjust and scale


When you have gathered enough learnings from the pilots, you should adjust your operating model accordingly. The next step will then be to scale the model to the rest of the organisation. Whilst you will have a more tested and durable process design ready, you can still expect adjustments to the model as you start scaling. This will occur more often in the beginning of the change journey but should be an active and ongoing element in the continuous change journey. We suggest identifying these challenges in large-scale retrospectives to map the elements that are the most challenging and describe initiatives and/or adjustments that can address these challenges.



3. Continuous improvement


The Greek philosopher Heraclitus (c. 535 - c. 475 BC) is quoted for having said: “Change is the only constant in life”. If this was true more than 2,000 years ago, it certainly also is today. Therefore, we cannot expect our organisations to remain in a specific state indefinitely. Rather, you need to create an organisation that is able to learn, adapt and evolve on a continuous basis.

Initially, this has to happen on a mindset level, where individuals within the organisation should develop a mindset that enables them to constantly identify and assess impediments and derive potential solutions (or experiments) to address the problem. You need to have a continuous focus on this across your organisation, as it is a prerequisite for creating a constantly evolving organisation.

However, it also plays out in the process landscape you will design. This design needs to encourage learnings and testing for improving, e.g. coaching of individuals, retrospectives in teams and large-scale retrospectives to tackle larger and more systemic challenges.



Where to get started


The implementation of agile processes starts with you becoming more aware of your own organisation’s challenges and the nature of activities whilst also developing a stronger understanding of agile practices.

Once you have developed a stronger understanding of the two, you should set up a pilot (or even just start conducting small experiments within your team). The pilot will, as previously mentioned, give you valuable learnings as to what will work and what will not work in the wider organisation.

Getting started on your agile journey, a key element is to get management support (an element which over time should probably not be necessary in a truly agile organisation). In the early stages of the change journey, having leadership support for experimentation/trying new things is a critical element.

Hopefully, this article has inspired you on how to get started with your own journey towards implementing agile processes (as a key element in developing organisational agility). And as basketball coach John Wooden once said: “Failure is not fatal, but failure to change might be.” This applies to many aspects in life but especially to organisations that have a desire to remain relevant and stay at the forefront of the industry.

Related0 4