Posts

One day to get started with Kanban

Kanban’s importance for workflow management keeps on growing! So, it’s no surprise that we are seeing more and more companies adopting this method. I’d like to share with you an example of an activity you can use, based on experience, to introduce and initiate a Kanban transition within a team… With just one day of workshops! 

 

Icebreaker 

First of all, with this type of day, I like using an icebreaker / energizer to get the ball rolling. 

One I particularly like for teams discovering Kanban is the first name game. In addition to getting people active and moving, it begins to introduce the challenges of multitasking and the benefits of limiting work-in-progress (WIP). 

 

Presentation of Lean, the origin of Kanban and its objectives 

I then give a brief presentation of Kanban’s history and origins, including Lean principles, before addressing the main objectives of Kanban, which are laid out in the visual below. 

Kanban1

 

At this point, we take a moment with the team for it to define the objectives it is looking to achieve by deploying Kanban. We make sure that these objectives are SMART (specific, measurable, achievable, realistic (or relevant), and time-bound). These objectives make the setting up of Kanban meaningful and, a few months down the road, will enable us to assess benefits and define improvements to be made. 

 

Discovering Kanban’s principles and practices through a simulation 

Rather than giving a theoretical presentation of Kanban principles, I prefer to explore them with a simulation game. One I often use for these presentation and setting up days is the Kanban Pizza Game.  

In the space of just two hours, it makes it possible to discover and experiment with several Kanban practices, such as workflow visualization, WIP limits, continuous improvement, use of feedback loops and more. 

You can read an explanation of the game in French or English. 

 

A review of Kanban principles 

Kanban principles

In this step, I go over Kanban principles with the team I’m assisting. It’s a chance for me to explain that we will not be revolutionizing their way of working today: current roles, responsibilities and processes will be maintained. However, it will be their responsibility to make Kanban their own, in order to improve the way they work. 

 

Review of the various Kanban practices and a setting-up proposal for the team 

 

Once they have discovered the practices through this game, we look at them one by one, in order to see how they can be transposed into their specific field. Following a presentation of each one, I help the team think about how it could be applied in their environment. 

Kanban 3

  1. Visualize the flow

I begin by asking the team who they work for (who are their customers or users) and what service they are providing. It is important to understand the customers behind requests. The team can then identify how requests enter the system. Ideally, these people should be involved in the process of setting up Kanban. 

I then ask them to explain the flows linked to the various types of requests they handle. In Kanban, we do our best to produce a global vision of the value flow. Step by step, we build the flow on the board, right up to value delivery. Once this is done, we look at the columns that could be meaningful in their Kanban board.  

Here, the aim is not to define a flow that will match 100% of the team’s requests, but the majority of requests. 

 

 2. Explicitly state the management rules

Once the columns in the Kanban board have been defined, I ask the team to explain who is working in each column, and what the conditions for moving on to the next column are. I continue to take notes on the board. 

 

3. Limit work-in-progress

I then ask the team to define several limits in its board, without forcing it to set ones that are too demanding. The idea here is to get started with Kanban. The team can refine its limits later as its experiment with the method. I take this opportunity to talk again about the ideas of ‘pull flow’ and ‘push flow’. I then suggest that the team adds two sub-columns, ‘In Progress’ and ‘Complete’, in each of its columns. Lastly, we cover the topic of emergencies, and the team defines how to address them initially. 

If the team has trouble understanding the benefit of using limits, even after the Kanban Pizza Game, other games can help build a better understanding, such as the Aeroplane Game. 

 

 4. Manage the flow

For flow management, we talk about the possibility of setting up a daily meeting. I present good practices for a daily Kanban meeting and ask the team if it would like to use one in its environment. If so, team members together define the time of this synchronization meeting. 

 

5.Implement feedback loops

At this point, we together look at what the team would like to apply feedback loops to. 

  • To its product: would it like to organize demonstrations of functionalities deployed? If yes, who for? And how often? 
  • To its work planning: how often and how would it like to manage the supply and prioritization of requests? It is possible to define frequencies that are fixed (e.g. we resupply once every two weeks) or linked to events (e.g. we resupply when there are less than X requests left in our backlog). Supply and prioritization techniques will be covered in greater detail at a later stage, with the person(s) in charge. 
  • To its performance: here, I present the various metrics frequently used in Kanban and their utility. Generally, at first, if the team uses a physical and not a digital board, I suggest that it notes the Kanban system entry and exit dates, and that it counts the number of tickets in each column on a daily basis. I explain to the team that time and a certain volume of data will be required for these data to be usable. I therefore ask it to simply note down this information and suggest planning a quick meeting a few weeks down the line, in order to look at how it can use the data. 

 6. Improve collaboratively and move forward experimentally

Here, I talk about retrospectives. While in the other sections of setting up a Kanban, I try to assist them without pushing them to make decisions, in this section, I do insist that they plan an initial retrospective. I also advise them to define a frequency for the first few retrospectives. This is because, for teams starting out with Kanban or Agile, they do not naturally feel the need or get into the habit of conducting retrospectives. So I take the liberty of pushing them a bit! 

 

We can also cover other practices that are often used in Kanban:  

  • Classes of service: here, we go over the various types of requests the team handles in order to see if it wants to turn them into classes of service; 
  • Corridors: I then present the ways in which corridors can be used and the team decides together if it finds this meaningful. 

At the end of the day, the team has an idea of what Kanban is and the benefits it can bring, and it has already started work on its first Kanban. Generally, by the end of the day, the whole team gets to work on creating the Kanban board based on what it has decided during the day! It is important to underline that this is just a beginning, that this is the team’s Kanban, and that it is up to the team to own it and develop it, in order to draw maximum benefit from it. 

Assistance from the coach does not end here of course: we ask the teams what they expect from the coach. Furthermore, we suggest holding regular progress meetings together, and offer to provide support for the first daily meetings and retrospectives, the prioritization and planning of work and deliveries, use of metrics, and so on. 

Two important points need to be kept in mind for this day:  

  • The coach must enable the team to design its own Kanban. If the team doesn’t own it, there is a strong chance that it won’t produce continuous improvement. The coach will therefore be there to facilitate, assist, and possibly advise and raise any points they identify that require caution. 
  • If the team isn’t familiar with agility or continuous improvement, it seems important to me that the coach works with the team for a period to build this state of mind. The same applies when it comes to questioning practices and possible improvements. Without assistance, it is likely that the team’s Kanban will not evolve, and that it will find itself a few months later facing exactly the same problems it faced before! 

 

The images in this article are taken from Kanban sheets that we created and distribute at the end of our Kanban training courses and introductions.  

They are available to download here. 

An Agile Health Check to support continuous improvement

As coaches, my colleagues and I wanted to offer the teams we support a tool they can use to not only challenge their own agile practices, but also identify their own areas for improvement. After some thought and collaboration, we successfully created a set of “Agile Health Check” cards. Don’t worry, we’ll explain!

 

Why an Agile Health Check?

Many of the teams we support use agile frameworks (including rituals, artefacts and roles) without necessarily having understood or acquired the agile mindset. So we wanted to offer them a way to take a step back from these frameworks and a look at a range of agile principles, as well as the benefits they can get out of them.

By creating these cards, we wanted to:

  • Get back to the basic values of agility and the benefits we are looking to get out of them
  • Getting teams to take a step back to look at their agile practices
  • Enabling teams to examine their own behavior and identify their own areas for improvement

What we didn’t want:

  • The cards becoming a way of assessing or even comparing teams. We deliberately chose not to have a rating system and instead opted for a smiley-based team satisfaction scale. But we are aware that the use of these cards will depend on the willingness of the people who will use them…

Agile health check

  • Asking the teams only about agile frameworks. These can be misused as toolboxes to do the same thing as before in a different form (new roles, new rituals, but without necessarily adopting self-organization, collaboration, accepting change, etc.). So we wanted to free ourselves of frameworks to address mindset.

 

How are the cards structured?

Inspired by Heart Of Agile that gets back to the basics of agility, our 12 cards are structured into 4 themes:

  • Collaboration
  • Delivery
  • Inspection and improvement
  • Team morale

The front of each card has a general question on an agile principle, and the back features questions to further examine this theme. We propose 4 levels of team satisfaction assessment (no rating). This means the team can self-assess each issue included on the cards then discuss the assessment, particularly identifying areas for improvement.

Here’s an example:

Agile health check 1

You can download the cards in French and English.

Obviously, these cards will inevitably change over time, based on your feedback and our experience.

 

[SUCCESS STORY] PIERRE FABRE: Renewed clinical trial recruitment journey

Pierre Fabre is rethinking the recruitment and management of its skin research center panel. In order to ensure the good management of this activity of Pierre Fabre, SQLI has imagined and developed a new recruitment and management tool for this panel.

Going live at the end of 2019, the platform facilitates the volunteers’ journey and the Skin Research Center team accompanies each of these people with more fluidity.

Download the Pierre Fabre success story

Agile at scale? Never without the business lines.

The dual necessity to speed up delivery of value to customers and do so with equal, or even fewer resources has encouraged many companies to initiate digital transformation programmes. The consequences of the current health crisis have only amplified the importance of optimising both time-to-market and production costs. Agility, and Agile@Scale in particular, are often rightly chosen as a means to enable this vital transformation. However, the full range of benefits promised by agility at scale can only be attained by effectively bringing business teams on board right from the outset, with a partnership-based approach, to ensure that everybody is moving in the same direction.  

Full involvement of business lines is a must 

To successfully deploy agility at scale, business teams must be brought on board. They are a precious resource to define requirements and adjust deliverables, thereby achieving the desired value while avoiding costly latencies. This is no easy thing to do, however. In many cases, they remain distant internal clients.  

Very often, agility at scale is first targeted by IT departments as a means to meet their transformation challenges. In the case of companies where business teams tend to see the IT department as an internal service provider, rather than as a value-creation partner, it can be difficult to ask them to adopt this approach, which not only requires them to change their working habits, but also to be engaged throughout the process.  

If business teams are not convinced by the benefits that this change will bring them, they will naturally maintain the status quo and will leave IT teams with no better solution than to nominate representatives from within their own ranks to champion business needs. However, these representatives generally do not have any real decision-making power, nor the perspective needed to effectively prioritise. This is bound to lead to additional back-and-forths with the business teams and will introduce inflexibility and latency, which are a hindrance to the structural efficiency of an agility-at-scale approach that draws heavily on Lean thinking in order to do away with such wastage and optimise value creation. Such companies will therefore lose right from the get-go some of the benefits sought by this approach.  

This was the case with the transformation of a programme at a major luxury goods company, where the programme management team did not think it was possible to directly involve business teams in agile-at-scale sessions (planning, solution review, etc.) Business needs had to be represented by the programme’s product team (mainly product owners), whose members had no authority to make decisions and thus had to organise additional consultations and parallel sessions, which reduced the speed of action, immediacy of feedback and overall efficiency. 

Identify ambassadors  

In order to convince all business teams to come fully on board, adopt an ambassador approach. Identify the business teams who are the most curious and willing to get involved.  

Next, invite these early adopters to take part in an agile scoping session. This type of collaborative workshop, lasting several days, brings together business representatives and development teams, allowing them to experience the interactive efficiency of agility, while structuring their needs in a way well suited to rapid implementation within the agile-at-scale programme. Encouraged by this first positive experience, they will be inclined to remain engaged and will be able to promote the benefits and positive effects to their colleagues. Word of mouth is still powerful and this storytelling approach will enable you to gradually convince the other business teams.  

At a major French bank, where transformation was being driven by the IT department, this approach made it possible to bring on board the credit risk business line, which, after taking part in an agile scoping workshop alongside IT team members, was won over by the efficiency of the approach, asked to apply it to other initiatives and touted its benefits to colleagues. 

The need for executive management to be involved  

This key approach of using ambassadors to encourage the initial involvement of business teams needs to be accompanied by endorsement from executive managers, in order to keep the level of involvement up over time.  

Executive managers in business and IT departments are generally accountable for their ability to meet the company’s strategic challenges, while demonstrating a high level of financial efficiency. To bring them on board, you need to set out an argument combining business KPIs (the production cost of an initiative, how well the solution meets the requirements, and the solution’s quality and maintainability) and change management (number of people assisted, level of agile maturity), and clearly present the difference in results between a conventional and an agile approach. Here again, agile scoping can prove to be an initial unifying force: a comparative quantitative analysis between conventional and agile scoping will clearly bring out the advantages of the latter, whether it is in terms of cost, lead time or satisfaction. Next, the same type of analysis extended to the agile-atscale programme will win them over completely. 

Once convinced, each business line’s executive management team will be more inclined to take the necessary measures to ensure continuous availability of their operational staff to fully take part in the agile-at-scale programme, and, like the ambassadors within their teamsthey will become your spokespeople and endorsers among their executive counterparts in other business lines, so that everybody moves in the same direction at the same time.

Remote training: feedback from agile coaches

Due to the lockdown, the possibility of organising remote training courses rapidly emerged at SQLI. At first, I was not very keen on the prospect and neither were my agile coach colleagues.  We thought that not being together in a classroom would affect the quality of our training. After two months and more than 25 agile training courses conducted via video-conferences, find out how our adventure in remote training went! 

 

Does remote training work?

Yes! Interaction, discussions, exercises and games are key elements for trainees to understand and learn. With a video-conference, it is possible to have both trainer-trainee and trainee-trainee interaction, and to carry out valuable exercises. 

The feedback from trainees has been very positive. Like us, some of them were reluctant to take part in remote training courses, but they were pleasantly surprised! According to their feedback, some of them even found remote training more effective than classroom training: 

“Even though we were in lockdown, it was possible to do exercises remotely with lots of teams thanks to Teams and Mural. Half-day sessions like this are ideal.”

“Great training, managed by 2 great trainers during lockdown.”

“Well structured and very instructive. This remote experience was most interesting.”

“Very lively training session!”

Based on their questions and the discussions we had with them, we were able to confirm that they had grasped the various concepts covered during training. 

 

Seven adjustments made for effective remote training

Adapting course length and format

While, with classroom training, we had two consecutive days of training to promote immersion, we changed the format to half-day sessions. We did this to reduce screen time and, therefore, avoid visual fatigue, long periods seated and concentration difficulties.  

We basically tried out two formats:  

  • Four half-days on four consecutive days; 
  • One half-day / one full day / one half-day, on three consecutive days. 

Trainees’ opinions of these two formats were mixed. Some of them liked the full day, which made it possible to focus on the training and not be distracted by their day-to-day work. Others preferred the half-days, which enabled them to maintain a good level of attention. Many of them told us that two full days in a row would have been too much to handle.    

For our SAFe training courses, which are always difficult to complete in two days, it was an opportunity to add a half-day to the training. We of course included a good 15-20 minute break in each of the half-day sessions, to give everyone a chance to take a break from the screen and move around a bit. 

 

Adapting course content

Our agile training courses are generally made up of 50% theory and 50% practice (including exercises and games). While some of the exercises were not possible remotely, we decided that reducing the amount of practice was out of the question! It is an essential element for the trainees to fully understand and take on board the concepts covered.  

We therefore reviewed our courses one by one, in order to adapt the exercises: some were adaptable and could be conducted via a digital collaborative tool, while others were not and had to be replaced. Thanks to the Microsoft Teams video-conferencing tool, we could also divide the group of trainees into sub-groups, in order to carry out exercises in small groups and encourage all to participate. 

 

Reducing the number of trainees

In classroom training, the number of trainees is limited to 12. After several tests, we decided to limit most of our remote training courses to eight trainees, in order to enable everybody to interact and get involved. 

Turning on the webcam 

In order to encourage interaction and participation in our training courses, we asked trainees to turn on their webcams. This presents several advantages:  

  • It breaks down distance, both between the trainees and between the trainer and trainees; 
  • It enables the trainer to pick up on the trainees’ non-verbal language, comprehension problems, dips in attention, and so on. 

 

Retour d'experience 1

Video-conference via Microsoft Teams

 

Using collaborative tools

We experimented with iObeya and Mural for the various games and exercises. Both are relatively easy for trainees to get to grips with. These tools are essential to enable participants to do exercises together. Setting them up and preparing the tables for the first course takes some time, but the advantage is it can all be reused for subsequent courses!

At the beginning of the course, we take a few minutes to explain how to use the tool to trainees and allow them to experiment with it.

Retour d'experience 2

Collaborative workshop using Mural

 

More refresher exercises

We made the most of the half-day sessions to introduce exercises at the beginning of each day to refresh participants’ memories of topics that we had covered the previous day.

 

We used several formats:

  • The standard refresher exercise, where all participants recall what they learnt the previous day, while the trainer assists and takes notes along the way;
  • Little games, such as 40 Seconds and Agile Taboo, which are fun, stimulating and enlightening. The feedback on these games from trainees has been so positive that we will be keeping them for our classroom training courses.

 

Testing and working in pairs

Before the first remote training course, or before beginning a new remote exercise, we carry out dry runs among ourselves. This enables us to check everything is working properly and, very often, adapt the exercises for a better experience! Furthermore, each training course is initially led by two trainers in order to ensure it runs smoothly. It is easier to deal with unexpected problems as a pair: while one person is leading the session, the other can manage any problems that crop up and tweak things as needed. After conducting the course once as a pair, we assess whether subsequent sessions can be led by a single trainer or should continue to be run as a pair.

 

Planning ahead to avoid connection problems

Losing 15 to 30 minutes due to a connection problem is an all too common headache. To try to make sure it doesn’t happen, here are a few precautionary measures:

  • Test the link to the various tools, with a person from the client company, before the training course begins;
  • Ask trainees to log in 15 minutes before the session in order to ensure that their connection works;
  • We give our telephone numbers to trainees so they can contact us in the event of a connection issue.

As it turned out, our remote training sessions actually began far more punctually than our classroom sessions! 🙂

 

So, is it better than classroom training?

No, we wouldn’t go that far! While we are pleased to say that the remote courses work very well, certain aspects cannot be replaced, or are difficult to emulate, remotely. For example, for trainees who are somewhat reticent, withdrawn or lack confidence in the subject, it is more difficult to reach out to them and get them involved. However, by doing exercises in small groups, it is still possible to encourage participation, in the practical part at least.

Elsewhere, in classroom training sessions, discussions can continue during breaks and at lunchtime. With remote training, everybody uses the break to leave the screen and video-conference, so the discussion is ended. As trainers, we do connect before the training begins, and offer to continue after the end of the session, for those who wish to continue to talk, but this does not replace the immersion that classroom training allows.

 

Will we continue the remote training courses once the health risks are over?

We think that most of our courses will switch back to classroom training. However, we see an opportunity for companies and ourselves to provide quality training for people located in other cities or countries, while avoiding long journeys for a couple of days of training. In these cases, continuing with remote training offers real added value.

 

[EBOOK] Become your company's "Agile Hero"

It hasn’t escaped your notice: today’s consumers expect a brand or a company to be able to constantly adapt and evolve its offer according to the needs of its customers.

If you are reading this, no doubt you are already convinced that Agility is essential to any company that wants to make the most of its resources and stand out from the competition.

However, making an organisation Agile is far from easy! It requires questioning long-established processes, fostering change within your company (or, at least, in your teams), and changing mentalities.

Rest assured: with the right methodology, solid support, and a heavy dose of enthusiasm, you yourself can become your company’s Agile Hero!

This ebook aims to help you ask yourself the right questions to develop an agile strategy, accompany your teams in this process and even become an outstanding workshop organizer!

download agile hero guide

Watch out for an agile hangover!

Agility has become THE watchword for most businesses looking to upgrade their organisation to a more horizontal and collaborative model. As a result, agility has taken a central role in project management. It appeals to young engineers and project managers, attracted by the promises this method gives a glimpse of. But it’s still sometimes misused, often for the wrong reasons and/or under the wrong conditions. All too often, clients confuse agility and iteration, at the risk of seeing their project take a wrong turn or grind to a halt along the way. 

Businesses faced with Canada Dry agility syndrome

Agility is the word on everyone’s lips. We hear things like “our organisation has to be more agile”, and “we have to adopt a more agile approach” every day… BUT, at the risk of disappointing many a project manager, a lot of businesses today aren’t agile. Some might call it “Canada Dry agility” syndrome. It’s got the same colour, taste and shape as agility, but it’s not what it seems. With agility as the end goal, processes are often rushed, and definitions poorly established, causing misunderstandings and confusion from day 1 of the project. The situation runs the risk of quickly deteriorating, driven by the growing frustration of staff drowning in poorly-organised or poorly-led workshops, information irrelevant to their business line, or a much too broad scope of action. The teams don’t understand each other anymore, whereas the aim of agility is to create a common frame of reference for use in project management. Cash continues to be poured in as the teams work on poorly-coordinated, and consequently time-consuming, tasks.
 

Agility or iteration: you have to choose one… and stick to it! 

Every project must start with an essential and crucial stage: asking the client what methodology they want to use. Even though a project combining iteration and agility might still be able to see the light of day by making specific changes, any difference between the methodology used by the client in-house and the methods deployed by the service provider to manage the project will jeopardise the whole affair. If you didn’t manage to or didn’t know how to have this conversation upfront and are now faced with this situation, there are several stages ahead of you to slice through this Gordian knot, starting with the most radical: 

  • Becoming aware of it. If neither the organisation nor the service provider are mature enough to do so, an agile coaching consultant is a good option when given even the slightest sign of going off track. If they arrive at the start of the project, they can put the right processes and methods in place to avoid this situation. If the project has already begun, they can help to raise awareness. 
  • Stopping the project. A necessary and natural step after awareness, stopping the project saves the teams involved time and can prevent a longer-term economic disaster. 
  • Make a decision and stick to it. Once the project is on stand-by, you need to work fast to reorient it and redefine the management principles. For this stage, you should consider your client as a partner, drawing up a new roadmap together and making it as relevant as possible. 

Agility and iteration: different criteria!

Agility must meet a genuine business need. If a business identifies a genuine client-side agility need but the client isn’t organised or mature enough to execute an Agile methodology, checking the prerequisites must form an integral part of the start-up phase, even if that means delaying the launch. These prerequisites include: 

  • The involvement of a genuine client-side Product Owner with real decision-making authority and knowledge of their organisation and the related business lines. 
  • An Agile-qualified Scrum Master and project manager with experience of successfully setting up at least one project. If this condition cannot be met, an Agile coach must be appointed. 
  • A contract covering the agile specifics (organisational and financial). 
  • A clear, informative and unambiguous kick-off meeting attended by all the participants and decision-makers. 
  • Support including, if necessary, a separately-defined consulting budget. 

This does not in any case mean that the iterative methodology is dead, and it would be a mistake to try to switch a full fixed-charge project to the Agile methodology. In this scenario, a clearly-defined iterative model would undoubtedly deliver better results. The Agile methodology must meet a genuine business need. For example, a big-budget client sent us a simple set of specifications, boiled down to one basic idea: “I want to sell my products at the end of the year”. In this scenario, it’s highly likely that the implementation of an agile methodology (meeting the prerequisites) could meet both the project and client needs. Measurement and setup of prerequisites on both sides is essential. If these two worlds clash during a project, it can prove explosive and cause significant financial and interpersonal damage. The teams need to speak the same agile language to move forward. 

Empathy – a successful methodology for digital projects

Using a mixture of methodologies is the key to success for any digital project, together with a strong capacity for adaptation. Whether you work for a large, medium-sized or small organisation, you will most likely manage your digital projects by following the latest trends. Today it’s all about Agility (@Scale or ‘light’). But it’s important not to forget the basics. 

Life before the Agile age

Before the era of Agility, organisational structures existed within companies offering real added value. Therefore, it would be a shame to destroy this added value today by trying to implement a whole lot of new methodologies just because they are fashionable. 

 

The Agile Era 

Organisations and digital factories (teams that use digital technology for a new industrial model), often try to adopt a methodology such as Agility, or the Waterfall model, as they believe it is the key to their project’s success and essential to their company’s digital transformation. However, it is crucial to remember the following: 

  • There’s not just one methodology for handling a digital project 
  • Trends are trends… Waterfall/Agility@Scale/etc…. Pragmatism is the only judge 

The path to success involves taking a look at your internal IT organisation. Find its added value and structure your own project methodology around this. This means you will be able to engage the rest of your enterprise and ensure they adopt your chosen methodology. 

Everything is Digital today as it was yesterday

It is therefore important to explain that a digital project is sometimes just a reinterpretation of what people already know (their current skills). For example, if we look back over the past decade at the newspaper industry, the first digital transformation projects often failed or partially succeeded because of the haste with which they were implemented and the belief that these digital projects should be treated with new methodologies (the Digital Paradise). The often-monolithic approach of IT service providers did not help either. By thinking too much in technological and methodological terms, the IT service providers often forgot the heart of the subject – the importance of the content (the articles) and the layout (the very specific format for highlighting this information) which represented the real added value of the press. As a result, many consumers felt lost when reading their “new” newspaper, because they could no longer find the editorial quality and layout they were expecting. Consequently, many digital press projects had to be completely redone. 

 

What was right before Digital is still right today

One of the major European banking players recently decided to manage all of its digital projects in Agile @ Scale mode. Although this strategic option had been taken by them years ago, they forgot that what had worked in the past, within in their organisation, was still valuable today. The added value that had been created by their “old” IT team in terms of organisation, communication, project methodologies and more … was partially destroyed by their determination to implement the Agility @ Scale processes. Here, innovation had clearly been destructive and not disruptive. 

Empathy is the key

There is no single dedicated methodology for digital projects, as these assignments are just like any other projects; they need a smart methodology mix to fit with the organisation in question and a strong human capacity from the project team (Project Directors, Customer Management team and top Management), to understand what real added value pre-existed within the organisation and how to protect and maximise this. 

Therefore, understanding organisations, their people and how everything and everyone work together is crucial when it comes to choosing the methodologies that will work for your digital project.  This is nothing new; it’s all about empathy. 

The agile digital agency: transformation in practice

“The Art of Doing Twice the Work in Half the Time” – is what Jeff Sutherland, one of the leading authorities on Scrum, promises in his book of the same name. What a promise for agencies, which are used to continually working at the limit! This is why pioneers in the agency sector have already been focusing on Scrum and Kanban for a few years and, in the meantime, agile transformation has become a fact of everyday life within agencies. 

In the first part of our series we explained why traditional project management has reached its limits within many digital agencies. But what exactly changes with the introduction of agile methods? Do sprints, daily meetings in front of a shared whiteboard and a lot of brightly coloured notes really make an agency agile? 

 

The 12 basic principles of agile working 

Irrespective of which agile project management method is chosen, agility is always based on similar values and principles. The Agile Manifesto can serve as a guide and standard: Even though this operational framework for agile teams was originally defined for software developers, the 12 principles can be easily applied in other activities (in the following, we have replaced some terminology from the software sector with more general terms). 

1.Our highest priority is to satisfy the customer through early and continuous delivery of valuable products & services. 

2.Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage. 

3.Deliver functioning products & services frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale. 

4.Business people from various sectors must work together daily throughout the project. 

5.Build projects around motivated individuals. Give them the environment and the support they need, and trust them to get the job done. 

6.The most efficient and effective method of conveying information to and within a team is face-to-face conversation. 

7.Functioning services/products are the primary measure of progress. 

8.Agile processes promote sustainable development. The sponsors, the team and users should be able to maintain a constant pace indefinitely. 

9.Continuous attention to technical excellence and good design enhances agility. 

10.Simplicity – the art of maximising the amount of work not done – is essential. 

11.The best workflows, requirements and ideas emerge from self-organising teams. 

12.At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behaviour accordingly. 

 

The 12 principles are based on 4 agile values    

1.Individuals and interactions over processes and tools 

2.Working software over comprehensive documentation 

3.Customer collaboration over contract negotiation 

4.Responding to change over following a plan 


Scrum, Kanban & Co: Agile project management has many facets 

The keyword “agile” automatically leads many people to think of Scrum. However, agencies do not need to use Scrum to work in an agile way. Scrum is a process model, which defines specific roles, rules and procedures. Agility is a code of conduct and a corporate culture, which is completely independent of Scrum. Or, in other words: Scrum does not work without agility. But agility works well without Scrum.

Many agile digital agencies use Scrum for project management, but others prefer Kanban or adopt selected innovation tools, such as Design Thinking or Design Sprints, for creative processes. Stable, self-organising teams, which communicate harmoniously, independently identify problems and find appropriate solutions, lie at the heart of agile agencies. 

Which project management methods and which agile tools are used is secondary and differs from agency to agency. Generally speaking, the majority of agility pioneers offer the following advice – don’t become absorbed in sets of rules, but rather start courageously and adapt processes to your own agency if necessary. 

 

True agility is more than just a method  

Just because the Project Manager suddenly becomes a Scrum Master or Product Owner and the largest deliverable is packaged in short sprints, this does not mean that all the problems and weaknesses of traditional project management are resolved overnight. 

There needs to be a change in thinking within the company and by each individual employee. If there is not an agile mindset, agile processes will fail. The “switch” to self-organisation and individual responsibility, for example, is not equally easy for all employees. Even for management, relinquishing responsibility and losing control is often a difficult process. 

Seeing failures as learning opportunities and dealing transparently with weaknesses is also a typical barrier to agile transformation. There are other pitfalls to agile tenders and pricing models, above all when there is an “agility gap” between the client and the agency. From experience, formulating (and signing) tenders, which are not based on fixed specifications but on estimates, is initially difficult for both sides. 

We know from our own experience that agile transformation of a digital agency is a process that requires expertise and, therefore, time. Even we have not yet quite achieved our aim, but improvements are already clearly discernible.

In the next blog article, we will share various details of our vision of agility and the agile transformation of Osudio with you. 

Article written by Slawa Baryshev, Agile Coach and Solution Architect 

The agile digital agency: fit for the future

The agile digital agency 

A number of major projects running in parallel, three forthcoming pitches and, shortly before the Go Live of a new website, the client is still requesting changes: an entirely normal day for a digital agency. To adhere to deadlines and budgets and keep clients happy despite all this, efficient project management is an absolute must. The challenge: in the wake of digitisation, conventional agency project management frequently reaches its limits. Caught between the increasingly rapid progress of technology, constantly changing customer expectations and global competitive pressure, digital agencies are really feeling the full force of this development. 

 

Agency project management is changing

No matter how meticulously project managers plan, brief, organise and control – the more complex the project, the greater the probability of requirements changing during its course. This may be because market players are turning value chains upside down, technical innovations are making brand new features possible or user feedback from initial tests differs from what was expected. 

Traditional “Waterfall” project management with its fixed project plan, rigid processes and milestones is not flexible enough to respond to this VUCA (volatility, uncertainty, complexity, and ambiguity) environment. Specifications, laborious consultation rounds, lengthy validation phases and skills silos in specialist teams do not work well with versatile start-ups, disruptive business models and the dynamism of modern channels, platforms and touchpoints. 

Allowing new insights or unexpected problems to be incorporated into a complex project plan is complicated and delays all subsequent phases. In the worst cases, not only are budgets exceeded and time to market extended, but also products emerge that the market no longer needs in their current form. 

It’s no surprise that many digital projects fail. Stubbornly slaving away on adopted project plans makes little sense when the project goal changes repeatedly along the way. The consequences are unfulfilled client expectations – and frustrated personnel, who have given everything to achieve the predefined milestones. 

 

Why agile?

Wouldn’t it be better not to spend so long on preliminary planning (which, from experience, is out of date in a few weeks anyway), but instead to quickly get started by flexibly aligning the project sequence with market conditions and customer expectations? Many agencies are already successfully testing this agile approach.

Agile project management, with methods such as Scrum, Kanban and Design Thinking, focus on small, manageable sub-steps, maximum transparency and intensive dialogue within teams and with the client. On the basis of a jointly defined vision, teams are given the space to find the best solution for the task at hand – while, at the same time, bearing responsibility for a timely deliverable, functioning interim result. 

At regular short intervals, the client receives an insight into the team’s progress and is able to flexibly shape the priorities for the next sub-steps by means of feedback. 

The major advantages: mistakes, blind alleys and changes of direction do not result in blockages, but guide the project onto the right path, in small steps. This involves: 

  • A fast start to projects 
  • A high degree of flexibility 
  • Maximum transparency 
  • Efficient workflows 
  • A positive error culture 
  • Optimised knowledge transfer 
  • Short time to market 
  • User-oriented results 

Positive side-effects: From experience, agile teams are more motivated and happier, which is why many agile agencies are also one step ahead in the “War for Talent”. Ambitious Generation Z employees expect modern working models with flat hierarchies, recognition and individual responsibility – precisely the conditions required for agile project management. 

In the next blog post in this series we present agile models for digital agencies and demonstrate why the use of agile project management methods alone does not necessarily result in an agile transformation.   

If you would like to know more about this topic, please allow us to advise you 

Portfolio Items