Code For Me Dude - Breaking People's Dependencies in Agile Projects

If I consider product sprints as an evil, every agile team has Marvel superheroes (developers) who with their expertise, kill the evil and bring joy to the city (Stakeholders).  But what if Batman goes on a leave while a tension erupts in Gotham City and there is no one to save it? Call Super Man? Cool Idea! But what if Super man says “Unfortunately, I've no idea about how to help people in Gotham City!”. Sounds like you've heard this before?

“X is on sick leave today so we're blocked on a module”

“X would soon be going on a 10 days vacations, so do not plan tickets for next sprint”

“X has to leave early, but Y has a dependency on his task which would block Y”

Well, such phrases are common and become even more relevant when Product Manager/Team Lead start loving the quick  response time they get from a developer working on same sub product/module for a relatively longer period. But the negative consequences are: 

• Immediately visible when he is not available 
• Gradually visible to the developer when he feels technical and functional stagnancy

 However, we all still love to get back to the comfort zone   instead of BREAKING THE DEPENDENCY! However, there are many, who really wish to break this ice.

This article is about a technique called "Code for Me Dude" which is a team configuration approach such that there is more knowledge sharing and hence lesser dependencies. Before I jump to my "Code for Me Dude" approach, following are a few popular options available for breaking dependencies:

2 Common Approaches & Why I don't like them much ....

1. PAIR PROGRAMMING

Wiki has an excellent definition for this, so I'm avoiding a few keystrokes.

"Pair programming is an agile software development technique in which two programmers work together at one workstation. One, the driver, writes code while the other, the observer or navigator,^[1] reviews each line of code as it is typed in. The two programmers switch roles frequently."

 Well, sounds nice. Few advantages besides saving electricity are obvious:

·         Better brainstorming, realtime reviews and possibly better estimations

·         Two people gain technical/functional knowledge for same module

With aforesaid benefits, it is indeed pretty tempting to opt for Pair Programming. But watch for a few cons too:

·         Effort involved in a decent code review in general takes 10-50% of the time involved in development. This means, even in worse case, you may loose 50% of developer’s development productivity

·         Both developers work on same module. This means, they gain substantial knowledge for a module but they are still not capable of handling another module/product when there are multiple mini projects running in parallel.

·         There may be situations where developers are not at ease working together OR are in too much of a comfort zone. Either scenario would impact development.

·         Developers may get bored working on same module for long

2. SHUFFLING

As the name suggest, swap developer X (working on ABC) with Y (working on PQR). Easy, isn’t it! I know you said “Yes”! Benefits:

·         You can break dependencies at a bigger level – module or even products.

·         Can help when developer are bored working on a module/product for long

But, it may not be that easy to implement as it sounds:

·         In a dynamic environment, the biggest question always is “When should we plan a swap”. I'm again talking about the comfort zone. Likely, you’d never do that.

·         Swapping developer means big effort/cost involved in deep Knowledge Transfer (KT)

·         Developers who had excellent response time, would all of sudden have a fall in response time (which is fine as long as Business understands that..ahm!ahm!)

·         Developers may lose the expertise they had for previous module being out of touch

     3. I SUGGEST “Code for Me Dude (CoMeD)” 

This is kind of Hybrid. It may already be followed somewhere, may have a different name, but it came as a original thought when a client wanted to break the dependency but had aforesaid concerns. 

WHEN TO USE IT?

• different products under same group sharing a common team.
• there are more-or-less technically equivalent people working on different modules/sub-products using common or specialized tools.

In this approach, for a particular project/module, one developer is assigned as a Primary resource while another is assigned as a secondary resource. While, Primary resource is an expert in that area, secondary resource is fairly new to the product (who is actually an expert in some other area). Thinking, what’s new in it? There's a big twist!

THE TWIST!

Primary developer do not spend more than 20% of his time in the module/project of his expertise while a Secondary developer accompanies him, who is fairly new to the system but spends 80% of his time in it.

WHY SO?

If you have primary developer for 80% on the same module, he’d always continue to work on complex & big tickets while secondary developer would get hand-on experience only for smaller & aesthetic tickets. So, one day, when primary developer is on leave, you’d find you didn't break the dependency ice well and actually you get back to square one.

Note - At the same time, Primary Developer would be a Secondary Developer for some other area which is still new to him while Secondary Developer would be acting as a Primary one for an area of his expertise. So, in a nutshell, a resource spends 80% time to leverage his area of expertise and rest 20% in guiding a new person in his area of expertise.

You don't need to be doing this all the time. But when you find a need for some dependency break, this can be effectively used to start with.

WHY THE NAME "CODE FOR ME DUDE?"

For effective utilization of CoMeD, it is highly recommended that ownership remains with the Primary Resource for the tickets which are implemented by Secondary resource. It is like Primary Resource asking Secondary Resource "Could you code for me Dude? This will bring up at par and help everyone in my absence".

Let’s see how Benefits of “Code for me dude” outshine the cons of aforesaid approaches.

BENEFITS

·         Nothing can be better than hands-on way of learning. Secondary developer will get at pace with primary developer much faster and with lesser formal theoretical KT
·         Productivity is much better than Pair Programming

·         Primary developer will retain the expertise of existing product. 
·         Having ownership lying with Primary Resource brings following advantages:

o    Primary developer will learn better interaction and communication as he needs to get his code done by secondary developer (That’s why “Code for me dude”) and also update business about status. This will groom leadership skills.

o    Better review as Primary developer would ensure code is written as per existing practice, being responsible

o    Business and Product Managers would continue to have a comfort zone as they’re still interacting with same developer.  Though in Standups, secondary developer should be providing status updates.

o    Once the secondary developer is at par with Primary developer,  he can take full responsibility as was initially held with Primary developer

·         Shuffling is somewhat easier this way and can be a continuous practice

However, this is challenging for developers (actually they might love it if they were always fascinated by work/tools their peer is doing/using). This satisfies the technical appetite of developers. At the same time, it breaks the ice of dependency bring peace of mind to product managers.

I hope you'd have found debatable  CoMeD approach useful. Do share your queries &  thoughts - Love/Hate, to make it better :)

CodeProject