Archive for Change

When Should You Implement Scrum or Agile?

Posted in Agile, Change with tags , , , , , on August 19, 2009 by vikramadhiman

Are there circumstances that are more favorable for implementation of Agile and Scrum and ones that are not very favorable for its implementation. Generally, the ideal conditions for implementation and spread of Agile/ Scrum in an organization depend on the market and customer scenario, rather than the development team scenario. Some such factors or conditions include:

  1. Unclear product direction or a research oriented product – the fact that the direction is unclear, makes you plan only for a small time in the future, when you reassess and reorient
  2. Too many changes/ feedback too often in the product – again this means that you take the minimum [agreed, clear or consensus] work – complete it – get feedback and move from there
  3. Competitive industry/ market scenario – this generally would mean you have to get the features out to the market sooner rather than later as well as have more customer connect in the product [some will argue this should be the case anyways]

There are some factors at organizational end as well, which can impede/ aid the Agile Implementation. For instance, if there is no management buy in, or team buy in or worse if there is no customer buy in [in service industry scenarios]- it will be hard if not downright impossible to implement Scrum, Agile or any other framework. In addition, where a deliberate slow and assured pace is mandatory [think software for nuclear reactors or space ships] – there might be significant overhead. Hence, small increments or sprints might not be possible in such a scenario. Turning, this around, you should go all out to implement Scrum or Agile, if:

  1. There is a relative buy in at all ends – customer>>management>>team [not necessarily in this order in all organizations].
  2. The cost of a single bug is very high.
  3. Everyone understands or make attempts to understand what is Scrum or what is Agile.

When you combine the outside [market/ customer] conditions with inside [organization] factors – you get a ripe condition for implementation of Scrum or Agile.

Change is Difficult

Posted in Change, Coaching at Net Solutions with tags , , on January 27, 2007 by vikramadhiman

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

Developers vs Managers – Part A

Posted in Change, Coaching at Net Solutions, Collaboration with tags , , , on January 14, 2007 by vikramadhiman

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.

Random Thoughts – III

Posted in Change, SCRUM with tags , , on December 24, 2006 by vikramadhiman

SCRUM empowers people.
SCRUM provides visibility.
SCRUM exposes people.

How do you handle all this?

We have already had problems where we identified one project manager as being the bottleneck in getting the team to an optimum level. We are staring at another project manager who has his ideas and thinking in old style management – control and direct. Two-three developers who work in his team are feeling a little restless because of the expectations that the sessions bring on them and the expectations of their reporting authority. The typical knee jerk reaction is to fire or move and shuffle teams. However, what is delaying this is probably because finding experienced project managers is very difficult. And finding experienced project managers who want to turn Agile is even more difficult. We are trying to convert project managers through trainings and hand holding. However, the jury is still out on this. Any process change does provide for lot of churning – however, we would try and keep this churning to churning of mindsets and not people.