Internet of Things, Black Magic and Humans

In the recent times I read a lot about IoT(internet of things). And the way they are going to improve our lives in so many ways. For example the story goes like

  • By the time you reach home the thermostat will start the AC or the heater and setup a pleasant temperature
  • The new age LED lights are connected to internet and switch on/off based on your location pattern
  • The fridge finds out, there is no milk and adds a to-do entry to your to-do list to get the milk
  • There will be sensors everywhere. Based on the data they will decide and act intelligently

Yes. All of this is well and good. But among all this intelligent set of things there is a dump thing mixed in. It is none other than the HUMAN. At times I feel scary how this billion of IoT is going to handle the human. I will quote one of my own examples here.

  • At our home we have 2 iPods a nano(8GB) and a touch(32 GB)
  • My father used the nano while I used the touch

I load the songs into the iPod using the following routine (Because of the difference in the iPod memory size)

  • Remove all the songs from iTunes
  • Connect the iPod to the PC
  • Add the songs based on the need into iTunes
  • Run the iTunes sync
  • Disconnect the iPod

Sometime back I was travelling to USA for a long term. As a part of the travel preparation I made sure I loaded my entire music library into my iPod touch. One check list item done and ticked. My father requested me to load some of his personal favorites into his iPod nano. I did my regular routine and gave the iPod back to him. He thanked me and verified all his songs were loaded. I felt happy that in between the travel preparation, I could get this small job done.

I packed my bags and reached USA. After a week I thought of listening to some of my favorite music. I took my iPod touch, charged it and connected my headphones to it.

SURPRISE!! SURPRISE!!

I hear some old song that was my father’s favorite. I thought maybe I added that by mistake. I shake the iPod for a shuffle. Again another old song. After lot of shake I found my entire music is missing and is filled with my father’s collection. I am wondering what has happened? I didn’t touch my iPod after the last sync. I clearly loaded all the songs myself. That was the first step in the travel preparation. I was wondering what sort of black magic has happened?

Then I found out, I turned on itunes wifi sync by mistake sometime back. So when I was loading the songs to my father’s iPod, my iPod touch found that out, intelligently wiped all the songs from its library and loaded all my father’s songs into it over wifi automatically. From the iPod touch point of view this is perfectly fine and intelligent doing all this in the background. But the outcome was a disaster from my point of view.

The problem is humans have a tendency to forget things. Until now it was my PC, internet and the so called Smartphone that has to deal with this situation. Now I am not sure how this billion IoT is going to handle this situation.

–Ferose

Advertisements

Subtle things in SCRUM – 2 Burnout

In continuation to my last post, Here is another subtle thing that I learned by practicing scrum.

The success of a SCRUM team depends on the effective sprint execution. Our typical sprint execution is like

  • We have a sprint backlog. This is prepared as a result of sprint planning
  • Each team member takes a task and starts working on it
  • Each day in the daily stand up meeting the team member reports the amount of time needed to complete the task (it is like estimating the task daily based on the latest knowledge)
  • Once completed pickup the next task based on priority

But during the retrospective meetings the team members complained about burn out. The following were the comments

  • This methodology is too taxing
  • I have no time for any other work other than the project
  • In case of waterfall we had pressure at the end but here in scrum we have constant pressure all the time

Over the time the team’s productivity also came down a bit. After some analysis we found the problem. It was “Allocating all our time for the project during sprint planning ( 8hrs/day )”. In addition to that during the planning phase we tried putting in as many hours as possible. And during the sprint we tried to meet those numbers.

The problem was solved in 2 parts. One was from the project management side. The other was from our own.

  • From the project management side they too felt this burnout and made a small change. Instead of planning for 8 hours a day, we were asked to plan only for 6 hours a day. The remaining 2 hours went for all the non project activities.
  • From our side we made sure that the team brings in all time burners to table (training, vacation, holidays, supporting other teams, reading, learning etc.,).

Now the team had a constant load and we started to make predictable deliveries. In addition to this we never got the feeling of being under constant pressure and burnout. Again it’s a small correction but we learned it only during the practice.

–Ferose

Subtle things in SCRUM – 1 Sprint Planning

In the past I was leading a team of 8 developers and a tester. We followed the Scrum method for close to 4 years. In this series of posts, I am planning to write things about Scrum method that I learned by practicing it. It is mostly out of my personal experience.

One of the major tasks in Scrum is sprint planning. Our regular sprint planning happened like the following

  • The product owner comes up with a list of features, bug fixes and refactorings that can be taken up in the sprint
  • I find out the team’s availability. (Actually taking all the planned vacations, trainings & holidays into account)
  • Next we break down the features into smaller work packages
  • We all sit together and estimate the work packages (using planning poker)
  • Then we pick up work packages that is equal to the availability
  • And finally we assign the work packages to the team members

This was working fine. But then over the time I found that we missed our team goal even though majority of the work was done. After some analysis and retrospective I found the problem was the last step.

  • And finally we assign the work packages to the team members

This step of allocating the work packages to the individual team members divided the team into individual members. So if someone completes a work package the next one was chosen from the team member’s pre-allocated subset. Sometimes this created situations where a work package of high importance to the team’s success was stagnant because of an overloaded team member. And another team member is busy burning some less important work package.

So we learned our lesson and stopped allocating the work to individuals upfront. We planned the work packages without assigning a name to it. Now once someone completed a work package the next one was chosen based on the team’s priority. It also made the sprint planning a lighter exercise.

This is a subtle thing which no one taught me in the scrum master training. And I learned it after failing couple of sprints.

–Ferose