Who Is Case Commons?

Case Commons' mission is to transform public sector human services (child welfare, homeless services, juvenile justice, etc.) through user-centered design & technology.

Front-line staff in these fields are some of the hardest-working public employees. Every day they make life-changing decisions about their children and families, in chaotic conditions, and with limited information. Case Commons wants to make sure these staff have all the information and support they need to make smart decisions and help improve lives.

We're pursuing this vision through the development of Casebook - the first collaborative, family-centered case management system for child welfare, enabling workers serving the most vulnerable families and children to be more effective and efficient via new software tools. Case Commons is funded by the Annie E. Casey Foundation, which has spent 20 years pursuing human services system reform. Case Commons also works in partnership with Pivotal Labs and IDEO.

We have some really hard challenges ahead: transforming our product into a platform that encompasses new states, developing analytics that help case workers make better decisions, visualizing social networks to help caseworkers see complex patterns, and mining case data to develop insights into what works. That's where you come in: we need more great people to help us achieve our mission.

A week at Case Commons

Start of the Week

Everyone gets to the office right around 9 AM. We're co-located with Pivotal Labs, a leading software consulting company that forms the bulk of our dev team. Getting here is easy. Most folks take a train in but there are a few who bike to work. (For them, we have a bike room and a shower.) There's breakfast and hot coffee for everyone. Mondays are bagel days. The rest of the week we have a fantastic breakfast chef.

9:15 – Casebook Standup

Every day at 9:15 we all pile into the big conference room, Grand Central, and get our remote developers on Skype. We do a quick recap of how every open story (feature) is going and also figure out who is going to work with whom for the day. Our developers practice pair programming so they're always in twos. We find it helps with knowledge transfer and spreading new skills around.

Design & Product help out at the standup whenever there's a lack of direction or specific UX questions. For the most part a technical lead drives the meeting.

Surprisingly, these meetings typically only last about 10 minutes even with our 30+ team members.

9:30 – Iteration Planning

The product, design, and entire development team piles back into a big conference room and looks at our backlog in Pivotal Tracker. The goal of Iteration Planning is to understand which features are slated for development during that week and estimate the difficulty of any of the stories in the backlog that don't yet have estimates. We aim for iteration planning meetings to last under an hour. We make that goal most of the time.

The development team estimates stories based on their collective understanding of the level of difficulty of the problem and the overall scope of work. These estimates don't and shouldn't map directly to time. We use estimates to figure out which features, as they were designed, are risky and which are not. Based on that, the product and design team can either make the requested features simpler or prioritize differently to better meet the users needs.

12-1 – Lunch

Afternoon

Afternoon The Product and Design team sync up (rather informally) about the design priorities for the week. We talk through our progress since the last check in and allocate new work to whomever has availability.

The typical flow we've been using is to have a product manager and a designer team up on a particular business need. The two then investigate, research, and talk with the different users to understand their personalities and approaches to (the) software. When they feel they have a handle on the idea, they create a couple sketches of software which could meet the need.

After getting user feedback about how well the functionality meets the business need and is appropriate for that user, the designer starts pushing the sketch to progressively higher fidelity. Our product manager and designer team keeps working together until we're confident we've solved the problem and designed something users will be able to immediately grok.

As design & product is talking about the upcoming features, the developers are deep in their work. They might have questions about an interaction or a final design. Expect to be interrupted by the developers to answer those kinds of questions.

5:45 – Technical Standup

When the team got large, the developers felt they weren't sharing enough tech implementation details with the larger team while it was fresh on their minds. So, at the end of every day, they pile into a room and talk about interesting efficiency gains, tricky bugs, or new rubygems that might help the project. Totally optional for non-developers.

Middle of the Week

The rest of the week follows the same rhythm. Breakfast is served around 9 AM every day. We have our different standups to check in and keep everyone in sync. Product Managers talk with the users and collaborate with designers. Designers work with PMs at the whiteboard and create delightful ways of solving the core needs. PMs work on writing stories for the next week. Our developers pair program to build awesomely maintainable software.

When someone needs an answer, we're free to get it by whatever means necessary. If there's confusion about a feature, it gets asked or answered on the spot.

End of the Week

On Fridays we'll typically have one of the following special meetings. You still get out around 6 PM. A lot of folks hang out after work on Friday to have a few drinks, listen to music, and play ping pong.

Special Meetings (alphabetical)

Kaizens

Kaizens are more focused meetings that we have every week or so. In a Kaizen, the product, design, and development team get together to focus solely on what is going wrong and come up with solutions that remedy the problem immediately.

Retrospectives

Every month or 6 weeks we get everyone in a room for an hour to talk about what's going well, what's not great or terrible, and what's making you upset. Everyone on the team gets to voice their own opinions. After everything is written on the white board, the group decides which issues we're going to try to improve upon.

Once we have a volunteer (or someone is voluntold) we agree upon a specific actionable approach to address that issue. We keep assigning people and coming up with collective solutions until the top inefficiencies are dealt with.

User Testing & Shadowing

We conduct all kinds of user testing. Now that we're live, users are constantly sending us feedback about what they like and don't like about our software. When we have design that addresses their feedback, we immediately send it over with a few clarifying questions.

We do more formal user testing as well where we've prepared a list of questions about varying designs and have carefully selected our users. On top of pure usability testing, you will have many opportunities to shadow caseworkers as they go about their daily work lives including home visits, watching staff use our program for their data entry, and sitting in on the meetings with clients, coworkers and their bosses.