Monday, September 23 2013
Keywords: Agile, SCRUM, Database Development, SQL Server, Oracle, TFS, Process
Agile Database Development, Part 4 of 5
This blog is part of a series on Agile Database Development.
Find Part 3 of series here.
*) Lesson 17: Database Projects
Add “database projects” and “data warehouse projects” to your visual studio solutions.
Save each database object in its own script file. This is also a great way to maintain history in TFS or whatever version control software you use.
*) Lesson 18: Collaborate more efficiently with others
Drastically diminish broadcasting emails to QA, POs, PMs, and other team members. Instead communicate with them in more efficient ways such as actually getting up and going to see them (if you have the luxury of working close to them), or phoning them up, IMing them, teleconferencing with them etc…all these methods beat the dreaded email. Folks are growing allergic to email…99.9% of long emails are not fully read.
Face-to-face is the best, if possible.
*) Lesson 19: Keep SCRUM chit-chat to a minimum
Talk a little technicalities to others on SCRUM time, but nothing too elaborate. See them before or after daily SCRUMs to discuss details in depth.
*) Lesson 20: Sprint length matters
2 week sprints are the best…you won’t go off the right path for a while…you won’t lose precious time.
*) Lesson 21: local teams are best, if possible!
Local teams beat matrix system, or remote teams where members are scattered around the world. We used to take this for granted, but in today’s high-tech world it is becoming a luxury to actually have a team that is entirely working in the same building. Nothing beats face-to-face SCRUMs with no telephone or cameras!. Remote SCRUMs with cameras and headphones will also work…but obviously not as efficiently. Having said that, I have extensive experience working remotely, as I had done this for 9 straight years, and had become quite efficient at it.
I talk to you from experience when I say that your team will deliver more in an office where you work close to your team members…for 1001 reasons.
If users are located in different geographical locations: it's a challenge...make sure SCRUM and meetings are not during no one's lunch hours or not outside of one's comfort zone otherwise unhappy enemies you will make. Make sure to specify at which time you meet and to what time zone the time pertains so that there'd be no misunderstandings. Same goes for deadlines.
*) Lesson 22: design matters
A good design off the bat, and you will have less to change later on. Having said that, I see it often (very often indeed) that a project’s design phase takes several months…way too long. I believe that is unnecessary and in fact a waste of time. Even the best designs will not last forever. Do not be perfectionists.
*) Lesson 23: Allow for trial and error
Do not have users commit…do not have your developers guarantee a delivery time or a specific design pattern for every user story or feature...even the best among us need to refactor and/or to enhance their code on regular basis...even the most senior architects would amend and revise their original designs.
Written by Montreal DBA Team