Talk to the real customer and listen carefully…

As an architect one has to interact with different stakeholders. An architect interacts with developer, tester, requirement engineer (our internal customer), fellow architect, designer and the real customer. Out of all this interaction, I feel the interaction with the real customer always fascinates me a lot. I will share one such instance here. In the recent times I visit a hospital regularly for my kid’s vaccination. The regular pattern is like we call the hospital and book an appointment. The appointment itself doesn’t contain a time slot or any waiting list number (token number). After this we need to physically visit the hospital, pay the consultation fees and get a waiting list number. Then we wait for our turn. This waiting is a painful one for all the visitors. The hospital has a nice IT system that helps them in patient management, billing, consultant management and employee management. Being a software solution provider I thought this is great opportunity. Add a module that can provide automated online appointment management (web based/mobile based). The visitors need not waste their precious time and still gets to meet the consultant on time.

I got a chance to meet the hospital head and mentioned this solution. Also I elaborated how easy it is to add such a module. He listened carefully and then uttered the following

“I know it is easy to add online appointment management to our system. But in our locality people still judge the popularity of a hospital by the amount of crowd waiting for consultation. If I reduce the crowd by introducing such a system, then it will bring down the popularity of the hospital. So having a manual appointment management system is a conscious business decision.”

I learned the reason and thanked him for the clarification. As I stated in the beginning interacting with a real customer is always fascinating.

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.