I spent an amazing Saturday morning with the 2020 class of Goa Institute of Management doing their MBA in Big Data Analytics, and it was an absolute delight to interact with students from my alma mater, and answer their questions.

I was incredibly impressed with range and depth of their questions, and during the conversation I provided a lot of references, so I thought it would be useful if I wrote a post linking to them here.

If you were in the discussion, and remember a question or reference that I made that’s not listed here, please feel free to leave a comment, and I’ll add it here. And with that, here are the questions I remember, in no particular order.

How do you build happy teams particularly in the times of this pandemic?

I spoke about servant leadership, and how it lends itself particularly well to the current times because as a servant leader your focus is on serving your team, and this is the primary ingredient in building a happy team. Read this introduction to servant leadership as a concept, and then this paper to see how you can objectively measure the impact of servant leadership on your team’s psychological health.

How are companies changing their onboarding to be fully virtual?

I was extremely excited by this question because I got to share my own experience with the fantastic onboarding experience that ServiceNow has created for its new hires which is by far the best onboarding experience I’ve ever had, and hundreds of others share my sentiment!

How do you take care of your mental health in an all virtual work environment?

Here again, I spoke about something we do in ServiceNow which is the no email, no slack, no meetings Friday. While I have to admit we don’t follow this a 100%, having a day designated where you don’t have a ton of meetings, and can do some uninterrupted work, and log off early when all of it is done helps your mental health greatly.

I also spoke about Google’s post from earlier this year that has tips on working together when we are not together.

How are Lean principles applied to software development?

Lean principles have their origin in automotive manufacturing, and they were translated to software development by identifying types of waste that occur in the software development process akin to the manufacturing process, and then making efforts to eliminate or reduce these wastes. As an example – “Inventory” is identified as one of the wastes in the Toyota Production System’s Manufacturing Wastes, and the equivalent in software development is “Partially Done Work”, and hence the emphasis on limiting WIP (Work in Progress). This paper on software development waste is a very useful starting point to understand this.

How do you deal with workplace incivility?

The question was more situational, but the situation the individual found himself was that he was facing rudeness, and general incivility in his workplace. Anger, fear and sadness are the three negative emotions that you usually encounter at work, and this MIT Sloan paper on smart ways to respond to negative emotions at work is one of the best resources I’ve found on the topic, and one that I continue to read when I find myself in similar situations.

How useful is an MBA in the software industry?

For this one, I didn’t use many references, and primarily talked about the transferability of soft skills, and hard skills across industries, and disciplines, and how all knowledge is cumulative meaning one piece of knowledge builds on top of another, and when you learn something in one area it is often used in another area as well.

What is the utility of a standup ceremony in Scrum?

Mike Cohn does a great job of explaining the objective and mechanics of how to run a daily standup, and I highly recommend this post. 

What kind of data do companies use to make decisions?

In response to this question I emphasized the need to appreciate the difference between outcomes and outputs, and understand that primarily organizations are interested in outcomes, so the most useful metrics are ones directly tied to outcomes and not outputs. This is a good paper to understand the difference between an outcome, and an output.

To wrap up, I’ll say that I had two activities and a whole set of slides prepared, but we never got past my introduction because the conversation flowed so naturally from one question to another, and I would absolutely have had it no other way, so my gratitude to everyone who attended, and I’m looking forward to interact with you again!

I’ve often heard people use iterative and incremental interchangeably in an agile context, and if I’m being honest I have often mixed up these terms myself. Mike Cohn does a great job explaining the difference using sculpting as an analogy, and till recently his example was the clearest I knew of when thinking of iterative versus incremental.

That changed last Friday as I was looking through the stories my team will build in the upcoming sprints as there are two pieces of work that we’ll be doing that are great examples of building iteratively, and incrementally.

A quick English definition of both words is helpful before we go any further.

• iterate:to say or do again and again
• increment:the action or process of increasing especially in quantity or value

In software terms – you iterate when you take a feature, and improve it successively, while an increment is delivering a feature, and then adding another one, and then another one, and so on.

In my example – we’re going to build a request submission process that requires approval and will trigger emails. Everyone has likely experience with this because they are one of the most common type of processes, and the end state is usually a process where you submit a request, it goes for approval, and upon approval it gets created, and alongside emails are triggered at every step.

This is what it would look like in a simple graphical manner:

The request creation process is iterative because we will first build something without any logic – everything gets approved, then we go back and add some logic, and allow approvals only, and finally, we add in the capability of rejection as well. This is an iterative process – we are making progress through successive refinement as Mike Cohn describes it.

The email process is incremental because each email notification is complete in its own right – the wording, branding, timing, recipient – everything is delivered fully at one go, and you don’t need to revisit a previously built email in the process of building the second one.

Agile development is both iterative, and incremental, and to some degree you can argue both sides on what is iterative versus incremental on almost everything. But I do believe this is a good example to illustrate the difference between the two, and how someone might decide whether their work is iterative or incremental.

I’m pretty excited to have hosted my first app on AWS! I have been playing around with R & AWS since the last six months or so, and went through a Shiny app tutorial last month.

Shiny apps are a great way to build responsive web pages that run R code, and generate very pretty graphs and charts. I was quite impressed with Shiny’s simplicity, and wanted to explore it further.

However, there’s not much meaning to creating impressive visualizations if you can’t share them easily, so I tried to see how easy or hard it is to be able to host it on the web.

AWS is the go to solution for this kind of thing these days, so I decided to start up an EC2 instance with Ubuntu on it, and install R & Shiny server on it, and then move my R code to this server.

It wasn’t hard at all, but it did take me two tries because I have never done this thing before. I got the code for app itself from the introductory R Studio tutorial.

In the end I was amazed at the relative ease with which you can bring together all these technologies, and have something up and running so quickly.

Here’s my AWS page. The Shiny app tutorial that helped me get started, and the Git page to the code in the tutorial. Finally, this tutorial that teaches you how to install Shiny server on AWS.

One of the most common errors I see in sprint planning is the tendency of people to try and come up with story points based on who is going to work on a story.

If the developer is somewhat inexperienced then the entire team leans towards assigning a higher number than they would have otherwise done.

This is a mistake because if you do this you will never be able to increase that part of your team’s velocity which accrues due to the team becoming better at the task.

If a story is truly worth eight points, and you assign it 13 points based on the fact that the person doing the story will take more time then sure this time it seems like the person contributed 13 points to the team, but in reality they delivered lesser business value. Two or three sprints forth if this person is now more efficient and does 13 points worth of work that will not show up in your team’s velocity because you will assign this story 13 points as well. So, while the person did more work from one sprint to the other – the team’s velocity remained the same.

You see this happen a lot, and I believe a big part of the reason is that people are just used to estimating based on the time it will take them, and not based on relative sizing. This is why it is often helpful to remind everyone what the team’s baseline is and that’s to be kept in mind while doing relative story point estimation.