The managers second session on Jan 20, 2007 was very interesting. It was something that was long time coming. The CEO had some other engagement, so could not make it on time. Hence, it was the managers and the Agile proponents. The topic was also suitably - Management Roles in SCRUM: Product Owner and SCRUM Master. I had to orient the course in terms of “what role would SCRUM Masters play in their teams” rather than as a critique of current project management style. Through out the session I emphasized how SCRUM Master is the natural progression for all project managers. However, it did not seem to have cut any ice. The managers are reported to have remarked : “you don’t need us any longer”, “our developers are coming up with strange interpretations of SCRUM”, “I am having difficulty controlling developers” etc. There have been two cases where managers have actually broken down. On another occasion people have been shouted on. Our effort seems to be stuck. At one point it seemed like I would go ahead with teams which are responding and leave the others. And then we thought - if I do that, whats the difference between current management style and Agile thinking I am propogating. The challenge is to win the trust of all. It is very difficult but then change is difficult.
I chanced upon the following excerpt from “CIO Playbook for Adopting SCRUM”, apparently co-authored by Ken Schwaber:
Change is hard work and there is no way around the hard work. Organizations implementing Scrum sometimes misidentify the hard work as someone’s fault, something that can be made to go away if the group at fault would just “clean up their act”. This type of organizational blame can kill a Scrum implementation, and with it the organization’s ability to build better software. When something is painful, when something goes wrong, recognize this is just part of the change that is occurring; it is an opportunity for everyone to get together to figure out how to solve the problem, together.
Scrum cannot be planned for and implemented with checklists, procedures, and forms. Scrum is just a simple framework that will identify everything in an organization that gets in the way of optimally building software. The work to manage and remove these impediments represents the difficult part of implementing Scrum, and it is different for every organization, since every organization is different.
Nobody likes pain and difficulty; many of the impediments are so inherent to an organization’s way of thinking and operating that they are very difficult to remove. No amount of planning up front will mitigate this difficulty; it will only help alert everyone to the hard work that must be done to become a world-class competitor. Scrum requires that senior management be vitally involved in impediment triage and removal, and therefore requires that the CIO adopting Scrum become the leading agent for change.
In this way, the CIO engages in a process of continued organizational improvement, all aimed at increasing the productivity and quality of the software teams. It’s not easy, and the leadership the CIO provides will be a critical factor in success, as the following note from Ken Schwaber to a CEO illustrates:
From: Ken Schwaber
To: XXX XXXXX, CEO for XXXXXXX Corporation
“On one hand, Scrum offers some very attractive possibilities – increased productivity, a better working environment, increased competitiveness, and a higher quality product. On the other hand, it is hard to implement. The amount of change engendered by a Scrum implementation is significant and difficult.
Even though the change is difficult for the developers and customers (product owners), they have immediate payback through increased job satisfaction. This helps them through times of stress and anxiety. Middle management, however, is stressed without immediate reward. They are asked to help transition an organization from traditional approaches to leaner approaches without a clear vision of a personal end point … what will I do and where will I fit into the new organization. This question is particularly difficult and fraught with danger since middle management will be fashioning the new organization. The potential for conflict and politics is daunting.
My experience with top-down, enterprise implementations of Scrum has led me to believe that the differentiator between success and failure is you. Your ability to vision the future and help communicate it to your management, your ability to patiently guide them through the change, and your ability to assure your middle management of their value and form them into a team will differentiate your ability to absorb the change and realize the benefits, or not.”
Although I am not the CIO of the organization and nor do I wield as much power - yet it would be worthwhile absorbing some of the above. Implementing this is a personal challenge itself. But then as I told the managers:
“SCRUM Management requires a much different level of intellect and emotional connect than traditional management.”
