Melanie Franklin, Director, Agile Change Management Limited, discusses the importance of considering business needs when transitioning into agile or DevOps.

OK, BusOps is not really a function (yet) but neither was DevOps only a couple of years ago. I use the term because I want us to give lots more attention to the integration of project deliverables into ‘business as usual’.

I work with a lot of organisations who are becoming more agile, often starting with IT and then moving agile into other types of projects.

Agile requires a very strong relationship between those creating the new products and services (project deliverables) and those that will use them on a day-to-day basis. In agile, the project deliverables are shaped from an initial high-level idea to a detailed, tested product or service through constant communication with the intended users. In my experience this causes two problems, only one of which is currently being addressed:

In my experience this causes two problems, only one of which is currently being addressed.

How to get and keep the users involved

This constant shaping of the project deliverables happens as they are created, so feedback often needs to be daily or at least weekly. Any longer between creation and user views risks the creators going off at a tangent driven by their understanding of the business but which would not have been the choice of the users.

The problem is balancing user involvement with the demands of their day job. Secondment is not an answer as it is the views of those embedded in the work that we need, and as soon as someone becomes seconded to the project team they lose their up to date operational understanding.

Ideally, we would ‘overstaff’ operations so everyone has the time to spend a portion of their week helping to shape the future. In practice, teams of user representatives are being created to work between the business and the project teams.

This provides a constant stream of views and feedback but still has the risk of being one stepped removed from what users are doing every day.

How to adopt project deliverables into the way business is done

The problem with agile is that these project deliverables keep coming, more frequently than buses! So users have only just finished learning the layout of a new screen when they are offered a new report, and as they try to integrate this offering into their process, a new interface changes how much their customers can do for themselves, cutting the back-office workload.

It is very easy for the business to fall behind the agile project teams because it is easier to develop new ideas than to start using them in your everyday work. Our brains take time to build new habits and there are only so many new habits we can build at one time. We are on the brink of ‘change overload’ triggered by our agile colleagues.

Overcoming change overload

So this is where we need to concentrate our efforts if agile is to become a reality. We need to clearly define all of the steps needed to incorporate system and process updates into our ways of working:

• Create pre-defined mini process workshops so that in 90 minutes an operational team can create new ways of working.
• Require project teams to automatically create ‘guidance notes’ to explain how to access/use what they have created and stop pretending that everything is ‘intuitive’ so doesn’t need explanation.
• Resource full-time on-the-job training function, to ease the path from creation to adoption, sitting partly in the project team but still a colleague of the users impacted by the project deliverables.

This article was originally published on Linkedin, and edited for web by Cecilia Rehn.