Get certified - Transform your world of work today

Close

A Scrum Meeting-Room Model Boosted Our Productivity

How a new pattern helped our team improve

15 January 2016

Senthil kumar Ponnusamy
HCL Cisco offshore development centre


We were in big trouble when heavy rain and flooding hit the city of Chennai during the first week of this past December. Our offices flooded and were closed for two weeks; one of our big campuses was flooded by five feet of water. As a result, we were running around to other offices nearby, and also to other areas, such as Bangalore.

However, we had been requested to continue our work as best as we could. Finally, my Scrum team got a meeting room in one of our other Chennai offices, but we were way behind in terms of meeting our sprint goal (after all, we had not had Internet or even power for a whole week). Nonetheless, the ScrumMaster, testing team, and development team sat down in the room with the test engineer, local architect, and business analyst and began face-to-face discussions.

Some good things came out of this. My development team had planned a feature for a two-week sprint, and although we had already lost that first week of the current sprint, they completed the features in three days. We were very excited, and we realized that having a meeting-room model worked well for us. Most of the organization uses the cubicle model for its work environment, and my Scrum team normally does indeed also work along with other teams on the floor. But we began to book a meeting room for two hours on a daily basis, and we used that meeting-room model of work culture for our development, discussions, testing, Scrum events, and so on.

We found that our team delivered high-quality features, and we sent the shippable increment to production release without even a single minor bug. Hence we made it an ongoing, daily practice to book a meeting room (with projector availability), and everyone liked this model. The team was able to hold a discussion as soon as anyone needed any requirement clarification. Technical help and support was always available during this period from my cross-functional team. We saw that we were reducing the feature delivery lead time and lowering variability as well.

As a Scrum team, we have been very successful during the last two sprints, and our team responsiveness has increased dramatically, as has our product quality and productivity. We have received a lot of appreciation from our stakeholders and higher management, even during the sprint when we lost a whole week due to rain and flooding. The team collaborated well and I could see that each person was organizing their work themselves, with great commitment and ownership. In addition, the team's business understanding also improved significantly during this time.

Overall, as a Scrum team, we now think big, do small, fail fast, and learn quickly. We see real improvement in these areas:
  • Responsiveness
  • Productivity
  • Quality
  • Employee engagement
  • Customer delight in the right product
  • On-time delivery of shippable value to the customer
Not a bad result from some terrible weather.
 

Opinions represent those of the author and not of Scrum Alliance. The sharing of member-contributed content on this site does not imply endorsement of specific Scrum methods or practices beyond those taught by Scrum Alliance Certified Trainers and Coaches.



Article Rating

Current rating: 5 (3 ratings)

Comments

Pavankumar Gaddam, CSP,CSM,CSPO, 1/18/2016 6:30:52 PM
Nice work. Good job. People often asks me Scrum has lot of meetings. It interrupts/reduces productivity. I tell them have 8 hr meetings every day. Gradually your productivity goes up.

Also, one more thing I want to mention is that, I call my team as team/member of a team and not as development team or testing team. By calling the members as dev/test, we are making walls between them.
Senthil kumar Ponnusamy, CSM, 1/18/2016 11:15:38 PM
Thank you so much for the good comments. yes, i do agree that i should call team/member of the team.
Senthil kumar Ponnusamy, CSM, 1/18/2016 11:16:25 PM
Also i wanted to add few more quantitative benefits below.

• Great Responsiveness from team so that we can deliver on time.
• We delivered a right product to customer with great quality.
• Teams productivity gone to next level.
• Customer delight for right product so team can get lot of appreciation.
• We could see better employee engagement always.
• It can completely remove the risk/bottleneck from depending on particular engineer/lead/project manager.
• No need to have any knowledge transfer session to anyone, it reduces some time for senior developers.
• Teams can better collaborate at project level as well as at personal bonding/friendship
• It makes anyone can work on any part of the project at functional level or code base level
• It definitely eliminate wastes
• It helps team to amplify their learning on product domain and also technical levels too.
• Team can come up with emergent design at functional level and emergent architecture at NFR’s level for the product.
• Encourage meeting room culture for development and testing instead of using it only for discussion purpose.
• Sometime, Discussion or work got postponed due to meeting room’s non availability that can increase the lead time.
• Everything transparent to entire scrum team which reduces the confusion and conflicts

You must Login or Signup to comment.

The community welcomes feedback that is constructive and supportive, in the spirit of better understanding and implementation of Scrum.

 

Newsletter Sign-Up

Subscribe