SCRUM, Source Control and the SQL Server Developer (Part 1)

(If you’re just visiting me from SQLServerPedia, thanks for stopping by!)

I recently responded to TJay Belt’s post about his Release Management process, and thought it would be better to fully explain our development cycle here.   Although I come from a DBA background, I currently work on the development side of the house in our enterprise.  About 6 months ago, we made a decision to adopt Scrum as our development process, and for the most part, it has greatly simplified our release cycle.  I’m planning on this being a two part post; this part will focus mostly on what Scrum is, and how we use it in our shop to release database changes, and part two will focus on how we use source control within the Scrum methodology.

You can read the Wikipedia article about Scrum, and it sums things up far better than I can; however, what I want to contribute to the discussion are some guidelines for implementing the scrum process.  There are two basic goals to scrum: first, you want to increase visibility into the development process so that customers (the product users) know what to expect and when to expect it, and second, you want to organize your deliverables around measurable increments (sprints have daily scrums, which identify progress and impediments).  It’s important to understand these two goals in order for you to understand why we implemented the rules we did.  Please note that these are our rules as of this date, and they may change, and your shop is free to change them as you need.

1. The Sprint will last 4-5 weeks.  Most scrums talk about Sprints lasting x number of days, but we broke it down into weeks because of the following constraints:
   • We have certain processes that begin at the beginning of the month, and some that begin at the end of the month.  We wanted to be sure that our Release Date always fell in the middle of the month, and
   • We wanted to have a consistent day of release.  We’re a 24x7x365 shop; for our business, most installation is best done in the middle of the week (so we can quickly identify any adverse affects).
2. We wanted to minimize the number of releases.  Most issues can wait 4-5 weeks for complete development, even though the Product Users obviously want it NOW!!!  To accomplish this, we had to deal with the issues of units of work, and emergency patching:
   • If an issue is an emergency, and cannot wait until the end of the Sprint for release, we will release a patch on Wednesdays.  In our model, patches are discouraged, but if they have to happen, they at least happen on the same day of the week as the regular sprint release.  This ensures that everyone affected knows when patches may be implemented (and when to expect downtime).
   • In the scrum model, a Product Backlog Item (PBI) is a prioritized unit of work; a Sprint Backlog Item (SBI) is a unit of work that is accomplished during the sprint.  We enforce a hierarchy in our shop; PBI’s are composed of SBI’s.  We do not release partial PBI’s; all of the child tasks (SBI’s) for a given Product Backlog Item MUST be completed before we release the code into production.  If some set of SBI’s is required for a given release, we may split the PBI into two in order to accomplish this goal.

As a database developer, most of work is at the core of many of the changes; there are few PBI’s that do not involve some sort of change to the database.  What we’ve noticed is that I’m often in demand at the beginning of the sprint, but my time consistently frees up toward the end; to help shift the burden a bit, we often stub out a dataset for the application (i.e., the app developers will dummy up a local dataset as opposed to making a stored proc). This is useful for two reasons; it delays their need of my services until later in the sprint, and it also defines what they want the output of a stored proc to look like.

In the second part of this article, I’ll discuss our source control arrangement and how it maps to the sprint.