Click here to monitor SSC
SQLServerCentral is supported by Red Gate Software Ltd.
 
Log in  ::  Register  ::  Not logged in
 
 
 

SQL Sandwiches

Sqlsandwiches is a tool for me to communicate what I have been learning to the SQL community.

Can Scrum work for the DBA?

Agile! Scrum! Development methodologies! Sprint!


If you have a manager who reads any web page about being a manager, then you have probably heard about Scrum. Scrum development is very attractive from a manager or stakeholder's point of view. You get short bursts of development and can see results quickly.


With my experience, companies with no scrum experience who want to adapt this method search the web and find a scrum coach and then book 1-3 day sessions. Being in these sessions before, I know they are long and extremely boring.


Having said that though, I have seen scrum in action and think it works great for teams that do it right. If you have a dedicated team working on one project then scrum can do wonders for you. Even if you have a couple projects going it can work well with an experienced scrum master.


Being a DBA though, I find it hard to fit into scrum. I have been part of scrum teams developing some application but usually only brought on to write some SP's, create a package, or another smaller task. I end up sitting in on 2-3 hour sprint planning meetings and end up with a couple hours worth of work.


The other problem with a DBA and scrum is that a good chunk of the work that I get isn't planned a week (or 2) in advance.


"Database guy, I need access to server 2930dkdks. It’s holding up production"
"Are you the guy who gives me the reports? I need 10 reports by 1pm today!"
"Mind helping out with this query? I'm not sure why it's slow, I only use UNION ALL 10 times"
"Mind checking out that server? It's out of space"


I would love to tell all these people to wait till next sprint but then I would have a lot of angry co-workers complaining to my manager.


This is why I feel scrum might not work for DBAs. Sure, I could factor in 30-40% of my time into each of my sprints to take outside requests but what happens when I only get one user all sprint who needs help for 30 minutes? Or what happens when Joe the engineer deletes the wrong database on the wrong server in the middle of day and you have to spend the rest of the day fire fighting?


The other problem is that I'm not on a team of DBA's. I do dev work, I do admin work, and I do BI work. Whatever is needed from my co-workers and my company.

I love the idea of Scrum and thinks it works well for developers but not so sure it works for DBAs.


I currently manage my tasks with a to-do list and a backlog. I revaluate the priorities of my to-do list daily and if I finish everything I reach into the backlog until another request comes in. If the backlog is a bit bare, there are always improvements to be made to current systems.


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?

Comments

Posted by David C on 29 May 2011

We use agile methodologies, but the thing that makes our environment "interesting" from the DBA's point of view is that there are 3 of us (I'm the team lead, plus 1 senior, and one intermediate DBA), and 4 cross-functional dev teams, each working on a different schedule.  

So each of us sits on multiple teams - which is awesome fun when you have to attend double the number of daily stand-ups and scrums, planning sessions, etc, etc. :-)

The way we make it work (to the extent that it does) is that we're only available as resources to these dev teams for 50% of our time.  The other 50% is dedicated to our own daily business-as-usual work, as well as internal projects (e.g. reports, SSIS, server upgrades, performance improvements, etc).  So if a piece of work is going to take us 2 days to do for team-A, then we schedule in 4 days for it.

I'm sure this isn't ideal, but it works in our environment where we don't have a big enough team to differentiate between database devs, DBA's, BI analysts, etc.

Posted by Anonymous on 31 May 2011

Pingback from  Dew Drop – May 31, 2011 | Alvin Ashcraft's Morning Dew

Posted by andre.vella on 6 June 2011

"The other problem is that I'm not on a team of DBA's. I do dev work, I do admin work, and I do BI work. Whatever is needed from my co-workers and my company." ... that sums it up for me. You're not in a team and it will never work out well for you. I know what you mean ("long and extremely boring...") because I was a one-man team myself in my previous job. My solution at the time was to have a quick daily catch-up with the DEV team lead and the product manager in order to plan work accordingly. It did not "waste" my time and I felt it worked out better for both parties.

However, if you are part of a team, Scrum for a DBA does work out very well. If fully endorsed, it can help you carry out your work better and faster, and you'll probably find out it is not boring at all.

Posted by Saravanan Durairajan on 6 June 2011

Scrum can work for a DBA, if he has been involved right from the grass roots of the project, like from requirements to DB design .... developers are always part and parcel of the project and DBA's are usually called in when the code does not work.

the usual thing is ,"the production server has problem. Code works great in DEV & STG not in production". We have to drop all our project and tasks to fix it, with no idea of the db design. even if there is an issue in the design or architecture, the dba has to make it work.

And DBA has to know all about normalized database, to writing excellent reports to cube architecture and processing. He should be also able to move data or make a bad process work in a snap, so that he can be sent into the next fire. If the DBA is alone in the company, he should have no life.

Aarggh,

Posted by PaulHunter on 6 June 2011

Scrum is great for development, however what many are describing isn't development.  ORM's are the worst offender here.  If you let the app dev's design the db so it supports the object model rather than the business you'll get into trouble quick.  OOAD <> 3NF!  If a SQL dev is brought in early and integrated into the team then you have a good chance of making scrum work.  The more likely scenario is the db guy is involved late because the db built to support the object model doesn't or can't scale.  Here the dev isn't part of scrum because the role wasn't considered important enough.  I call this scrum-but.  It was supposed to be scrum, but [insert bogus reason here].  First, diagnose your situation, then recommend a solution.

Posted by mwfontan on 23 September 2013

Putting a DBA in a development scrum will only serve to bore the individual involved, and keep him from servicing other needs.  DBAs need to be available to do whatever is needed to service development and should not be considered a contributor to the design, which is the responsibility of the dev team.  The DBA simply needs to make the design work.  This is how the agile methodology saves time and effort for developers.  

Leave a Comment

Please register or log in to leave a comment.