HI Michael,
This is a good question as this is a general challenge which agile teams face. Being in the software industry for over 15 years, i use the following approaches to succeed.
1. If the development team opposes scrum, it is purely due to fear of micromanagement and status pressure which they have to give every day on the morning scrum updates. So in our company we had followed an adhoc 2 releases a month or sometimes a release in 2 months which was non consistent. I straightened this by making one release a month and reduced the developers burden of unwanted releases and so they started liking the agile scrum model.
2. From the end users or the business customer, it is always pressure of no time to answer developer questions or lack of leadership in the business support for them. So i educated the leadership about the importance of time to answer the questions and i made a weekly fun date for an hour where the developers and business will colloborate to flush out the stories.
3. Sometimes with old school business analysts , conventional waterfall model with usecases is liked a lot. You might have to educate the business analyst on writing stories with less information and more on entity impacts which is what the developer is looking for.
So to summarize what i am saying
1. Educate the value of scrum to the current team by identifying the pitfalls on the current approach.
2. Remove the fear in the minds of developers on the scrum by focusing on the positives.
3. Rally the leadership by defining key performance indicators like time taken for releases, bugs on each release, requirements errors, delays on requirement times and business roi.
If you need more asisstance, please feel to drop me an email at buyan@thylaksoft.com .
Thanks
Buyan

Links:

• http://www.thylaksoft.com

posted July 9, 2010

In my opinion it cannot be done without the support of the marketing/sales/business teams. Otherwise you are just setting your team up for frustration, conflict and eventually failure.

posted July 9, 2010

The best way to implement an Agile system in an organization with a Waterfall-oriented approach or chain of command, is by putting solid barriers in place and having some degrees of isolation between the development environment and the marketing, management, legal etc. departments. Departments like finance and legal do not need to be agile. They are just supporting departments to your product development department. Resources such as business analysts, qa etc, come on the development side of the company and so must be agile for the process to work. So agile rules need to be enforced in that case. A good way to start being agile is by implementing pilot projects with the new methodology. If it works, it will naturally be noticed by the 'elders'. In any case, for a methodology to work, a good leadership goes a long way. So I would start by communicating the process with the managers and see how it suits the environment in question.

posted July 9, 2010

Careful attention to the Roles of the Product Owner and the Scrum Master can allow an agile team to embed within a less than agile organization. Ultimately, though, this is not an ideal fit, and one or the other will disappear in time. Hopefully it will be the less-than-agile aspects of the enclosing organization that give way, persuaded by the promises that are met by the agile team embedded within their organization. This works fairly well when the organization is neutral. However, where the organization is anti-agile I would recommend moving yourself to a different organization, let this one die in its own time.

posted July 9, 2010

I have had great success with Scrum, even in a Scrum hostile/ignorant environment.

I assume that when you state "succeed with Scrum" you mean from the perspective of product delivery rather than from the perspective of having the whole organisation adopt an Agile approach.

I suggest, for example:

* Keep Scrum terminology within the Team;

* Communicate with the outside world in language they understand and appreciate. Ideally, this language is neutral (i.e. not explicitly belonging to any methodology);

* Adapt your use of Scrum according to any necessary constraints of your customers – you must make your customers happy (e.g. producing a simple Highlight Report if it’s really wanted);

* Enable your customers, and other stakeholders to enjoy and appreciate the benefits of Scrum – e.g. collaboration, rapid delivery, frequent and regular progress, without feeling the need to inform them about Scrum;

* For the time being, Scrum can get along brilliantly as a marvellous little black box;

* Allow the realisation that the methods are Agile and Scrum emerge naturally, when the benefits are familiar, proven, and undeniable;

* Avoid debate or argument, let results speak for themselves in due course;

* Wait for the organisation to demonstrate their curiosity about Scrum and then enthusiastically answer their questions.

posted July 10, 2010

Open yourself up to if it is even the right approach to the problems you are attempting to address. Perhaps you need to morph your approach to conform more smoothly with the needs of the other parts of the organization. Remember, you are attempting to solve their business problems, they are not there to support your usage of one development methodology.

posted July 10, 2010

I have personally had to deal with this from two perspectives (on the same project!) - a development group that was located overseas (I am in the US) and business functions. I had to use a variety of tectics:

1. First, I recognized that pure Scrum was not going to be an option. Some Scrum masters would ridicule my approach as "Scrum-but" (am I missing a "t"?) but until the technique proved itself, this amount of change was not reasonable to expect.

2. On the business side, I never used the term Scrum (in agreement with Dave's comment). I used the terms "low hanging fruit", "collaborative efforts" and "quick hits" a lot. And I asked for help, explaining that I really did not understand the business as well as my counterparts, but I was willing to learn in order to be helpful to them (i.e., I put my pride on the back burner).

3. I worked in business areas that I understood best, first. This way, when business users were not available, I could step in and play the "Product Owner" role (although I would always review those decisions after the fact with the true product owners).

4. In dealing with the developer skeptics, I always had detailed budgets and objectives. Yes, I changed the specific work packages frequently, but also was able to convey a clear vision of what needed to be done (with the help of my business allies). Also, these non-Scrum developers were treated differently than the Scrum team and as a contraint in our development (again, until this was proven, this was too much change to ask).

5. Finally, I used a lot of contractors for my Scrum development team. Basically, I let them know what I was doing and why I was doing it. As they were not nearly as threatened by this, they were much more willing to experiment.

With all of this, I'd say compared to other Scrum projects, the team's productivity was average, at best. But compared to previous efforts, the amount delivered in a relatively short period of time was significantly improved, and led to many questions about some of the processes that had been in place.

posted July 10, 2010

Your problem is like an iceberg: only a small part is visible.

Problem 1 - Scrum
Even the context is ok, using only the Scrum (sub-) method does not mean you are working Agile! You shall be able to cover all the development disciplines with agile practices and follow Agile Manifesto Principles. Scrum does not cover well the engineering disciplines. Try also a combination with XP and other Agile methods.

Problem 2 – Organization context not agile
In this case you will have some problems:
- some lack of understanding of the Agile process from the rest of organization
- possible lack of reserve resources (peoples with multi-disciplinary & senior skills )
You need in this case to establish an agile long-term strategy inside the company for the parts that use this methods and the management shall assume this strategy.
For the resource problem, you need to also build a strategy for managing this problem on long term bases.


Problem 3 – Organization context anti-agile
This is a bigger problem that problem 2. “Anti” Agile or “Anti” RUP by default mean a high misunderstanding of software development methodologies. A right process shall be iterative and shall be also derived from both Agile and RUP with a balance in one of the parts depending of the context. The selected method shall be always adapted to the context. That means a default “Anti” or “Pro/Always” has no logical reason.
The solution is (could be) first to make a basic training with the stakeholders and to adopt the methods incrementally and based on cost-benefits analysis.

Problem 4 – External context anti-agile
In this case perhaps is better to have a mix between Agile and RUP.

posted July 13, 2010