Four apps. Two platforms. One week development cycles. One board to rule them all.
A little while back at Rounds we decided to make a big change. Rather than focusing most of our energy on a single app, we decided to branch out. Within the span of a week we were working on four separate apps (Rounds iOS, Rounds Android, Booyah iOS and Booyah Android).
We decided not to split developers up into teams per app. As a company we want to keep the flexibility to move resources around to accommodate constantly shifting priorities and we also feel it’s important to make sure knowledge is shared by as many people as possible.
As Release Manager, this presented a bit of a challenge for me. I wasn’t so much worried about being able to get out a version per app per platform every week as much as how in the world were we going to plan and follow up on all of this. How would we track work when a single developer might have tasks on several apps within a single week?
We use JIRA as our project management tool and the bold first move we made was to make the move from Agile to Kanban. It was a move I’d been ready to make for a while and here’s why:
We’re one team. We’re one team that works simultaneously on (so far) up to four different apps across two platforms and a server – but we’re one team. So for me, regardless of the fact that we release weekly versions sprint-style, managing and making visible everything that happens in the company means having one board.
So, no big deal, I just need one board to be effective for developers, QA, analysts, product managers, marketing and, hopefully, me.
What I’m looking for in an ideal Kanban board:
- An easy way for me to balance sprints (oh I know you don’t think they’re sprints because it’s a Kanban board but chill :)) for all apps across both platforms and make sure work was distributed appropriately across developers
- A prioritized backlog of tasks alongside current work – tasks ready for development and those still being defined
- A backlog where Product can build and prepare tasks without worrying that they might get into developers hands before they’re ready.
- Clarity for developers to always be able to enter into JIRA and know exactly what they should be working on and what is coming up without ever having to juggle priority. Even if they are working on 3 different apps.
- A direct path for QA to receive anything that is ready for testing as early as possible – and certainty about how and what to test
- A big view so team leaders are able to easily see where their focus is most needed – which app, which platform whether it’s code review, technical review of upcoming specs, or helping to push along tasks that are in progress
- A filter for Marketing to see only the new features and when to expect them so they can be prepared
Filters for BI to be able to know when events need testing or features are being released so they can always be ready with their analysis
- One place for everyone who is interested to be able to see easily the progress of any app, any version, any time
So how did I get this dreamboard?
Basically, it starts and ends with our one giant Kanban board. Each app is a project, we use labels to differentiate between platforms (ios/android). We use versions to delineate “sprints” as those essentially become releases
And this one giant board has all the filters which we use in coordination with ALL the labels… We go label crazy. A little overhead in the ticket creation process saves an unbelievable amount of time in terms of communication down the road.
- Events, needs marketing promotion, type of qa….everyone from any team can filter and find what they need. All on one screen.
- The labels also come in handy to searches for present sprints, past, future….no more emails about “which events are fixed in this version?” – just search that version + events. Boom.
What this gives us
- It’s not in our culture to keep secrets from one another here. Anyone who wants to know what’s going on should be in the know.
- Being able to see the company’s big picture at any given time should give everyone a deeper understanding of why they are working on what they are working on
- With an agile board I can look at one sprint at a time. We commit to these specific tasks and it’s not so easy to change. When balancing 5 apps, priorities can change in a second. What we had time for when planning a sprint we no longer have time for in the middle of it. Kanban makes it easy for me to adjust tasks on the fly.
- I can prioritize any sector within an app or platform (ie per developer or in code review), or everything together (for people like head of mobile who needs to see everything)
- Similar to visibility but a little different. This plan has cut my time writing emails and cross checking several different docs by way more than half
- Emails go to who they go to – this can be in front of anyone’s face any time they choose to see and better even – its updated in real time
Is this the simplest thing ever? No. Welcome to JIRA :) BUT, shifting into our new processes went even more smoothly than I initially expected. When everything is laid out and visible, and the reasoning behind doing things is clear to users (read: US), adoption to change is pretty easy. When people understand why they’re doing what they’re doing and how it benefits them, they tend to be happier to do it.
And a developer told me this was pretty cool. A developer. Said something about JIRA was pretty cool. Is that sinking in?