Database.ca SQL Server Blog

My Blog

Monday, September 30 2013

Keywords: Agile, SCRUM, Database Development, SQL Server, Oracle, TFS, Process

Agile Database Development, Part 5 of 5

This blog is part of a series on Agile Database Development.
Find Part 4 of series here.

 

*) Lesson 24: Trust those you work with
 
Have trust in your team by default, both in their expertise and their maturity level. It will alleviate lots of stress and will make you a happier colleague. A friendly team delivers more robust code, faster. Don’t micro manage the team and mind everyone’s business or be condescending toward them. Forget the little problems and annoyances…we are all human, no one’s perfect…we could all have a bad day…and any of us could lag behind in certain expertise.
 
If however you feel that a specific individual’s knowledge level or behavior is a major problem: try to solve it ASAP. A rotten apple could turn the whole batch rotten. For Agile to work perfectly, the entire team needs to be excited, motivated, happy and functional.

 

*) Lesson 25: Debug your stored procedures right from Visual Studio
 
Saves lots of time and pain and helps create robust trustworthy code. I have a couple of articles on this site on how to get this done, for Oracle as well as SQL Server.

 

*) Lesson 26: Enjoy non-working moments with your teammates!
 

  • Eat lunch all together…outside of company…in a mall bringing your own meals…or in a restaurant
  • Every Friday bring a box of donuts to share with your colleagues!
  • Go to Cinema with them
  • Have gaming nights with them
  • Do not allow that the topics of religion or politics be brought up during working or non-working hours…no 2 people agree on these…these topics will always hurt someone’s feeling
  • Do not get emotionally involved with a colleague…there are millions of singles out there…get someone else…these things create lots of stress and tension at work and not to forget your entire attention span…

 

*) Lesson 27: Do not fall into the ‘us and them’ game.
 
Work closely with QA, Product Management Group, POs, your manager, and any one else outside of your team. Do not see them as a threat, enemy or a boss. Maintain friendly but professional relationship with all of them. You are all working for the same company, for the same cause…do not start ‘us and them’ kind of rumors…if you feel like someone’s actions or words is not profitable to the company: go see them face to face and express it out.

 

*) Lesson 28: Work items: don’t focus on tasks…focus on user stories
 
Put most of your emphasis on user stories and features…you don’t have to create each single task under each user story and put the correct amount of hours taken to do it etc…that’s micro management. Focus on user stories, are all the acceptance criteria clear? Is the user story started? In progress? In testing? Done? Micro managing tasks takes lots of time and resource and discourages many colleagues.

 

*) Lesson 29: Work items: don’t be too exigent with user stories
 
Do not give your PM/PO extreme hard time because you feel the user story is not complete and is lacking acceptance criteria. Instead, get up your chair, and go see them and work with them closely to try to brain storm and complete this user story. Help them with that task, don’t just complain about ‘them not doing their job’…tag team with them. You are all working for the same company and cause.

 

*) Lesson 30: Use a physical board to display your user stories
 
Physical boards of any kind beat digital ones by far. Do not show your colleagues a report from TFS with some graphs...That is so not motivating and just boring...
 
Show items at least for this sprint…but if you have a bigger board you could even stick the back log for the next 2 or 3 sprints to it! If you have a giant board, I’d recommend something like this (not every single column could apply to every single group, I understand):

 

Agile, SCRUM, Database Development, SQL Server, Oracle, TFS, Process

*) Lesson 31: Transfer knowledge!
 
You are a DBA...your email signature says that you are a 'senior'...One cannot call himself a senior because he is old! Or because they have been in a company for 20 years! Being a senior in something means that you have come to the expertise and maturity level where you feel comfortable with transferring knowledge out to those who seek and need it.
 
You've been pulling...now push info out.
 
Some of your teammates do not know database work as good as you do? No problem. Do not complain about them around the coffee machine. I'm sure you don't know C# as good as they do! Teach' em DB instead!
 
Best way to do it: reserve an hour every several weeks...ideally in a training room if possible...with a projector and/or a computer...bring a box of donuts...or if your team's budget allow a few box of pizzas...and teach them...one or two light subjects at a time...focus primarily on topics that do help the dev group now or in a foreseeable future...obviously teach them the fundamentals first...but teach them conservative and defensive database programming techniques before all else...after all it's AGILE...you need robust database code!

 

 

Written by Ramin Haghighat