Database.ca SQL Server Blog

My Blog

Monday, September 09 2013

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

Agile Database Development, Part 2 of 5

The blog is part of a series on Agile Database Development. Find Part 1 of series here.

 

*) Lesson 5: Training & Certification is of outmost importance
 
Ideally your Company should provide Agile Training to everyone who's new to this process. Providing this training is more important than providing technical trainings, as it has a much wider impact in the long term. If technical training are not being provided due to low budget, then it is still not the end of the world as folks can still learn a lot by simply searching the Net. There's a wealth of information out there on all technical topics. But changing a process, moving from Waterfall or any other process (or no process at all) to Agile is not easy…it’s a big change…and people do not like change. You also do not want each person to learn Agile his or her own way...there could be conflicts.
 
When some team leads, managers, PMs and POs are introduced to Agile, the insecure and micro-managers amongst them become too defensive at first…and some will even never let go of that fear. I have seen those who saw the new process as a major disturbance in their way of work and they felt that they would be at the grace of developers and thus lose some of their power.
 
Proper training helps clear misunderstandings. I have seen people who were great skeptics before receiving their training, and all motivated and optimistic about Agile afterwards.
 
Also make sure your SCRUM Masters are all trained & certified.

 

*) Lesson 6: Consistent source of info and training
 
This one extends on lesson #5: If possible, try to have everyone trained by the very same trainer and/or other sources of training. No two trainers are alike. And having a group trained and certified by one person and another group by another person could be the beginning of a long series of misunderstandings and “my system is better” , and "this is not the real Agile" discussions.

 

*) Lesson 7: Keep the motivation high
 
Best results occur in groups where everyone is motivated and excited about Agile. It wouldn’t work unless everyone in the team is actively contributing to bettering the process and is eager to gradually learn and improve.

 

*) Lesson 8: Be patient
 
Adapting it and mastering it should be very gradual: if you were doing Waterfall yesterday then don’t expect 100% agile today...it takes many months...in some groups the fruits were picked only after one year of gradual enhancements…It’s all good as long as your team is getting gradually better by time. Don’t be perfectionist and have high expectations too soon. Keep encouraging everyone who is learning and is showing signs of motivation.

 

*) Lesson 9: The misunderstood multi-functionalism
 
One wrong expectation I’ve already heard of would be "Everyone in the agile team must be able to replace everyone else in the team, if need be, we are multi-functional".
 
A multi-functional team is a team that is self-sufficient and doesn’t need to reach outside and outsource majority of its usual requirements. A good example would be a group who has all the following expertise covered: GUI, Middle-Tier, Database, Testing, and Builds.
 
Ideally and only if there are enough resources, a minimum of 2 persons in each team should be quite knowledgeable in any given subject, so that one could cover the other during vacations and sicknesses, and also one could lend a hand to the other one when need be. Tasks could also be rotated between them.
 
Certain tasks fall into the gray zone, and are perceived as the ‘boring’ tasks that no one wants to do; therefore they could be rotated between the team members. An example is Builds, InstallShield, different kinds of Tests, documentations, code review etc.
 
It is very good and positive that all team members participate and create database objects. There should however only be one database expert in the group, and he/she must code review other folks’ database work, to make sure that all work done by different developers work well together synergically. A stored proc written by programmer A, could look and work fine by itself. A second stored proc written by another programmer (B) could also look and work fine and pass all unit tests, however checking both of them in could create new bugs, security holes, locks and deadlocks or major performance flaws.

 

 

 

 

 

Written by Ramin Haghighat