Here’s a lightweight project plan template I created to help with our cross country move. Feel free to use and enhance!
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.
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 recently finished reading Succeeding with Agile by Mike Cohn, and absolutely loved it. I have read Mike Cohn’s blog for a number of years now, and I am a big fan of his writing, and after reading this book I have decided that I will read all his other books, and also undergo his online trainings; I really did find a lot of value out of this book.
The book is full of practical advice on scrum, and lists out the various problems you will encounter while implementing scrum, or practicing it in your organization.
The book is structured quite simply, and intuitively in the following heads:
- Getting started
- Next Steps
Each section goes into a lot of detail that taps into Mike Cohn’s experience with dealing with the challenges that organizations, and individuals face in adopting and running scrum teams.
Although I liked each and every section, my favorite one was on teams. Ultimately, a large part of running an Agile program successfully is to have an inspired, united, motivated team who has each other’s backs, and this section goes into great depth as to how you go about building that. This section also deals with some key aspects of sprint planning, backlog management, leading a self organizing team which are all at the heart of a successful agile project, and are also things that I am most closely associated with as a scrum master.
There are two other great things about this book that I’ve really enjoyed: one is that every section is peppered with common objections that Mike has heard throughout his career, and how to counter them. These are certainly things that I’ve heard myself, and even experienced myself. It is very beneficial to read from one of the most well respected thought leaders in the agile community on these objections, and then model the responses in your own behavior, and interactions.
The second thing is the extensive list of further reading material and references provided in this book. It is very exhaustive, and varied, and just this morning I spent an hour going through Hofstede’s cultural index which I found fascinating.
In conclusion, I think this is a great book, and even a must – read for anyone who works in any role in a scrum environment, and certainly for all scrum masters.
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.