Industry: Health care provider
Headquarters: Walnut Creek, CA
Employees: Approximately 5,000 employees, with several hundred in IT.
Atlassian tools used:JIRA Studio with e-Business team. Other teams at John Muir Health use on-premises Atlassian tools.
John Muir Health is an award-winning health care provider that runs a network of hospitals and clinics in Northern California. Dustin Pearce is the Program Manager for the newly-formed e-Business team, tasked with revamping John Muir Health’s online presence via the Web and mobile apps.
Tell us about your team. How many people and where are they located?
We have about 10 people working on 4 different projects. Only two of us (myself and a business analyst) work at our headquarters. The rest of the development team works remotely. We work with two different contracting agencies. One is deploying and customizing our content management system, the other is building a mobile app.
How did you learn about JIRA Studio?
I’ve been using Atlassian tools for years. Soon after I joined John Muir Health 5 years ago, I brought in JIRA, Confluence and Crowd. When I shifted over to the eBusiness unit, we needed a new set of development tools, and JIRA Studio was the right fit.
Why did you choose JIRA Studio instead of using on-premises tools?
As a new team just getting off the ground, JIRA Studio saved us valuable time because we didn’t have to deploy and administer it.
Also, with so many remote developers, we don’t have to deal with the hassle of getting each person VPN access before they can start coding, viewing issues, etc. We just set up a JIRA Studio account and they can start working in minutes.
What sort of software development process do you follow?
Our two larger teams are following an agile approach. We do three week sprints, with a week in between for retrospective and planning.
The concept for the new applications was defined by the business analyst on my team. She created a ‘story matrix’ in Confluence, that correlated user stories to different features. Each story was then assigned a priority (‘must have’, ‘should have’ or ‘uncertain’) and mapped to a virtual task card.
Based on these prioritized stories, the team gets together and decomposes the highest priority stories into estimable tasks. We are still a fairly new team, so we’re figuring out our velocity.
How does your agile development process work with remote teams?
We do daily stand-ups for each team where we share the task board in a video phone conference. Each team member updates the status on their issues and identifies impediments. Our task board contains the columns ‘To Do’, ‘In Progress’, ‘To Verify’ and ‘Done’. A basic rule is that if a developer is not working on a task today, then it goes from ‘In Progress’ back into the ‘To Do’ column.
As the scrum master, I keep an eye out for tasks that are staying too long in the ‘In Progress’ or ‘To Verify’ column – With all our developers working remotely, this is often a sign that a particular task is taking longer than was expected, or might be a risk.
In addition to the video conference for daily stand-ups, we try to get the teams together in the same location for the planning and retrospectives. That’s why we allocate a full week to these activities. Getting together is a good opportunity to build rapport and trust and improve communication during our sprints when everyone is remote.
What are the biggest challenges you face as a distributed development team? How are you addressing them?
The biggest challenge of working with a distributed development team is the lack of transparency and visibility. It’s harder to build and maintain trust. You don’t have that ‘peripheral vision’ that exists when everyone is co-located. The fact that our teams are also new and don’t know each other well is another challenge.
We address these challenges by having a lot of video and phone conferences. In addition to the daily standup, the teams might meet several times per day to talk about implementation details and other topics. At the start of the project, we had everyone come on-site for a week to work together, and that helped build a lot of trust.
I feel confident working with this team because all the engineers are very good, and I talk to them daily. If I were working with an outsourcing agency where I couldn’t talk to the individual developers, I know it would be a lot harder.
What advice would you share with other distributed software development teams?
In order to make things work with a distributed team, you need to have experienced developers who are capable of being productive independently. You don’t want to have someone learning to do something new on their own. That’s very risky.
I also recommend that you get together in the same location as often as possible, even after every sprint. That’s why my teams have a full week between sprints, to allow for travel time and working together.
For day-to-day tracking, nothing I’ve tried works better than the virtual task board in JIRA Studio. I know that every day the status of issues will be up-to-date, and everyone is looking at the same view of our progress towards completing a sprint. It let’s me look back and see the big picture knowing I have accurate information.