Management of change experience in my organization
Mohammed Asif PGPEX 23/8
Change is the only constant in life. Things and situations around us change every day and we have to adapt to them. But ironically, change is the hardest thing to bring about in a person or an organization. Resistance to change among employees is the biggest challenge a management faces when trying to effect a change. So, why should an organization change? Any business in today's fast-moving environment that is looking for the pace of change to slow down will surely be disappointed. In fact, businesses should embrace change. Change is important for any organization because, without change, businesses would likely lose their competitive edge and fail to meet the changing needs of ever changing customers. Change that results from the adoption of new technology is common in most organizations and while it can be disruptive at first, ultimately the change tends to increase productivity and service. Technology also has affected how we communicate. No longer do business people have to laboriously contact people, in person, to find out about other people who might be useful resources - they can search for experts online through search engines as well as through social media sites like Linkedin. Today's improving communication technology represents changes that allow organizations to learn more, more quickly, than ever before. As the world evolves, customer needs change and grow, creating new demand for new types of products and services -- and opening up new areas of opportunity for companies to meet those needs. Change management has become crucial in today’s organizations. Effecting a change in my team at CA Technologies
I worked as a scrum master in a product development team at CA Technologies. 2 years ago, the company adopted the Agile methodology and started following the scrum model. A team of not more than 9 engineers made a commitment to develop certain features from the product list (known as product backlog) in a stipulated time frame. Usually, commitments are made for a sprint (2 to 4 week time period. The time period is chosen by the company) and a release has typically 5 to 10 sprints. Team sits together before every sprint and carefully plans as to what all items to be taken up during this sprint. Team as a unit tries to complete all the items taken up during the sprint. A sprint retrospective happens after the sprint where every member gives his opinions on what went well and what can be improved for further sprints.
In this development model, everyone volunteers for work and goes on to complete his/her own work. In case someone fails to complete, another team member steps in for him. This kind of model which lays more emphasis on team work necessitates that there are no laggards in the team. The team targets for some features in a sprint and the team velocity is determined by the number of features it could actually complete. It is a self-correcting model wherein team understands its own ideal velocity by trying and failing/accomplishing. As you can see, the role of retrospective and feedback is very prominent in this kind of a model. Every person should be willing to volunteer for more work, to challenge his abilities and know what his ideal potential is. Hence, feedback from peers to peers becomes very important for this model to succeed. Pain points of the model
I was the Scrum Master of the team and was responsible for ensuring that team plans the sprints well and is successful in meeting the commitments more often than not. Removing obstacles, if any, of the team was also my day to day job. After a couple of sprints, I realized that though few engineers were meeting their commitments, there were problems that need to be addressed. There were engineers...
Please join StudyMode to read the full document