Scrum for the DBA?

Question

I really wanted to find out what people out there think about Scrum for a SQL Server Production DBA.

I have seen one article (http://www.sqlservercentral.com/blogs/sqlsandwiches/2011/05/29/can-scrum-work-for-the-dba/) that talks about this, but this is from 2011. There might be things and perspective changes that happened since 2011 to the present 2017 situation.

Here's something that could help you provide you some insight to the type of situations that the production DBA deals with on a usual basis:

1.Schema/Data Promotions from Test Servers to production servers.

2.Monitoring Servers/Databases continuously throughout the day(Checking the server for space, Memory,CPU etc)

3.Backups/Restores/Disaster Recovery Planning and Implementation.

4.Installation/Management/Monitoring/Usage of DBA Tools like Idera, Redgate, Different versions of Visual Studio's/SSMS's etc.

5.Creating/Scheduling/Monitoring Jobs/SSIS packages, SQL Scripts.

6.Sometimes Creation/Deployment of SSIS packages/SSRS reports/SSAS Cubes.

7.Maintenance/Patch Management/Upgrades/Migrations of SQL Servers etc.

How does all of this fall into Scrum and how to deal with it?

Scrum is being implemented as a new thing from the management side and points are being assigned for everything that is being done. 1 point is being equated to 1 hour, 1/2 point is 1/2 hour and so on. So everyday the DBA is being asked what is being done in the daily scrum and lets say a Database is being backed up, the manager(who is also a scrum master) says: All you are doing is setting up the script and letting the backup go. You aren't doing a thing until the backup is done. What should the DBA do? So no points for monitoring the servers/databases since they are a 24*7 job or rather a full 8 hour job for the DBA.

In scrum/sprint, is time really associated with Fibonacci series(0,1,2,3,5,8,13,21 and so on) points associated with time in someway or the other? From what i have learned this is something to do with complexity and never to equate with time, but is that what management does anyway?

But what really is happening in the name of scrum is that, we are being asked to provide the story, estimated/actual points/time for the story, time started, time completed, and details as to what was done to complete the story. Almost the same as this!! (Is Scrum a status report meeting or a developer meeting?)

Is this Agile/Scrum. What is it?

• How Does scrum fit in for the production DBA in this way?
• Are you a DBA that uses scrum?If so, how do you make it work? If not, how do you get around the manager who loves scrum and insists that you be a part of it?

Answer 1

Is this Agile/Scrum. What is it?

No. This is Command and Control dressed up as Scrum.

How Does scrum fit in for the production DBA in this way?

Scrum is for work that's difficult to estimate but shares a common goal that can be worked towards. What you describe is more of a collection of distinct tasks that are either scheduled or completely ad-hoc. Something like Kanban would be a much better fit.

Also sooooo many scrum mistakes:

points are being assigned for everything that is being done. 1 point is being equated to 1 hour, 1/2 point is 1/2 hour and so on.

Points in scrum are not assigned by management but by those who do the tasks. Also points have no translation to hours. Ideally they'll end up having something of a correlation.

So everyday the DBA is being asked what is being done in the daily scrum

This is not a daily scrum this is a status report. A daily scrum is for the team to sync up and decide/determine/share what is going to be done. It is for the team to communicate problems to the scrum master. It is for the benefit of the team, not anyone else.

the manager (who is also a scrum master (no he is not)) says: All you are doing is setting up the script and letting the backup go. You aren't doing a thing until the backup is done. What should the DBA do? So no points for monitoring the servers/databases since they are a 24*7 job or rather a full 8 hour job for the DBA.

He's not entirely wrong on that. Much of this work can be automated. Still you have to schedule tasks by the effort required in your current situation not the effort required given maximum automation. Also a certain amount of time needs to be calculated for context switching and whatever manual steps do remain.

In scrum/sprint, is time really associated with Fibonacci series(0,1,2,3,5,8,13,21 and so on) points associated with time in someway or the other?

What you are describing is an aid to help estimate backlog item points. The idea of using Fibonacci numbers is that they help demonstrate the larger uncertainty inherent in estimating larger tasks. It is not necessary to do it like this IF you understand that higher level estimates are less reliable and that a large task of X points most likely will not break down into N subtasks with a total of X points.

But again. These are points not hours! Estimating in hours conveys a false accuracy to the uninformed. People are generally bad in estimating absolute values like hours, but management is really good grabbing onto them. People however are much better at estimating relative values (ie. is cleaning your apartment more or less work than cleaning your car?). The predictive power of scrum does not stem from accurate estimates but from consistent estimates and the ability to compare past estimates with actual outcomes.

Answer 2

Sounds like a lot of red flags for me. As Professional Scrum Trainer I read quite a few scary bits. To start:

Yes, Scrum and DBA work can go well together.

One, estimation.

At the Sprint planning work is planned and optionally estimated. Not something you do during the daily scrum. And while relative estimation techniques are useful for forecasting, they're kind of useless to plan actual work, especially if you clearly have an idea of the amount of time taken.

Looking at recurring tasks and making sure they're part of the sprint's plan is something which fits in Scrum, it would be done during the sprint planning. For these things, especially when the work is well known, I'd just subtract it from your capacity for more challenging tasks.

Hourly estimation directly related to story points is a clear no-go area, especially if there is a direct correlation from 1 point = 1 hour. There's lots of documentation on Story points, so I'll leave it at that.

Two, daily scrum

The daily scrum is for tracking progress towards the goal of the sprint and for planning the day to come. Not for "scoring point", I wouldn't care how many points something is worth. If your work for the next day is planned, there is nothing in the way of achieving the Sprint goal and you feel you are productive, that would be the most important.

It's also a moment for the team to work together to come up with a plan for the next 24h. Not for a moment to report status to a manager. The manager can track the progress of the work through visualizing it and through tthe sprint review at which point in time the work is demonstrated and reviewed. In your case you'd rarely directly demo your work, it should be evident as part of other things landing on the environment or through the solution of problems that impacted users of the environment.

Three, the nature of the work

The way your role as a DBA is described above is quite traditional. Promoting schemas between environments is something that can be automated quite well.

Lots of monitoring can be configured to trigger alerts, not requiring a lot of manpower to actually perform the task of monitoring. The time required to expand drives and allocate resources can be automated or making sure you more space allocated when you expand is an easy way to reduce the overhead of these kinds of jobs by reducing their frequency and optionally limiting their impact.

The act of backing up and restoring is something which can be configured on a schedule. Manual acts of backing up or restoring are something which can often be delegated to other members of the team as well and may not require the work of a DBA. Same applies to rolling out new tool versions, putting the installer on a share and either signalling team members to upgrade when convenient or using remote distribution techniques can easily distribute these things to desktops, server etc.

How to proceed

Try critically looking at the work that can be automated or can be delegated. Spend your time on the work that is actually complex and requires your specific skills. Work with other members of the Scrum team to ensure they are able to perform many of the less complex work.

Use the retrospective to analyze your work and the work others perform and see where optimization is possible.

Work with the team to get rid of the need to "score points", scrum isn't about doing as many tasks as possible, it's doing as little as possible to get the most work done.

Tricks to combine operational work with development

Teams that have more operational work on their backlog often keep a Product Backlog and an Operational Calendar. The product backlog contains work that occurs because new features are deployed or changes are made to the environment, issues detected from recurring inspections may end up on the product backlog for investigation and solving. The operational calendar contains all the work that occurs on a schedule and can be planned way in advance.

Other teams combine Scrum and Kanban. New feature development and larger changes are planned through the product backlog. Recurring work is mostly automated and incidents are treated through a "priority lane" which uses kanban and isn't planned at the start of every sprint. Over time the team will learn how much time needs to be reserved for ad-hoc work. This way of working steps away from recurring tasks and calendar based long-term plans, it takes on the work as it happens for some of the work. Other work is ordered throught the product backlog and the team's velocity can be used to forecast likely points in time when this work is taken on (in which sprint).