Part 2 Getting Ready - 2.2 Discerning the Magnitude

2.2 Discerning the Magnitude 

17. Urban Scholar

An age-old story goes like this.  An urban scholar travels overnight by train and reaches his destination. It is a countryside.  He comes out of the train station.  He is there to visit his friend.  He prefers to walk down to his friend’s house.  He finds a man standing in a nearby shop. He walks close to the shop and asks, “How much time will it take to reach Mr. Smith’s house if I have to walk from here?”

“I don’t know but you have to take that road.  That is about 2 miles of walk. That is the shortest route.”, and points to the road on his right side.

With a smile, our urban scholar decides start walking.

After twenty seconds he hears, “At this pace, you will reach Mr. Smith’s mansion in thirty minutes!”

Moreover, he inquires to verify, “Thanks! That is about two miles. Isn’t it?”

“Yes. That is correct!”

Estimation of software projects is nothing more than an educated guess. Sometimes, it turns out to be a wild guess too. One cannot afford to make wild guess because it can result in loss of credibility, monetary loss, brand erosion, and so on.   Observe, ask questions, and gather some knowledge before you estimate.

*-*-*-*-*

18. How Do We Size It?

Expressing estimates in terms of a unit of size creates a common understanding.   When you travel from one place to another by road, it is Miles or Kilometers. When you want to weigh something, it is Kilograms or Pounds.  When you measure liquid – say milk or oil, it is Liters or Gallons.

How do we express the size of a software application or product?  How do we compare two or more applications or products?  Counting the number of lines of code (also known as SLOC – Source Lines of Code) can happen after the product or application is delivered.   Can you estimate the number of SLOC from requirement specifications?

Bill Gates said, “Measuring programming progress by lines of code is like measuring aircraft building progress by weight.” We need to question the old school of thought and do what suits the present.

*-*-*-*-*

19. FP, UCP, SP, Etcetera

Learn Function Point Analysis.  It is not enough if you sit through a daylong classroom session. Try to apply it in projects and understand how it helps you in estimating. Besides, practice it – estimate, execute and deliver.  When you do this, you will learn what it is.  This holds good for all techniques.  Reading and lip-servicing alone will never help you or your teams.

Is someone in your organization promoting Function Points? Learn why. Is there a Function Point Analysis training program in the offing? Don’t miss it.  Let me repeat. Learn, ask questions, practice and experience it.  Do this for every technique – Use Case Point Estimation, Story Point Estimation, Test Case Point Estimation.   You will know what they are and how they make sense in different situations.

If your project is following complexity based estimation with classifications such as small, medium, large or very small, small, medium, large, extra-large, check if those buckets or categories carry adequate definition. 

Do not hold on to one technique even if you know it right.  Also, do not hold on to many techniques without a deep understanding of what they are.

*-*-*-*-*

20. What will it take?

Years ago, one of my customers approached our team with a set of reporting requirements.  He wanted us to deliver fifteen odd reports. The specifications were neatly written. We had a walk-through of all requirements. At end, he inquired, “How much time will it take?”

“We will estimate using Function Point Analysis or some other technique and come back to you in couple of days.  We will review our estimates over a conference call.”

“Well, are you talking about two days for estimation, one more day for review and yet another day to finalize and start the work?  We need all these reports in one week. With our current team of 5 engineers I think we can accomplish this.”

“Well, I am not sure. When do we need to move these into production?”

“Good question! That is in our next release, which is one month from now. I think we can start with the first ten reports today, do daily status check and track progress. What do you think?”

Finally, we agreed to start the work. Track our status daily. We completed all reports in ten days

Understanding and learning from our daily progress helped us move further.

Remember the urban scholar!

*-*-*-*-*

21. Who is Involved?

Once I was hired by an organization to execute a large project. The pre-sales team was involved in estimating the schedule, team composition and cost.  This project involved a team of more than fifty engineers across two locations and we had twelve months to deliver. When we started the project, nobody from the pre-sales team became a member of our team.  We started the project with requirement analysis phase and discovered several hidden or unspoken requirements. We negotiated all we can to contain the scope with limited success. We had no room to alter the estimates or schedule.   Can you guess the result?  We pulled it along, slogged, stretched, managed employee turnover, and delivered. The rest, I leave it to your imagination!

Do you know? Nearly 50% of failed projects in our industry suffered because of estimation and schedule problems.  This happens when estimates are made by management with no inputs from practitioners.  This happens when dates are decided and dictated based on raw requirements.  This happens when the estimates are very aggressive and new team members are introduced late in the game to douse the fire.

In successful projects, estimates are created by practitioners – typically by two or three independent groups and validated.  Team members are empowered to execute and make course corrections as they move along.  Team members are involved in task breakdown and task estimation.  Even though some of these projects start with an unrealistic or dictated date, team members and the project managers had enough room to negotiate and adjust the delivery date.

Ironically, in some instances, the creators or potential creators are not involved in estimating what it is going to take to deliver.  When this is inevitable, we need to be empowered to execute. Is there a better way?

*-*-*-*-*

22. Leave the artist alone!

One of our projects involved significant amount of creative design to differentiate our customer’s online portal and create a unique positioning among competitors.  In another project, we hit an unknown roadblock – a technical issue that required deep thinking and creativity to help us move forward.   These are the instances where you need to leave your team member alone. ‘What is our estimate?’ or ‘How many hours will it take?’ and the likes do not fit in here.  ‘What can I do to help you?’, or ‘What support do we need to make this happen?’ and the likes encourage the team member.

There are activities or projects that are emergent in nature. You know what you want. However, you do not have the ability to plan it in detail. You have to empower and support your team member who has taken charge of this. Do not push else the result will be a disaster.

Going behind all the time and nudging is a big No-No.   Leave the artist alone! You will get the deliverable!

A word of caution. I do not mean to say that such projects are activities do not have a deadline. There are deadlines beyond which the value of our deliverable diminishes.  Do not fail to set expectations. Meanwhile do not nudge or micro-manage!

*-*-*-*-*

23. Pushing for a deadline?

Sometimes you hear, “Here are the high level requirements.  We need to deliver this project before Thanks Giving at any cost!”   Have you heard this?  Can you deliver?

A possibility here is to be ambitious, aggressive, get onto the battlefield and win it.  Battles are won. That is a glory. And battles comprise of fatalities.

Another approach is to decline politely and say, ‘No’.

Which one do you prefer? Is there a practical approach?

There is no right answer. Weigh the pros and cons before you take the call.

*-*-*-*-*

24. Rational Thinking

Joe my customer called me that afternoon when I was out for lunch with my team members.   He shared with me some good news. That was about a new project.

In this project, he wanted to involve two geographically distributed teams. He recommended a team of seven engineers spread across two locations.  The objective of that project was to change the back-end or database of a large online portal.  According to him, this was a straightforward project. He wanted us to consider a tool-based approach.  We agreed on a tool-based approach so that close to 70% of the data migration happens through tools and the rest through human intervention.

We started the project with seven engineers. We planned to complete it in three months.  We were at the wider end of the cone of uncertainty – there were too many uncertainties.  We spent some time in tool evaluation and finalization.  We spent some more time in categorizing tasks that can be automated.  Our backlog increased week after week. After the first month, we realized that we needed a larger team to complete this project.

There was no room for negotiation on the project end date because of several internal and external dependencies.  Our customer wanted a robust and scalable database engine to meet the online rush during the upcoming holiday season, which was two months after our planned end date.

As we went on executing the project, our team size became 16 and we delivered a month after the planned date.  Because of all these, the project cost almost tripled.

We did a project post-mortem to understand the reasons and lessons.  We depended on Joe. He was the subject matter expert. He suggested a team of seven engineers, a schedule of three months and a to-be-validated approach. We did not cross-verify or validate.  Seven and three influenced our minds. We did not question.  We, including Joe fell into the trap.

Humans do not make decision rationally all the time. This applies to every one of us. 

Dan Ariely’s book Predictably Irrational is one of my recommended books to you. This book will make you wonder as well as understand how we are dominated and driven by arbitrary numbers. Also, read the chapter titled ‘Scheduling Madness’ in Steve Maguire book Debugging the Development Process.

*-*-*-*-*

25. A Practical Approach

Engage with your customer.  Involve your team members. Understand customer requirements. Remember, estimation does not result in a single number or a date or a timetable or a schedule. If it does, there is something wrong in it and the whole thing will not create a win-win proposition.  Estimation – whether it is the size of your project in Function Points or Use Case Points or the size or iteration scope in Story Points or project cost or schedule need to include a) the level of confidence and b) an entire list of assumptions.

When you refine project requirements, you know more details and your confidence will increase.  For this, you need to engage with your customer and business analysts – very actively. When you understand your project well, some of your assumptions might become invalid. With these, you will be able to re-estimate and re-plan.

Estimating and planning should not be done once at the beginning of your project and set on stone. You should perform these at regular intervals – every other week or every month.

Create a backlog of all features or user stories – whichever jargon you use. Prioritize or rank them.  Do this at regular intervals.

Deliver working software in short iterations at a sustainable pace. Learn and improve the accuracy of your estimate.

You will come across issues. They may be technical or people related or estimation related or something else.  Reflect as a team. Learn, decide and move on.

Estimating for small projects is relatively easier and less risky. If your project is large, see if you can cut it into small chunks and execute.

Involve multiple subject matter experts.  Let them come up with a collective decision on what it is going to take to deliver.  Involve the team. Never leave it to an individual.

The result? Rational thinking and decision-making!

*-*-*-*-*

26. Estimation and Execution

You may be good at estimating project schedule and cost.  It pays off when you are equally good at execution. 

Think! What happens when you yield to unplanned meetings, unexpected phone calls, emails and other such time thieves?   

You may be very good in managing your time.  What happens when you fail to make adjustments and be a team player?  What if there are several dependencies and wait times in your team?

What happens when you do not reflect as a team to reduce or eliminate inefficiencies and implement continuous improvement?

What happens when you do not have the courage to say ‘No’ when something obstructs your plan to deliver?

What happens when you fail to learn in a group setting at regular intervals?

What happens when you find it difficult to put it all together, focus on execution and get it done?

As much as you focus on estimation or more than that, you need to focus on execution too!

Execution must be a core element of your culture.

Pomodoro’ means tomato in Italian.  It is associated with a popular time management technique called Pomodoro Technique developed in the 1980’s.  Another icon associated with this technique is egg.  Remember the tomato or egg shaped kitchen timer?  A kitchen timer or an electronic timer is all you need to implement this technique. Pomodoro Technique enables focused work.  In simple terms, you set the timer for 25 minutes and star the task on hand.  Each Pomodoro is a time box of 25 minutes.  At the end of 25 minutes, the timer rings. You stop what you do and take rest for three to five minutes and start the next Pomodoro.  Each task you want to accomplish may need one or more Pomodoros.   After every four Pomodoros, plan for a long break – say for 20 to 30 minutes.   This technique helps you improve efficiency or productivity.

*-*-*-*-*

27. Commitment on Estimates

Are you ready with your estimates? When you share your estimates, does it entail your commitment as well?  When you say, “It is going to take six months and the planned end date is 28th August”, your boss or customer or senior management may perceive it as ‘Yes. We are committed to deliver on 28th August.”  Is that what you mean?  If yes, take it as a commitment and execute well.  Else, assess your level of confidence.

Can we stand up in every situation and say ‘Estimates and commitment are two different things?’

Obviously, we cannot. In addition, if we do it is going to cost us a lot!

Therefore, the questions are,

1. Can we commit to what we can deliver in the next iteration?
2. Can we commit to re-estimating and re-planning at regular intervals?
3. Can we commit to fail-fast-and-fail-early so that we learn from failures and perform well in a long run?
4. Can we commit to reflect and learn from our experience and improve at regular intervals?
5. When we work in short iterations at a sustainable pace, I am sure we say ‘Yes’ to all these questions.

*-*-*-*-*

28. Return of the Urban Scholar

The urban scholar we met at the beginning of this chapter plans to visit his friend once again after couple of months.  This time he catches the same train, travels overnight, disembarks at the destination and comes out of the train station. He is tired.

To his surprise, he finds a horse carriage outside the station and decides to take a ride to his friend’s mansion.  There is a man, perhaps the owner of the carriage standing next to it.  He goes near the horse carriage and enquires, ‘Hi there, I am John. I believe you are the driver.  I want to go to Mr. Smith’s mansion. How much do you charge? How long is the drive?’

‘Hi John! Good morning! I am Joe. It is about five dollars. That is my standard rate to go there. It takes about fifteen minutes.’

The urban scholar likes this proposal and takes a ride.  On the way, they exchange small talks about themselves, their families, and so on.

John, our urban scholar asks Joe, ‘Is there a way to reach my friend’s mansion in ten minutes or less? Why does it take fifteen minutes?’

Joe responds, ‘Yes. I forgot to tell you that. My son, Tim would have taken you in exactly ten minutes in the same carriage. We have only one carriage and one horse. Somehow, Tim has a better rapport with both my horse and carriage.  He comes here on Thursdays and Fridays.  May be next time, you will get a chance to be there in ten minutes.’

The carriage stops at Mr. Smith’s mansion.  John thanks Joe, pays five dollars and enters his friend’s mansion.  As he enters, he thinks through the conversation.

I am sure you do too.   It is not the horse alone!  It is not the carriage either.  Nor it is the driver. It is how all three work together.

What do you think?

*-*-*-*-*

2.1 Knowing the Needs and Wants                Table of Contents                  2.3 Creating Blue Prints