How agile are people in responding to change?

The starting point for this article is a large software development and implementation project of a new SAP software for more than a thousand users in a large international company.

In addition to the standard functionality already available in the system, a number of functionalities essential to the customer had to be completely redeveloped, and existing processes first analyzed and in some cases optimized.

Agile methods are on everyone's lips and are often postulated as the "savior" for all kinds of problems familiar from software development projects of earlier days. The relatively rigid and linear approach in the classic waterfall (project) methodology, in which the requirements analysis, the solution definition and the subsequent, often lengthy development and test phase were worked towards a fully defined end result at the beginning of the project, harbored numerous risks of not achieving the desired result in the end.

Too many unforeseen things could happen during the long project runtimes: Requirements could not be completely defined in every detail at the beginning, stakeholders changed during the project, technologies were already obsolete again at the end of the project, or the original requirements simply changed during a long development phase or suddenly became obsolete.

The iterative approach in agile project and development methods promises significantly more flexibility and security in being able to react to changes as they occur.

Short development cycles of typically one to two weeks make it possible to define and deliver manageable development packages with less complexity for the "sprints" and to be able to react flexibly to changing requirements in the subsequent, recurring sprint reviews with the clients.

One almost gets the impression that every agilely organized (development) project should automatically be a success. Unfortunately, this is not the case.

A successful completion of the development work does not define the project success of a large software development project by far. No matter how well and purposefully the software may have been completely redeveloped, adapted or appropriately extended to a functioning end result, the client's requirements may also have been fully met:

True project success is only achieved when the new software has been successfully rolled out in the company and is accepted and used by the broad mass of users.

The introduction of new software is usually accompanied by the introduction of new or modified processes. However, processes that are lived by people cannot be introduced or changed in an "agile" manner - because people are still subject to different speeds of change.

No project or development method, no matter how agile, can help. If the "human factor" is not recognized and taken seriously in time, even the most agile software project ends in the best case with great software that pleases the client and perhaps some stakeholders, but is not used at all or only inefficiently by the broad mass of users.

Experience shows that the risk of success increases with the size of the subsequent user group (or of the company), because often no representative group of the final end users was involved in the feedback rounds of the individual development cycles.

On the one hand, in the composition of the stakeholders, especially those for the sprint reviews, there is a tendency to select the employees who are already committed and have a greater affinity for change.

Furthermore, it is simply a problem of mass: With more than 1000 end users affected and possibly several processes affected, the probability is very high that the small core group from which feedback is actively collected in the sprint phase is simply not representative.

So what to do to best put a software development project with a large number of affected users on the path to success?
From our point of view, it is important to combine the advantages of modern, agile methods with those of classic methods from project management and organizational development: develop agile, roll out classic.

In the software implementation project on which this article is based, with more than a thousand affected users, the proven Sirius project approach was used, combining the advantages of the agile Scrum methodology with classic project management approaches and organizational change management.

Attempts are made as early as possible to establish multiple communication and interaction channels to as many (potentially all) end users as possible.

In our view, integrating only a few selected "key users" is not sufficient to achieve acceptance of the new software to be introduced and any upcoming process changes. Instead, significantly more must be invested in the areas of communication and change management, which are often omitted due to a lack of time, money and resources - right from the start of the project.

There can't be too much information and transparency about the upcoming changes - just too little!

Phases of the Sirius project methodology

In concrete terms, it has again proved worthwhile in the present project to pay particular attention to the following points in the individual project phases:

Scoping

• Take the time to define the project scope clearly and unambiguously! Formulate very precisely and concretely. Actually, this is a matter of course. But also explicitly write down what you do NOT have in the scope.
• Formulate the goals and NON-goals of the project - in addition to the project scope.
• Make sure you have aligned scope and objectives with all key stakeholders.
• Communicate scope and objectives at every opportunity. Introduce each workshop with a short slide in which you again clarify what is in the scope of the project and what is not.

Design phase

• Make sure that a representative selection of users is involved in the design phase: The key users involved in the core team of the project are usually not sufficient to have sufficiently considered all user groups in the design. Explicitly consider teams and users in other regions as well - they may work differently than the experts assigned to the project and thus have different requirements!
• It is better to hold a few more design workshops than not enough: The workshops are not only about working out the necessary requirements for the software - the workshops also serve as a means of communication to convey the project and its goals to the (key) users.Already in this phase, you can significantly increase acceptance if you involve as many users as possible or at least representatives of the various user groups.
• Actively and explicitly integrate very critical users: When putting together project teams and workshop participants, people often avoid those employees who are considered "difficult. It takes time and effort to also pick up the problem-oriented employees, but you will be confronted with their objections one way or another, at the latest during the rollout. At this early stage, however, you still have the chance to respond actively and to moderate objections.
• Think of the works council. Do not see this as an obstacle, but as an opportunity to gain further plus points for the acceptance of your project.

Development Sprints

Use the Sprint Reviews for what they are intended for: Validate the delivered (partial) development with the user's expectation of the delivered feature.

So don't keep the group of participants in the review sessions too small and don't just integrate the key users, but invite other users to the sessions. Document the review session.

In this project, each Sprint Review was conducted and recorded as an international web session. This gives stakeholders from other regions of the world the opportunity to view the review afterwards. This is much better than "just" sending a set of slides and minutes afterwards.

Test the delivered (partial) function directly in a review phase after the sprint review with a defined test group. In a Sprint Review meeting, no matter how long it is, you simply won't notice all the points.

Only when you "try out" the delivered software component with several users will you notice errors, design flaws and conceptual weaknesses.

Process & Integration Tests

Test a complete process run as early as possible. As soon as the sum of the delivered partial developments from the sprints allows a complete process test, test it as well - again with several users. What worked well in the individual sprint tests does not automatically work well in the complete process run.

Expand the group of testers for the final integration and UATs. Also have users test here who were not involved in the sprint tests. It has been shown time and again that the users who were involved in all sprint reviews no longer assess the software in its entirety in an unbiased manner towards the end.

Roll0ut

Use all available modern media in your training concept for the roll0out of the new software. In addition to the obligatory manual, create short versions for the essential functions that users need in their typical day-to-day work.

Produce short tutorial videos for the most important functionalities. These do not have to be elaborately produced - on the contrary, it promotes acceptance when "employees for employees" discuss these videos.

Use a central collection point for all information about your project - including training materials, FAQs, tutorials, web sessions, news etc. Communicate this, e.g. intranet page, over and over again throughout the project. Include the link to this page in any material published by your project.

For the training sessions, take into account the time zones of the employees in the other locations. People always like to forget that a web session at a time that is convenient for us in Germany becomes a night event for colleagues in Asia or the USA.

It significantly increases the acceptance of your project if you actively consider this circumstance and explicitly schedule trainings and info sessions also at convenient times for users living abroad.

Accompanying Communication, Marketing & Organizational Change Management: The activities in this block are neglected again and again, as they are only unnecessary ballast and cost drivers in the eyes of many. However, exactly the opposite is the case!

This is where it is decided whether the project will be successful in the end or not:

Inform the organization about the project and the goals associated with it. Repeat this regularly and report on progress. Use all the resources at your disposal for this, especially in large companies.

The more transparency, the easier it is for you during the rollout. In this specific case, in addition to regular newsletters, short info web sessions on the project were held monthly - for all potentially affected users.

Everyone was allowed to participate. The sessions were still recorded to really give all users the opportunity to see the sessions.

In addition, large "fact sheets" were hung up in the team rooms of the various locations, which concisely presented all the important information about the project on one page. Furthermore, the project team visited many teams in their team meetings and presented the project.

On the subject of communication can only be said: There is no such thing as too much! Talk about your project and the goals pursued with it as much and as often as possible - start this already with the start of the project.

Think about the change process that every employee must and will go through. Try to provide them with as much transparent information as possible.

Conclusion

Agile methods in development projects have made it much easier to achieve the desired end result in a targeted manner. However, completing the software by deadline X does not automatically make the project a success.

Only when the users accept the new software and ideally even perceive it as a support in their daily work can the entire project be considered a success - at least that is Sirius' understanding of the project.

As soon as it comes to people and their individual approach to change, agile methods are of limited help. When it comes to change, people are only "agile" to a limited extent.

Fortunately, classic project methods still offer sensible and correct concepts here - you just have to apply them seriously. With the right combination of the right methods for the right purpose, the next project will also be a success again.