10 Tips to run Agile in a multi-project Agency
October 22, 2018by Chris Carreck
These days nearly every one does, or tries, to do agile. Every place you look has a different flavour of Scrum, XP, Kanban, etc, all with custom adaptations to suit their product, business, project.
Mostly, it revolves around one project, or multiple projects each with their own scrum master, own dedicated development team, running independently of each other.
What about it a multi-client, multi project agency, where we have a single team of developers, working across a range of ongoing projects and products for a variety of clients, each of which requires a different type of skill set at any given time, depending on the type of work being required?
The simple answer, one which I’ve seen raised in discussions before, is only allow one project at a time, focusing team effort on a single unit of work, before moving to the next. The idea being not to spread to thin and increase productivity in one concentrated space. But this doest work for us, our projects aren’t always just straight full stack development. Some require specialist DB and API knowledge from a back-end developer, some require a designer only, or a UI specialist to integrate a bunch of flat designs, before we move onto the next phase or await client sign-off. Also our clients want to see progress. They don’t want to wait 3 months while we complete some one else’s project, so there are business concerns that we need to be mindful of.
To this end, here at CLD we have found the following approach has really helped us as we run several projects at once:
1. Get your tooling right
We switched to jira from git tasks and zen hub. This allowed us to create proper backlogs that could be groomed and ranked accordingly. We have backlogs per project, broken down into epics. An epic may represent a feature or enhancement within that project. We also have an overall studio backlog, that all projects feed into. This allows us to prioritise internally and externally per project with a client, and also get a feel for the overall backlog of work going through the studio at any one time.
2. We use a Kanban
Rather than constant sprint planning, we use Kanban to track the progress of tasks, to help identify where blockages are occurring or where we need to focus resource. Each project has a Kanban board, and we have a studio overall Kanban board. This gives us insight at both project and overall studio level, we can see where items are being held up, where we may need to target a certain type of resource etc. We also may create a board for a specific ongoing within a project, for example a project where we have an ongoing commitment to an SEO budget.
3. Target releases not projects
We have a mix of ground up new builds and ongoing features, improvements and maintenance to existing projects. With this combination we have found it more efficient to target a release or specific feature, and plan the tasks required to complete that feature. We generally then make a call if a set of tasks for a release are to big and should be broken down, generally we try and keep this to less than a week for anything in a release, anything over that, its the next release.
Automate as much as possible, from Kanban tooling and task management, to merges, testing, deployments and board updates. With multiple releases, multiple projects and multiple boards, having to constantly update every change, spend time on every deployment (as they happen so often) can take up a huge amount of time. We automate our Jira task updates, by integrating with GitHub, smart commits and scripts, which are hooked into our deployment process, which in turn is integrated into our merges so our boards are updated automatically during an automated or scheduled deployment or commit. Basically, PMs and product owners can concentrate on backlog priority and what we should release next, devs can concentrate on new features and code improvement, and our testers can concentrate on specific use cases and edge cases and be notified when things are ready for testing without constant oversight.
It may seem obvious, but its key. Stand ups are per project, alternating every other day, so any crossover resources are not continually tied up. Also effective communication day to day, be it at a desk, via slack etc. Walkthroughs and product owner involvement and demo’s to explain a feature progress mid-sprint are still vital.
Minimum viable product. We bill time and materials, and we have a pre-agreed rate and deliverable with the client. We cant go off script and start adding nice to have’s. We concentrate on delivering the best value for the client, and look at how to grow out the feature once the core is delivered. This goes back to planning to a release, we need to be very strict on what goes into a release, and what might get bumped to another version.
7. Not writing full user stories is OK.
We don’t write a full user story. We tried that approach and found it didn’t always work. Sometimes, just the technical details are enough. Such as “wire up age verification API on step 3 of checkout” with some details on how to do that is enough. We don’t go with “As an administrator, a users age must be validated before their account is opened”. We keep it succinct and direct.
8. Burndowns and retrospectives
We don’t produce these for all projects and we don’t do retrospectives each week or fortnight. We are in such a fast paced environment, we don’t have time each week to sit and run through with each team thats working on a different project. We catch up once a month and retrospect on the month as a whole, what went well on some projects, what didn’t and where we should improve.
9. We begin Agile at the design phase.
Usually projects have a discovery and learning phase, exploring the products and the needs before we are ready to wireframe and move towards flat designs. The wider team is still included in these phases, however we don’t run it as “agile”. Its after this stage, when we’re ready to design, that we start developing our stories, putting our Kanban board together and start stand-ups with the project team.
10. Include the wider team in discovery
Although we don’t start the agile process until we’re ready to begin design and wire framing, it makes sense for us to keep the team involved at an early stage. To identify potential pitfalls and gotchas early, it allows the team to hit the ground running when we are ready to start our backlog.