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.