Last month a few of us in the team attended WordPress maintenance support plansCon Vienna with fellow WordPress maintenance support plans enthusiasts and developers from across USA and further afield.
Over the three days, my teammates and I hosted several Birds of a Feather (BoF) sessions between us. The format is more participatory than a traditional talk, so it’s a great opportunity to engage in discussion and hear other perspectives from within the community.
WordPress Update has been delivering digital projects since 2001, refining our agile delivery process over the years from the DSDM Agile Project Framework in combination with other agile practices particularly suitable for an agency environment.
My first BoF session invited other conference attendees to share their experiences (the highs and lows), tips and best practices for making Agile work in an agency. The following is a roundup of what we discussed over the hour.
Starting slow.
We identified that the typical journey sees agencies start off being ‘agile’ with a small a. They have begun to implement some of the process tools around agile, such as SCRUM, standups, sprints and so on, but aren’t yet living by the core elements of the Agile Manifesto.
Individuals and interactions over processes and tools.
Working software over comprehensive documentation.
Customer collaboration over contract negotiation.
Responding to change over following a plan.
Agile Manifesto
Including the client.
We talked about whether the client should be an integral part of the delivery team or should be kept at arm’s length. Those who believed they had an Agile workflow suggested that the client should be part of the team and involved throughout. The benefit being that – as part of the team delivering the product – they share the risk with delivery.
Those who felt they still had some way to go in becoming Agile were more wary of this approach, believing the client either couldn’t take on these roles or wouldn’t want to. These agencies were more likely to retain full control of the project and client, and accept all the risk as a result.
Handling changing requirements.
There was a discussion about the time taken up with dealing with change, and how clients don’t always appreciate the efforts involved in managing their changing requirements. I described how we deal with this at WordPress Update with our Dual board in Jira.
This process separates new ideas neatly from refined and signed off units of work ready for development. The client can see their backlog of new ideas and what state each is in, and knows that effort will be involved in taking those ideas from concept to ready for development.
We also considered the need for developers to be able to highlight to a client when an idea is completely new, and to prevent them from trying to squeeze additional functionality into a sprint which already had been signed off.
It’s good to have a SCRUM master or some level of leadership position in the team so developers don’t have to make these decisions themselves and can defer to someone else if they are unsure.
Questioning sprints.
Someone raised the idea that sprints were a waste of time in a truly agile project. They suggested that nirvana could be achieved with Kanban alone; there is only work in progress and with an engaged client and team you would be constantly refining the backlog so new work could constantly be pulled in and worked on. This works well in a model where the client has you on retainer as their technical team for a long period of time (rather than to deliver a specific thing, like a website).
So there’s always a finite amount of WIP (work in progress). If stories are always refined to the point that they are about half a day’s effort for one person, and are complete (finishing them can be tested and, in theory, released) then you can calculate the velocity and the time remaining on sections of work fairly accurately.
We invest heavily in agile training for our staff and clients, and we’re currently hiring for multiple roles including a Delivery Manager.
Source: New feed