Our Work


Diverse Team + Many Hats = Adaptive Scrum

By Gwen Daniels on November 13, 2015

We did something this sprint we've never done before: we added stories specifically for the Product Owner. That's not a typical move for a scrum team to make, but we're not like most development teams. Most Scrum teams are made up of developers working on software features. We've got that, but we also have two members focused on usability, design, user testing, and UX generally and 3 members focused on transforming our legal content. Most Scrum teams are also working full-time on the development project. Since we all have other responsibilities besides this rebuild project, we are not.

So why did we do it? Because Teri (our product owner and program director) wears many hats. Yes, as product owner she is responsible for ensuring we are building the right product and not wasting very precious resources on the wrong thing. But she is also:

  • designing our navigation structure
  • working with the content team to structure how we transform content
  • participating on the committee developing the design for the new IllinoisLegalAid.org
  • my sounding board for development issues
  • responsible for coordinating things that fall outside of tech, UX, or legal content

In reviewing the backlog (the place where we list all the things that we need to do) for Tuesday's sprint planning meeting, Teri and I identified some stories that were blocked because of items she was responsible for that weren't reflected in the backlog. For example, Teri has taken primary responsibility for creating and documenting our navigation and content triage taxonomy. Until that work is complete, several of my stories are blocked.

By adding Teri's stories to Jira, we can document the blocks, have her work archived as part of our Jira documentation system, and she can track her hours in Salesforce (At ILAO, everyone tracks time using a Salesforce app). Just like any other dev team member,Teri participated in estimating the story points for those stories and determining what she, as part of the team, could realistically take on in the next two-week sprint. Why is this good? Well, not only does it help get the work done, but it keeps the story on our radar so we can check in with her at the daily scrum (while it is optional for the product owner to show up, Teri nearly always comes to our daily meeting). In short, Teri is like a really epic Transformer: part dev team-part product owner-part Program Director.

This isn't the first time we've decided to do things differently. First, we broke the Scrum recommendation that the team spend 2 hours per week in the sprint planning meeting. We plow through the prioritized backlog in 90 minutes, instead. That doesn't leave much time to really break stories out. With a part-time team, 4 hour meetings every 2 weeks is more of a burden on our limited time than anything else.

Second, I've taken on a larger role of managing the backlog as it relates to technical stories in the last several months. This means I go through the technical stories in the backlog and try to break existing stories down, add technical suggestions as comments, add new ones where I see things missing and prioritize based on known dependencies. This is all stuff the development team would be doing if we had longer planning meetings, but this approach allows me to do it at times that work best for me and without subjecting the non-technical team members to long Drupal-specific conversations. Our contract developers are usually just an email or Google hangout away.

So why not just break the team up into multiple teams? We've thought about it a lot. But here's the thing. We get the best results when all three elements (UX, Tech, Content) are part of the conversation. UX can work with the designers to create a beautiful design but if tech can't actually implement it, it'll never be anything more than a really nice Photoshop file. If the developers create a form to create legal content that doesn't have the fields the content team needs to create new resources or has labels that make no sense (developers should NOT write final copy, BTW), then it's a waste. By involving content and UX in the technical development, we build a better project the first time around. And by involving UX and technology in content strategy, we give our users a better overall experience.

But probably the best example of breaking the scrum model for the good of the team comes from the last sprint. Dina and I, representing UX and tech, and the content team members of the development team, locked ourselves in a conference room for half a day and mapped our existing divorce content to a new bundle-able model. It allowed us to work through a whole host of issues: where does this article belong in relation to all the others? how does a user get to it? what does the user see on the page? what do we need to build to create this format?). And had we not all been in the room together, it would have taken much longer to resolve than those four hours (plus some content team follow up the next week). As a result, in the current sprint, we started with numerous stories to transform content to the new model and to build the new content bundle structure we need to support that model.

At the end of the day, here's the truth: the diverse skills and roles of our team allows us to do things better, even if we must sometimes ILAO-ize the Scrum process.