Our Work


Sometimes You Have to Hit Pause and Reset

By Gwen Daniels on February 06, 2016

Just before the start of this sprint, Lisa (ILAO's Executive Director), Teri (IllinoisLegalAid.org Product Owner/ILAO's Program Director), and I sat down to discuss the website rebuild, our scrum process and reality. Like so many tech projects, we are behind schedule and over budget (or likely will be because of the schedule delays). So this sprint, we decided to hit the pause button on technical development and regroup.

Our Scrum process has always looked at only part of the picture: the rebuild. It failed to take into account the other work for which our various team members are responsible. In 32 sprints, we've only met the number of points we committed to take on once and our velocity (how many points we can accomplish during any give Sprint) changes constantly. Adding to that, the content team had a parallel Kanban process going for the last several months to track all of their additional commitments (and in fact, imported their rebuild responsibilities into that process as well as in the Scrum process). The biggest risk to this project has always been competing projects, and when you have a part-time team working on the project while still juggling other projects, thing can get dropped. Not seeing the full picture during a Scrum meeting makes it harder to prioritize the rebuild work ahead of other work and makes forecasting really difficult.

So we decided to make some changes. The content team is no longer part of the Scrum team. They are handling the content transformation work within their Kanban process. It made sense for them to only have one process. For the technical work, we are keeping the elements of Scrum that work well for us and ditching the rest. In some ways, we've adopted a Scrum of Scrums approach (minus all the Scrum teams): Stephanie (content), Teri (product owner), Dina (UX), and I (Tech) meet in place of the normal sprint planning meeting to discuss what needs to get done in the next couple of weeks. Stephanie takes anything that may affect content back to her team. Dina then discusses the UX stories with Alex, our User Experience Research Coordinator, and I hop on Google hangouts to chat with our contract developer, Kelly, from my desk to hash out technical paths forward on our stories. Previously, having everyone at the table for the planning process made it hard to hash out the implementation details necessary to accurately plan our work. Our meetings are significantly shorter and more focused on technical issues than when they included the full team.

Kelly (our contract developer) and I still do a daily scrum and we still maintain our product backlog, which serves as a living history of what we've done including all of our comments and documentation as well as a running inventory of all of the features that we want to have but haven't gotten to. It helps us to prevent the not uncommon occurrence of postponing a feature to meet a deadline and then forgetting about it. And because the greatest benefit of the Scrum process at ILAO has been increased communication between content, tech, and UX, we are getting together once a week to compare notes and help each other out where needed.

The second thing we're doing in this "pause" period is to go back and lock down the version 1 scope. We've done iterations of "these are the version 1 features" but there is a big difference between saying our new website will have legal content and spelling out what needs to happen to allow us to post that content and display it on a webpage. It doesn't address what else goes on the page besides the legal content, and how it gets searched or navigated to or where else on the web site that content may be used. There are a lot of hidden requirements that we are trying to uncover and document appropriately in the backlog to ensure that:

  • we are all on the same page as to what we are building;
  • no high priority feature gets dropped;
  • low priority features get stored in the backlog but resources do not get expended in version 1 building low priority items; and
  • we can more realistically estimate the remaining effort required to launch version 1

It's something that should have already been done, but this is a new process for us and we're still working through learning how best to do something of this scale as a team. We're going to screw up from time to time. We're going to look back and say "I wish we'd had the designer lay out that page" or "You realize that with this change, I'm going to be deleting about 3 weeks worth of work right?" But these things are inevitable on a software project. Agile projects beat waterfall projects because we are catching the wrong things now instead of the week before we go live. We can hit pause, regroup, and move forward while hopefully minimizing the "we got it wrong" or "we missed that" moments.

In locking down scope, it means that sometimes we are wireframing a key project (not beautifully, but just enough to convey the requirements), some of it is simply annotating a blank page with notes about what needs to go on it and what underlying functionality needs to exist to accomplish it (for example, a popular today block requires that we pull in Google Analytics data to determine what is popular) but a lot of it is simply talking through assumptions and making (and documenting) decisions. Teri, Dina, and I have been going back and forth over items the past week and will continue to do so for the next week or two.

Once this is done, we can get back to building out the rest of the functionality of the website and get the new IllinoisLegalAid.org launched and live for the world to see. In a project as big as this, these kind of 'resets' are essential. They're hard, but they're essential. What we're building will be a key piece of ILAO's infrastructure for the next decade. It's important that we take a little extra time, take a step back and refocus so that we can get this project built right.