04 Sep 2016
Agile needs ‘BusOps’ and DevOps
by Melanie Franklin
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 2 problems, only 1 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 is only so many new habits we can build at one time. We are on the brink of ‘change overload’ triggered by our Agile colleagues.
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 a 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
If you are concerned about some of these issues, get educated about Agile so you can start creating your own solutions to these issues.