“Jira sucks”. They said.

It wasn’t the first time we’d heard that. As a fundamentally creative team with a digital agency heritage, we do work in a way that depends on close collaboration between the people working on a variety of projects in regular two-week sprints. On paper, Jira (and other tools that model Agile methodologies) should be perfect for teams like us and the success of these tools and the companies that use them prove that they don’t suck. But something was not sitting right.

Creating digital products in an agency is fundamentally different from the equivalent team working on a project with a fixed team. For any two week sprint, we work across many projects for many clients. That means there are lots of opportunities for delays, interruptions and curveballs.

But also opportunities for new insights, creative ideas and collaboration with clients. These external influences mean that Scrum sprints or Kanban practices are brittle and sometimes break. This is because, at any time during a cycle, the team members working on a task or ‘Story’ may need to prioritise other Stories, create new ones or even drop a Story altogether. An entire project may even get ‘Blocked’.

We acknowledge the reality of our clients’ businesses as we operate a cross-disciplined team across their requirements. It's the fundamental reason our clients work with us -- our cross-disciplinary expertise amplifies their internal capabilities.

In a search for an alternative to Jira, we looked at many products and after a comprehensive review saw pretty quickly that none allowed us to achieve what we wanted. They either too closely modelled a formal software agile methodology or followed a very traditional centrally controlled task allocation style of project management.

Our requirements were pretty simple and included:

• Increased Flow Time for the team is the ultimate goal.
• The team should be in control of managing the planning and execution of the Stories in their Cycle with autonomy rather than have someone else do it through command and control.
• The Kanban needs to be scalable to support many projects and clients and should always be visible and accessible by the team no matter how many projects are in play.
• Stories are currency, so their completion is something to celebrate. It should be rewarding and fun to complete Stories and Cycles.
• Data entry is a pain, and so it should only happen once to eliminate waste.
• We needed to be able to see the future to see how people were allocated on projects in future cycles and plan for impacts when changes inevitably occur.

As a company of digital obsessives, we have built products from scratch for startups and created new products and ventures for existing businesses looking for an edge in their markets. We were uniquely positioned to make this product for ourselves.

Using the Jobs To Be Done framework to understand user needs, we developed what ended up being an extensive list of issues, pains and gains that captured the full gamut of requirements from the various internal audiences types, relating to delivering and measuring the work.

After conducting a road mapping exercise, we were able to develop a shortlist of core features that would be necessary to allow us to replace our Google Sheet based tool for Cycle Planning as well as Jira. This shortlist, coupled with our understanding of the needs of the business, would become our MVP or Minimum Viable Product.

The shortlist ended up being more of a medium list, of course.

So, given that we live in the real world, where the product development work required to complete the MVP, would also need to work in and around our current client work, we needed to find a pragmatic way to make this happen - with limited resources.

Taking the true MVP approach, our team whipped into action and designed a feasible solution that would get a working product into use by the studio in a matter of weeks not months. This allowed us to unshackle ourselves from JIRA and start iterating on our product in a way that really worked for us, the users. It wasn’t pretty but it did the job.

Every day new feature requests, UI improvements and business reporting requirements continue to flood in, and sticking to our approach we prioritise quickly and iterate fast. Daily releases keep the team engaged and celebrating the true value the new product is delivering to our studio.

We’ve chosen to host the application on Google Cloud using their Google Kubernetes Engine service, which has proven to be a very flexible, efficient and satisfying for developers to build upon. It also provides scalability and flexibility for the future.

The vision is to have a tool that is empowering and fun to use for teams like ours and one which means they get more Flow Time. We have more work to do but perhaps one day soon you’ll also be able to get In Flow too.