Change is Difficult

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.”

Next Group - Session V

The session was conducted on a new day the week ending Jan 19th, 2007. It was Wednesday. We had sent a holler much in advance. However, it was amusing to see that lots of people still managed to reach the training venue either Tuesday or Thursday [we combined participants from two groups into one]. It just goes to show the great value [and disadvantage] of rhythm and cyclic activity.

The session this week was “Unit Testing - with code snippets from C#”. The group listened patiently as we discussed Text Fixtures, Test Harness, Test Set Up, Test Tear Down methods and how nUnit is perfect for Business Layer. In terms of impact, this one would be the least effective session ever. The group said that they had already covered this in the alst session and were not convinced if in their hectic schedules they would be able to incorporate nUnit in their set up. All of them were almost convinced that this would make the development activity longer.

We had to try and convince them to try this for the 20% code that was most critical for the project. It would take some more convincing before this results in any useful activity. We will follow up on this later.

Sessions Restructured Again

We restructued the sessions in the week ending Jan 20, 2007. All the dot.Net resources were in one group. The other group has been disbanded for now. The overall group energy was not working and we have to think of a way to get some positive energy in that group. Also, the first group now comprises of participants who have taken the SCRUM axion - Art of the possible back to their teams and implemented some aspects of Agile practices in their teams. The group that we discontinued [at the moment] could not implement the same due to number of reasons.

There was an interesting technology paradigm to the success of participants as well. The teams which did well with SCRUM over last few months were all dot.Net teams. The PHP teams were not as successful. In fact there are murmurs of developers wanting to shift teams because the other teams are more dynamic, energetic and buzzing.

However, the other group has not been abandoned. We are trying to regroup, try other strategies and motivating them to implement SCRUM/ Agile. Its only when there would be certain critical momentum in the direction, we would make any headway. Our efforts are to get that going now.

————————————————————————-
Journey from no-style Project Management to Agile Thinking and Principles
http://agilediary.blogspot.com/

Developers vs Managers - Part A

One of the pitfalls that we were almost waiting for *not* to happen was developers vs managers confrontation. In our first group we had two developers who were a bit out spoken and their managers were little relucant to leave them for the sessions. The developers seem to have understood the Agile ideas like “the team is the manager, SCRUM Master has no direct authority over the team, estimates can go wrong” a little wrongly. Worse of all, their managers instead of helping them understand these issues - went into a me vs you debate. The result: both the developers have given interviews at a competing firm and the HR department is exercised. The CEO is concerned that managers are getting stressed out because of developers and the developers don’t know why they were taught some things when no one is going to implement it. The classic tussle had started:

1. Project Managers were saying “you don’t need us anymore.”
2. Developers were saying “voa! you don’t know how to manage or don’t understand Agile.”

Our solution centered around talking to all involved separately and on one-to-one basis to understand their view points. We also understood that we need to reorient some aspects of our lessons to emphasize Humility and Teamwork as part of an overall theme. And importantly, we need to let people understand that Agile viewpoints and that “we are not going to solve their problems - they have to figure a way out.” We are there to coach them, help them understand and help them talk - the talking and the walking needs to be done by the team.

Let’s see how this one unfolds.

Next Group - Session IV

The session started of on a low key note. We had to phone two participants to remind them that we are having a session. Another participant was ill and could not make it to the office that particular day. And yet another participant [especially when he happens to be the CTO] had some urgent work and was not be able to attend the session. However, the session picked up pace primarily because of its relevance to the developers directly. We talked about the Engineering Excellance in Agile teams - shared code, evolutionary design, unit testing and refactoring. Over the last session that we had conducted for the first session - we included some more information on unit testing - especially the NUnit framework and some more examples of code refactoring. The key idea seems to have gone down well. The participants were aware getting to an understanding of what “done” means and how these practices affect the estimation.

After the session, we identified responsibilites for each individual and asking the participants to take back the knowledge from the session to their teams and report/ interact next week on their experience. It would be fun next week.

Sessions Restructuring

Some important scenarios have taken place with the sessions this week.

1. We have decided to stop using the polls for gathering feedback. We would rather talk to individual people one on one to get a feel of what they think and what problems/ issues they face while implementing SCRUM. We started with two developers this week and plan to continue with others next week.

2. The first batch who were continuing with the communication/ team building sessions - completed their sessions. There is no concrete result out of the batch. One of the developers has left. Only two of the participants are trying out SCRUM in their teams/ projects. All others are sitting and waiting for things to happen.

3. The Next Group or the second group is also completing their 4 sessions.

We have tried to restructure the participants for the next sessions. The dot.Net developers/ managers would attend on session and the other session would be probably a hybrid of all other participants. We would be allowing time for some participants from the first session to understand, grasp and implement their projects using SCRUM. And will come back with advanced sessions for these developers in future. Hence, what we would be having would be two sessions - one is the Next Group [with two participants from first group attending sessions with this group] and another a totally fresh batch where sessions would start all over again.

Watershed Week Continued

One watershed week followed by another. Can it get any better?

The last week saw us conducting a session for Project Managers and turning skeptics into more skeptics and some skeptics into curious onlookers and some firmly into the SCRUM backyard. The long 3.5 hours session focussed on Agile principles and SCRUM introduction and dispelled many myths. It also gave birth to interesting conversations where insecurity in project managers came to the forth. Further, it also separate the men from the boys and women from the girls. However, the participants do not seem to have grasped all there is to SCRUM. We would need more innovative ways to overcome fear and get a good understanding of SCRUM principles.

The last week we also started a new project called ProjectM. This project would allow us to start a software that supports the SCRUM framework - project backlog, sprint backlog, tasks, team collaboration, obstacle lists and knowledge sharing. I will discuss more details on this project in the future weeks.

Its getting exciting. The real action is starting only now.

Next Group - SCRUM Session III

The third session for the second group was heavy in theory and discussion. There were no practical exercises which the group completed. Rather, we had discussion on the role of Product Owner and SCRUM Master. It was a wonderful moment when noe hour into the theory - the group suddenly came up with a suggestion to identify the Product Owner and SCRUM Master in our context. What followed were understanding of the principles of Agile and SCRUM. The team went ahead to identify the issues they face in their projects. The team was airing issues and hoping that someone else will solve these problems. When this was brought out that it was for the team to solve these problems - most of them did not get how to solve these issues. But thats what the paradox is - the teams have to identify the issues they are facing and how they are going to solve them. The teams seem to be on their way. Almost all the teams working on the project are tracking their requirements and working in fixed sprint lengths. Lets check if the teams are documenting any obstacles that they are facing as well.

Alas sometimes more the things change, more they remain the same. We only have 3 people responding to our poll so far. Lets see if we can get more people to respond to the feedback next week.

Next Group - SCRUM Session II Feedback

We got 4 out of 7 people to respond over the last week. We never envisaged that getting the people to provide feedback. Despite personal requests, participants are a little reluctant to provide feedback. It could just be fears that their responses are being tracked or plain indifference. However, we have to identify what we can do for these people to shed their barriers and seapk up. This task is yet not complete and we need to focus on how to complete this.