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:
instead
of BREAKING THE DEPENDENCY! However, there are many, who really wish to break this ice.
- Immediately visible when he is not available
- Gradually visible to the developer when he feels technical and functional stagnancy
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 ....
2 Common Approaches & Why I don't like them much ....
1. PAIR PROGRAMMING
"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:
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
·
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
· 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:
· 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
·
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 :)
I hope you'd have found debatable CoMeD approach useful. Do share your queries & thoughts - Love/Hate, to make it better :)
