Using Scrum to manage policyIQ (Part 1 of 2)

If your role in any way touches the world of technology, it’s likely that you’ve heard of “Agile Methodology” as a way to manage software development.  The concept is pretty simple (and I’m going to simplify it even further): build, test, and get feedback in short iterations.

A specific method of implementing Agile Development is Scrum, a method by which a team works together in short “sprints” to complete specific goals.  (The folks at do a fabulous job of summarizing the method – and it has very little to do with rugby.)  Our product development team has been using Scrum to develop policyIQ for awhile now.  The short (typically 2 week) sprints allow the team to complete the development on a feature, test it and get feedback – sometimes directly from customers and sometimes from our policyIQ account management team.

scrumThe enthusiasm around Scrum was infectious – and the whole team caught the bug

As the development team started to really smooth out their Scrum process, it was clear that the methodology kept things on track.  And the enthusiasm for it was infectious.  While “Agile” and “Scrum” are typically words associated with the actual software development, we started to ask, “Why can’t these same principles be applied to everything else that the policyIQ team is working on?”  So we set about applying Scrum to the entire team – and we needed the help of our internal policyIQ application to do it.

I should point out that I am NOT a trained Scrum professional.  Our Senior Manager of Technology is trained; with his guidance, we’ve taken some liberties with the “official” methodology to apply it to our work.

How do you get started?  You just start.

scrumstartedquoteOne of the lessons that our trained “scrum master” (ie our Senior Director of Technology) taught us was that you can’t get too caught up in starting off perfectly.  You just have to get started.  So we did.

We started by taking all of the project plans and “boy wouldn’t it be nice” lists, and translated those into User Stories – descriptions of the project or task that focus on what the impact of those projects might be.  For example, we wanted to issue a Client Survey.  The user story read:  “The policyIQ team wants to craft a Client Survey, so that we can better understand the needs and desires of our current client base as it relates to product features, support and training.”

The Scrum method suggests that you determine the length of time for each “Sprint” – no longer than 30 days – and then break your projects down into pieces, so that you can complete those pieces within the sprint.  So, the Client Survey User Story had to be revised to become multiple user stories in order to be able to accomplish parts of it within a sprint, starting with the draft of questions, all the way through follow-ups and long-term goal planning.  Scrum also requires that you prioritize each item so that you can pick out those items that will have the most value (weighted for how much effort it requires).

We incorporated 5 – 10 minute daily morning meetings into our routine, so that we could keep everyone up to date on what was accomplished, what was on the agenda for the day, and what issues were causing delays or “blocks”.

Revisiting, revising, rethinking

We had gotten started, but the first few sprints just didn’t go so smoothly.  Other things kept popping up and we weren’t getting those sprint items completed – but those “things that kept popping up” were really important tasks that couldn’t be delayed.  We realized that we really had to rethink and better prioritize what we actually put into our sprints and we had to leave room in our sprint schedules to address last minute priorities.  So we took a step back and documented our high level goals, and prioritized THOSE, as well.  Then we referenced the high level Goal in each User Story, so that we could better focus on the goals that were our top priority.

But how are we going to track our progress?

All of these user stories and goals have to be managed – and it won’t surprise you to learn that we chose policyIQ to manage the information.  In our follow-up blog post later this week (Using policyIQ to manage Scrum), we’ll show you how we implemented our Scrum process using policyIQ!

Some of you may also remember that our friends at Equinox co-presented with us last year to show our policyIQ clients how they manage their software development and IT projects using policyIQ and Agile.  Check out this recording to learn more about their process!

This entry was posted in Solutions and tagged , by Chris Burd. Bookmark the permalink.

About Chris Burd

Chris is the Vice President of the policyIQ group at RGP. She gets geeky about compliance and technology, and gets to spend every day working at the crossroads of the two. With policyIQ since 2005, Chris has worked with hundreds of policyIQ clients to implement technology and enhance their internal compliance environment. In past lives, Chris worked as a system implementation consultant, a e-commerce specialist, a customer service call center manager, and - for one short but memorable summer during high school - a machine operator on midnight shift in a plastics factory. In her free time, she spoils her nieces, reads too many books, and spends more time than she should taking photos of her cats. She's on a mission to visit the hometown of every US President - so far managing to get to 14. She would like to be a rock star when she grows up.

1 thought on “Using Scrum to manage policyIQ (Part 1 of 2)

  1. Pingback: Using policyIQ to manage Scrum (Part 2 of 2) | policyIQ Blog

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s