Preyesh Malde - a genius I had the privilege to work with!

 

It is not everyday in my professional life that I come across people that I want to keep with me forever. This man had something about him that I always admired. I was never sure what that was but I knew there was something special.

He is one of those kind who does not let you enter his good books, but once you are in, it is nearly impossible to get out of it. I feel that I did make it through. I know I am going to break a lot of hearts when I say this but he did mention on his last day in office with us that "of all the people, he enjoyed working with me the most."

I met him about a year and half ago when I was in London to learn from him. I still have the first diagram that he drew on the white board to explain the overall architecture of a product. I also remember that I out in a lot of effort in documenting whatever I learn from him. The first document that I wrote was in a Q & A where a person is asking questions and an expert is answering them. I never could gather the courage to tell him that when I was writing that document I had his picture in mind and also quoted some of his statements. That remains my most loved and treasured document in my current professional sprint.

Everytime I was in London, he would make sure things were planned to perfection, every evening we were drunk (well almost). He introduced me to the best coffee I have ever had in my entire life (Taylor Street Barista). The sound of the words 'skinny cappuccino please!' is still fresh in my memory. We had a few Old Fashioned in my first visit to London @ Sushi Samba and we loved it. He then made sure he had a new venue ready for us to visit and drink that loved drink of ours whenever I was in London.

Well all of this was outside the office hours. I am in no way hinting that we only enjoyed, we worked together and we did deliver a lot of quality stuff. We shared a great chemistry. Although he was the one who used to guide me through most of the work, he was never shy to take any comments from me and include them. In his leaving card I wrote to him saying that he is the one person to whom I attribute all my technical success of the project. One of the colleagues who read my note on the card also mentioned that "you have attributed all your success to him, there would have been others as well." The answer is yes there are others as well, but technically he is the one person that I have learnt the most.

This picture is all that I have for memories. I would have spent about 6 months in London working with him (while he was working for the same organization) but I never even thought that there could be a day when he would leave the company and go else I would have clicked one picture with him. I am sure this is one the tasks that I want to do on priority next time I am in London. I am sure we will meet whenever I am in London. 

I would like to conclude by thanking you mate for all your help support and love throughout the journey. I wish we get a chance to work again in the future. Till then I have a lot of code that we have written together to live with. It has been a pleasure working with you Mr. Preyesh Malde. 

Open/Closed Principle

As most of us know, Open/Closed Principle is a design principle while working with Object Oriented Programming. The wikipedia definition reads:

In object oriented programing, the open/closed principle states "software entities (classes, modules, functions, etc.) should be open for extension, but closed for modification” that is, such an entity can allow its behaviour to be extended without modifying its source code. This is especially valuable in a production environment, where changes to source code may necessitate code reviews, unit tests, and other such procedures to qualify it for use in a product: code obeying the principle doesn't change when it is extended, and therefore needs no such effort.

This is a design principle that we generally follow in our day to day development cycle. Recently I have been doing a lot of code reviews and I have been working with the teams to ensure some good practices are being followed within the teams. To my surprise, there have been cases where I see the Open/Closed principle has been applied but the definition of open and closed have been reversed. I have seen implementations that are closed for extension but open for modifications. What this basically means is that the designs are flawed and there is a lot of re-work required to sort out the mess. 

It is funny how life lets you chose your own interpretation of things !!!    

Agile Estimation - PlayScrum Delhi [25th July 2015]

What is Meetup

It is a social community of people who meet face to face to share their experience and learn from the experience of others. It is an informal way of interacting with people and learning from each others experience.

What is PlayScrum Delhi

It is group of Scrum/Agile enthusiasts within Delhi NCR who want to collaborate with others in the same region sharing the same interests. Details available here.

Who decides what we will discuss

The people who attend the meet-up collectively decide what area or topic we want to discuss. Agile Estimation was agreed to be the topic for the meet-up on 25th July 2015.

Agile Estimation - as it happened

Introduction

We started with a round table introduction of the people attending the workshop. It helps build an understanding of the breadth of the participants.

Estimation Game

To set the context of what was coming later on in the workshop and also to make sure everyone is involved, we started with an estimation game. People were grouped into small teams and then they were given some fruits and they had to come up with an estimate of how much effort will be required to eat that particular fruit.

The purpose of this game was to:

• prove that estimates are not scientific and they are limited to the local teams and not generic.
• the interpretation of '8' could be different for different teams.
• show why it is easy to use a benchmarked unit as against hours/time.
• to underline the fact that estimation is sizing the problem and not the solution.   

Why Estimation

We discussed why is estimation important and what are the different techniques that people are using to estimates. The purpose was to communicate that any of the approach could be used and there is nothing that scrum prescribes. The teams are free to use what ever technique that serves there purpose. Some common techniques were using Functional Points, Story Points etc.

Story Points

This is one of the ways of estimation used in agile projects. It has come from XP. It is an indicators of the Uncertainty, Complexity and the Amount of Work that requires to be done for a feature/story/task to be complete.

They help drive Cross Functional Behaviors within scrum teams as the size of the problem will remain the same from a DEV, QA, BA or any other perspective. It is also a relative measurement unit.

We took the analogy of building a room to explain the concept. To build a room you would need a 600 sq ft area, 3 windows, 2 doors etc. Now the size of problem to build this room will remain same. How it is built would defer. We concluded that estimation is for the WHAT and not HOW.

Story Point Matrix

This is a way of organizing your historically estimated data which can be used as a benchmark in the future estimations. Essentially this would a map of the possible story points with some example of stories against them.

Examples:

2 - preparing a cup of black tea

3 - preparing a cup of white tea

5 - preparing a glass of cold coffee.

Velocity

It is the amount of work that the team has been doing within a sprint. If you are estimating based on SP then the Velocity would be the No of SP delivered within the sprint. This is useful while planning your iteration as it helps you come up with a base number of SP that your team has historically delivered and hence helps you plan for future.

Exercise 

To clearly understand the concepts we discussed a problem. The problem was:

• There is a company with 3000 employees
• There are only 7 people in the IT support
• People are complaining that there IT related problems are not being solved and that is hampering their productivity.
• The problem gets escalated to the CEO
• The CEO calls a meeting and asks the team to come up with a solution to fix the problem within 24hrs. He emphasized that he needs a solution that goes live in 24 hrs and not a plan.

We then divided ourselves into groups and tried to solve the problem. The aim of this exercise was to prove the fact that the size of the problem was same for all the teams, the solutions were different. 

No Estimates

There could be different ways of estimating. People have started talking about not estimating at all. Some other ways of planning your iteration is to limit the number of stories in you sprint. This would mean that all the stories are relatively sized. The teams split the story if they feel it is growing bigger, this eliminates the need of a separate estimation session.

Conclusion

This is just interpretation of what we discussed during the workshop. I might have missed some points. If you feel there is a change that i should make, leave a comment about it and i will incorporate it.