agile
business
technology
software

Agile – A Business User’s View

Nick Churchill-EvansApril 4th 2018

We were recently asked to provide one of our clients with consultancy services that will create a range of documentary deliverables, rather than our more usual software solutions. So whilst requirements and documents need to be ‘developed‘ through the course of this work, it will not in itself develop any software or technology solution at this stage.

Can an agile approach work outside development?

We were recently asked to provide one of our clients with consultancy services that will create a range of documentary deliverables, rather than our more usual software solutions. So whilst requirements and documents need to be ‘developed‘ through the course of this work, it will not in itself develop any software or technology solution at this stage. This provided an opportunity to have an internal debate as to how best to manage the work to ensure that we would facilitate efficiency, creativity, quality and accountability. To cut a philosophical debate short, we concluded that we should adapt our standard Agile approach, rather than looking to a more traditional methodology, or simply leave a set of skilled, motivated and intelligent people to simply get on with it. All three options were valid given the nature of the work and the people undertaking it, although the latter was the least appealing to me, regardless of who was doing it. I’m not a control freak and I don’t want to state the obvious, but experience shows me that things are more likely to be done properly with management rather than blind faith!

Putting aside the details of this particular work package, or any other for that matter, one of the outcomes of this process is that has allowed me to take stock of the fundamentals of Agile as a business user. These are not ordered and illustrated formally but are the pieces, from my experience at least, that make a difference as a business user looking in on the real work from the outside, observing the results that they precipitate.

At the top level, within the interpretation of Agile that we use as a business for delivering projects on behalf of our clients, we have a number of key components:

Product Roadmap/ Deliverables/ User Stories: Sufficiently detailed, documented view of the deliverables in the form of contextual user stories. The contextual element being that each story is written in a form of who it applies to, what it will do and why it will do it
Sprints: Running iterative rounds of work in 2 week chunks
Planning: Planning games at the start of each Sprint, democratically planning and elucidating the deliverables at the start of each Sprint
Scrum: Daily Scrums for all team members on each day of each sprint, focused on exceptions such as ‘what I’m stuck on’ & ‘what I’ve not managed to do’
Show & Tell: At the end of each Sprint, Show & Tell allows work to be demonstrated measured stories to be accepted by the client as either; delivered in the ‘product’; set for amendment or; rejected
Retrospective: Periodic reviews to look back and learn, with a view to perpetuating good practice and starving bad practice

We also couch this within a few other concepts that assists in practical application:

Minimum Viable Product (MVP): Chunking projects into phases where each is the minimum size that it can reasonably be, yet in each case producing something that the business can potentially release and in turn gain benefit from
Expect and embrace change: Allow the requirements to change within the time/budget/effort envelope and encourage the ultimate product to move with the business.
Peer review: reviewing work round the team to pass on good practice, identify and address bad practice and ensure quality and consistency.

When I abstract these from the business of software development and consider them more generally, what I see is that these principles can be applied to pretty much anything that I need to do within work that requires any degree of organisation or needs to manage complexity. They create a very positive landscape which is:


Transparent: Because we are constantly and iteratively, planning, monitoring and reviewing, there’s little that can be deliberately or accidentally hidden from an attentive participant
Business focused: Because the approach is completely accessible to business people it allows them to ensure that the work is grounded in their requirements, rather than being permitted to take on a technical life of their own
Pragmatic: The iterative nature, willingness to change and the focus on the MVP concept, promotes an approach that is centred on meaningful, incremental steps that deliver work packages that are practically linked to the evolving needs of the business and its desire for delivery of things sooner rather than later.

Even having worked as a developer 20 years ago, I understand little of the technical detail of the work that our developers undertake. However, the Agile method gives me great insight into the health of our projects, provides me with comfort that quality requirements are being observed and that projects remain business focused.
Coming back to the idea of using this to complete a complicated and broad piece of consultancy work, we rationalised that these facets are just as desirable as they are within a software development project. We also recognised that they will help us manage complexity and uncertainty without burning a significant proportion of project consultancy time defining, scoping and pre-empting at the outset. In short we are expecting better results from the consultancy process for our client, delivered more swiftly than if we had taken a classical waterfall approach.

© Nick Churchill-EvansApril 4th 2018

Credits

Social

© 2018 Copyright cloudThing ltd. All rights reserved. Company registered in England & Wales no. 7510381, VAT no. 152340739