Nine ladies don’t deliver a baby in a month.

While estimating migrating our persistence layer from server-side encryption to client-side encryption, my team estimated our project will require 60 developer weeks. The team created a detailed plan for each milestone and estimates for each, giving a high confidence date for each project. And then stated with multiple developers we can reduce the total time. Which obviously makes sense, when I asked so with two developers can we deliver it in 30 weeks, and three in 20 weeks. Some of my team members agree with visible hesitations on their faces. As theoretically 60/2 is 30 weeks and 60/3 is 20 weeks, so their engineering brain agreed but experience struggled with that answer. So, we agreed 30 weeks is not the answer, and I asked what would happen if I put two people on this project, or even three, my engineering lead struggled with the answer in coming up with an estimate. He asked for an additional week to determine that level of detail to conclude what will our expected delivery time.

While the above scenario is common, but often unanswered, and my team and I struggled with this very question i.e., can nine ladies deliver babies in a month. As business and project space become more ambiguous, identifying details of each deliverable and surrounding complexity often impacted our project plans and delivery windows. We heavily relied on cushions and ensured the team had necessary time to weed out complexity while meeting project timelines.  But even after baking in cushions, the team was up against the timeline and barely delivered projects or needed few more days near the end to deliver big projects.

While, as I expect last minutes delays and last days push is part of our delivery experience, I wanted to take an opportunity to document some observations and identify learning opportunities for future self.

Why multiple engineers don’t necessarily double the speed of delivery?

Cost of Increase in Collaboration (a double-edged sword):

The obvious part I missed while adding multiple engineers on the same project is that multiple engineers come with cost of increase in collaboration. Keeping multiple engineers equally aware of project space required the engineers to share context, ensure each task is detailed that enable the other engineer to effectively deliver on that task independently. Creating benefits of better detailed documentation, while maintaining each engineer on the same page requires more communication, and sometimes rework due to non-alignment. And, as of right now I have never accounted for a collaboration multiplier while adding multiple engineers.

Is Divisible:

When dividing projects tasks, I often miss can I really assign a task to multiple people at once. If all tasks can’t be assigned to multiple people, how many tasks can only be done by a single engineer at a time. And, if each project such as design, launch coordination, security reviews are singleton tasks, how do we bake them in our planning. Historically, long term projects will still have up to 20 percent of task that require individual to derive them in the beginning, and post implementation, up to 10% of a project estimate time i.e., an individual to coordinate launch and release efforts with multiple stakeholders. Leaving only 70% percent of time for implementation that can be parallelized between multiple engineers. While 70% percent tasks can be parallelized, it does warrant a close analysis especially for short term projects and 70% percent parallelization between multiple engineering will come with the cost of collaboration highlighted before.

Estimate Accuracy?

My team that does a very detailed job during design has figured everything about the implementation, so why we are still falling behind. When we discussed this among our team, we realize we often do great job in reviewing documentation and have a great idea what we want to implement. But engineering components much like life don’t behave exactly how we originally estimated. Additionally, each engineers bring their experience that changes the implementation from the original design. Such variations and challenges during implementation continue to require us to add some percentage of cushion to our original estimates to ensure the team has the necessary time to recover from any delays. I generally prefer to keep up to 20% to account for unplanned off days, sick days, re-work in implementations, and any technical delays.

Project timeline estimates with risks listed above:

·       Estimated dev effort: 60 weeks.

·       Projected Dev effort: (60 weeks + 20% of 60 weeks) i.e., 72 Weeks

·       Projected Single Dev effort: (20% of inception i.e., 72 weeks: 14.4 Weeks + 10% of launch coordination i.e., 72 weeks: 7.2 weeks:  22 Weeks (14.4 weeks + 7.2 weeks))

·       Projected Divisible effort: (70% of 72 Weeks) = 50.4 Weeks

·       Number of projected engineers: 2

·       Cost of collaboration (TBD by team: in my team: .2): (50.4 *.2)/2 = 5.4 weeks

·       Total Project Divisible effort time (Estimated Effort + total cost of collaboration): 25.2 + 5.4 = 30.6 weeks

·       Total Projected time to deliver: 30.6 + 22 weeks = 52.6 weeks (round to 53 weeks)

What did I miss in the above timeline: Unplanned long vacations, team attrition.

  

Coffee Place with Super Chargers

What one needs on highway is place to drink coffee and in electric car world? Super Chargers. Tesla is indeed doing good job by bringing entertainment into the car, but coffee places like Starbucks could do much better job in charging car's while entertaining coffee requirements for customers. The tribal like development of electric car owners and coffee drinkers could add extra revenues to coffee sellers shares. I a

Additional 30 minutes of customer time on drive from Seattle to Portland is win-win situation for both, while building on monopoly currently Starbucks possess on entertaining tesla customers will only strengthen their portfolio.

Times I slept by.

I often wonder how much it has changed as it moved past. Now I open this tiny window to peep through memories of past & look to those significant memories one's which made everyone go alas. Some brought tears, some even broke heart and everything changed it a bit from what ever it was.
These micro changes often make a different large in one's heart in ones' life and one's path.

Drifting with Time...

As slowly i drift in time
I miss those who held me calm
made me feel loved
kept safe my beating heart

You are so afar now
diminished even in memory
faded in times that didn't last
all this while tried staying alive

What I felt then
no words are true enough
to share my feelings share my heart


I betrayed you i betrayed my own heart
little I realized how I dishonest I was
As time flew by
little by little tore myself apart

Now all I do as i sit quietly
Cry in my own little heart. 
with the hope everyday to see you once more
Touch your heart and make you smile

Teri Yadoon Se

Marr kar khud ko mita jayenge. 
Khudd ko he hum bhula jeynge
Teri yadoon se mitayenge khud ko is kadar

Ki prachaai ko bhi humaari chupa jayenge..

Software Consultant - Engineering Prostitute

It’s been while till today I couldn't really frame this very title. Prostitute by definition is "A person who willingly uses his or her talent or ability in a base and unworthy way, usually for money”. Our job is not about delivering solution but makes clients happy. We have wide variety of clients it starts from business user, business analyst, project manager, Development manager and sometimes even other consultants. Each and every clients has its own very needs likes and dislikes. We often used the word politics to describe this pleasing but if you attend one of these meetings you will soon realize this is one way pleasure ride.

Business Solution: As consultant team arrives to deliver the business solution. First thing consultant expect are problem, requirements and business expectations. The requirements are highlighted and goals are identified and works towards goals starts. As project matures, flavors of personal favors, personal expectation, even personal needs start clouding the delivery. And yes those are planned for too but there is always delta of those can be address in timeline given while trying to address those some components are missed. And journey started to deliver a best business solution and often ends up with least sustainable one. Now as we understand business needs are the very reason for software solution or project but If not well discussed, scoped, planned and handled they often become the very hurdle in delivering the best solution sometimes even solution itself.

Story of setting over expectations isn't far from truth, it’s often considered good practice to add more then what is needed in a thought process that consultants and sometimes the only friend BA will trim them down. Let me give an example of swing delivery. Consultants would be often shown park to delivered in times that can delivery just one swing, so while in race with time consultant will deliver few components of swing and few of park as time doesn't really allow delivery of whole park but they will fail to deliver the basic swing set which was actually the need of delivery.

We spend time on delivering items which are mostly to please but have no real business value as they are deemed important by a person who is our point of contact. We even use fancy terminologies like of “A wholesome experience” as swing by itself will not give you complete feeling so let’s build fencing around it, let’s have pond too since we have pond we should add some ducks. With more visionary people in team we can even add merry go round, Now all this doesn't just come from business user, sometimes our very own PM or BA’s. It is very important to build framework solution that allows to extend our swing set solution to Whole Park but wrong if you spend time in building actual things other than just swing set.

As to voice these concerns is a job of consultant. But as prostitute adjust herself to do whatever client’s needs so do consultants. In the end all consultants are working for money not for good solution of problem. If consultant says they will only build what all are written in requirements those consultants are not very well treated either clients gets another prostitute or just force the very prostitute which disagrees. In the end we are all sell out of market so as most prostitutes you will sell it too. 

Adieu

As i bid adieu

I reminisce our old times. 

Thank you for being my support

As my teacher as my guide

Will always treasure

These life long bonds

And old ties.

It was journey of curves

On the path of light

As i emerge at the end

I feel enlightened i feel bright

And will always remembers

In hard times you were always beside

As i bid adieu

Now i smile as I walk

Onto my new life

With a hope we again sit beside

And i was always glad

having you as my friend in rain and shine