Siolon

Engaging the Entire Development Team

Before I left col­lege the only expe­ri­ence I had in soft­ware devel­op­ment was as a one-man team. I did all the design and back-end devel­op­ment. There wasn’t a con­flict of inter­est between designer and pro­gram­mer, because they were both one per­son! As I left col­lege and got into the “real world” I found that it was impos­si­ble to do large-scale soft­ware devel­op­ment by one­self. All of the sud­den there were infor­ma­tion archi­tects, pro­gram man­agers, user inter­face experts, data­base admin­is­tra­tors, tech­ni­cal writ­ers, and on and on.

I came to real­ize the value of spe­cial­iz­ing in one field. For instance, it would be counter-productive to man­date a DBA to learn Pho­to­shop inside and out, and like­wise it would be counter-productive to have the UI per­son learn how to know how to write every vari­a­tion of data­base indexes. But I also saw the lack of knowl­edge that each had even of what the other team member’s respon­si­bil­i­ties were that led to inef­fi­cient meet­ings, mis­com­mu­ni­ca­tion between clients (espe­cially in terms of require­ments gath­er­ing), and over­all it lead to a “that’s not my job” men­tal­ity that hurt the over­all pro­duc­tiv­ity of the team.

The The­sis

I believe we need address the lack of com­mu­ni­ca­tion between the team mem­bers by increas­ing col­lab­o­ra­tion and at least a gen­eral knowl­edge of what the other is doing. If the pro­gram­mer knows that the UI per­son is very con­cerned with Web stan­dards then they can address that while he designs (among many other exam­ples). All mem­bers of the team address the same client with the same require­ments, and with knowl­edge of the var­i­ous aspects of the SDLC the client can receive the max­i­mum amount of value for their investment.

The arti­cle is bro­ken up into exam­in­ing the role and duties of the project man­ager and the devel­op­ers. Both have unique respon­si­bil­i­ties in order to ensure that the effi­ciency of the team is what it can be.

The Respon­si­bil­ity of the Project Manager

The respon­si­bil­ity of mak­ing this work falls on all mem­bers of the team, but the project man­ager (project lead, tech­ni­cal lead, etc.) is the one that has the author­ity to del­e­gate who will work with who and for how long. There should also be a strong impe­tus for this per­son to embrace this ide­ol­ogy, because when con­flicts arise between devel­op­ers or between devel­op­ers and clients the project man­ager is the one usu­ally respon­si­ble for resolv­ing the conflict.

By del­e­gat­ing devel­op­ers to have a work­ing knowl­edge of what the other mem­bers are doing through the soft­ware devel­op­ment and main­te­nance cycle then all mem­bers are able to offer con­struc­tive crit­i­cism to one another and help in a time of need. It is a great asset in the tool­box of deliv­er­ing qual­ity software.

Reduce Devel­oper “Pos­ses­sion” of Code
I was sit­ting in a meet­ing, and when a cus­tomer bug request came up in a cer­tain mod­ule then we auto­mat­i­cally pointed to that one per­son who designed the mod­ule. The men­tal­ity behind it keeps other peo­ple on the team from double-checking the code and able to help each other of bug fix­ing and future devel­op­ment. Kent Beck, the pop­u­lar pro­po­nent of eXtreme Pro­gram­ming (XP) (which I nei­ther endorse nor dis­cour­age) says the fol­low­ing on “col­lec­tive ownership.”

“One of the effects of col­lec­tive own­er­ship is that com­plex code does not live very long. Because every­one is used to look­ing all over the sys­tem, such code will be found sooner rather than later. And when it is found, some­one will try and sim­plify it. […] Col­lec­tive own­er­ship also tends to spread knowl­edge of the sys­tem around the team.” (Kent Beck. Extreme Pro­gram­ming Explained: Embrace Change (2nd Edi­tion) (The XP Series). New York: Addison-Wesley Pro­fes­sional, 2004.)

Regard­less of whether one uses XP or another SDLC, the con­cepts intro­duced are a good start­ing point to increase the amount of com­mu­ni­ca­tion between team mem­bers, increase pro­duc­tiv­ity, reduce errors, and deliver higher lev­els of cus­tomer satisfaction.

Facil­i­tate Team Brief­ings
We all love to talk about what we’re pas­sion­ate about; so why not use that to the advan­tage of your team? I work on a team where the project lead encour­aged us to give a brief­ing on a new tech­nol­ogy or cer­tain aspect of their job that would ben­e­fit other mem­bers of our team. Let’s use an example.

The user inter­face designer is con­stantly frus­trated why the DBA and devel­op­ers just don’t “get” web stan­dards. It leads to con­flict, because the devel­oper is solely con­cerned about the func­tion and not the form (in an extreme exam­ple). Well, why not let that designer brief the team on the value of web stan­dards? It would also be help­ful for that indi­vid­ual to out­line best prac­tices so the appli­ca­tion has both max­i­mum form and func­tion. Often mis­com­mu­ni­ca­tion hap­pens over very small issues, and by tak­ing the time to clearly out­line a con­cept then the prob­lem often goes away.

In fact, recently I gave a brief­ing to my devel­op­ment team intro­duc­ing CSS and CSS best prac­tices. Months of frus­tra­tion on my part was alle­vi­ated as many mem­bers of the team started to see the busi­ness value of sep­a­rat­ing pre­sen­ta­tion from struc­ture. We are now con­vert­ing our old table lay­out to a CSS-driven layout.

Man­ag­ing Many Egos
Let’s face it-designers and pro­gram­mers have egos, and not just small egos but large egos. Every­one has their own phi­los­o­phy on how devel­op­ment should be done; this is nor­mally a good thing that brings vari­ety and many per­spec­tives, but some­times it can also be a hin­drance when try­ing to empa­thet­i­cally com­mu­ni­cate with team members.

How many tech­ni­cal meet­ings have we all been in that seemed to go on and on and seem­ingly accom­plish noth­ing? It seems like we spend most of the time debat­ing philo­soph­i­cally on the best route which is per­pet­u­ated by our own indi­vid­ual ide­olo­gies. This can, and should be, alle­vi­ated by real­iz­ing that what’s best for the appli­ca­tion isn’t always how we feel it should be.

The project man­ager has the added respon­si­bil­ity of ensur­ing that these debates don’t get out of hand by effec­tively man­ag­ing the con­ver­sa­tion and ensur­ing that every side is heard. Ulti­mately, every busi­ness deci­sion that is made must be made by some supe­rior who weighs the options and chooses the best. A man­ager that is open yet firm in mak­ing deci­sion does won­ders for mov­ing devel­op­ment along.

The Role of the Developers

The project man­ager can do quite a bit to ensure to ensure that the team works in an opti­mized state, but ulti­mately it comes to the peo­ple that com­prise the team-the devel­op­ers. I want to give a few sug­ges­tions for the devel­op­ers to ensure that cohe­sive­ness is improved.

Every­one Should Test Every­thing
A great way to get team mem­bers to get involved with the entire project is to not rel­e­gate test­ing to indi­vid­ual projects or a sin­gu­lar tester. By involv­ing all mem­bers of the team in test­ing helps ensure that the qual­ity of the appli­ca­tion will con­tinue to increase. I am con­tin­u­ally amazed at how mem­bers of my devel­op­ment team don’t even know how to use many aspects of the very appli­ca­tion they develop. It is often the result of the “pos­ses­sion” of code prob­lem address above.

Improved Knowl­edge Man­age­ment
A good devel­op­ment team should be the most expe­ri­enced and con­cerned about knowl­edge man­age­ment. As the appli­ca­tion matures then it becomes more and more nec­es­sary to ensure that cor­rect and com­plete doc­u­men­ta­tion is retained (although don’t wait to start). The great knowl­edge man­age­ment chal­lenge of cap­tur­ing tacit (un-written) knowl­edge is crit­i­cal to address when you’re in a devel­op­ment team. As devel­op­ers come and go the need to be less reliant on one or two devel­op­ers is extremely impor­tant. You should, at least in the­ory, have enough doc­u­men­ta­tion to move devel­op­ers around and if nec­es­sary to replace.

Fos­ter­ing Mutual Respect
Aretha Franklin had the idea when she said: “All I’m askin’ / Is for a lit­tle respect”. We all love to know that we are respected by our peers, but it only comes about when we extend it to oth­ers. That whole Golden Rule idea is very applic­a­ble in this sit­u­a­tion. When devel­op­ers cre­ate an atmos­phere where we respect one another and each other’s con­tri­bu­tions then more effi­cient com­mu­ni­ca­tion is likely to take place.

In Sum­mary

There are many ways to engage the entire devel­op­ment team, and the respon­si­bil­ity lies within the man­agers and the devel­op­ers. It is truly a trial and error effort, but if you and your team seek to improve in the areas above then you are more likely to deliver a qual­ity prod­uct to your cus­tomers and improve pro­fes­sional satisfaction.