I'm not sure what distinguishes "method introduction" from any other organisational and cultural change - probably nothing. People are always somewhere and moving to nextwhere, both in their business project [deliverable] and in their worklife project [learning]
Fluency - in a fluent team, people know what they are doing and why, and can reflect on it in order to improve it (where improvement includes drastic change if desired). This is where things really get done.
large organisations - over 1000 people in IT - with a culture - usually waterfall, based on long experience of slow IT and business change - often pretending they use RUP (or wanting to)
medium-sized projects - 30 to 100 people - probably could be smaller, but only if everyone learned to work differently
long-lived projects (or - programmes of projects) - 5 years - not because they are slow (necessarily) but because of business learning and change; responsibility shifts from the development organisation to a service delivery group
transactional, high integrity systems (money) - can't make too many mistakes, and none that last
insurance company - claims system - problem - "how to use Java effectively to build this system (and others that follow)"
· developed artefact-based method with them; mentored them on iterative working
· mid-weight (about 30 artefacts in total, felt empowering to users)
· highly devolved structure (method essentially built by teams in each domain, led by experts; consensus managed carefully)
· what happened to the method (everyone liked it more the more they used it; a stroppy Java programmer changed his mind completely; everyone very tuned in to both using it and thinking about improving it; still very keen 12 months later)
· what happened to the project (delivery deadline shifted late on and method ditched - delivered on (new) time but quality visibly suffered and the team was very upset)
investment bank - back office processing - problem - "how to improve design and processes to make development faster"
· got practitioners to build artefact descriptions that included best practice; mentored them on everything (created automatic buy-in; key ones were conceptual (analysis-level) model agreed and understood by everyone, requirements)
· struggled with requirements and testing (requirements essentially rule and mini-process based, complex interactions; unit testing easy but test in deployment environment (Java on OS/390) very cumbersome
· what happened to the method - desire to expand its use to testing and deployment
· what happened to the project - still too little iteration - very happy with method - delivering OK but with heroics)
·
various other smaller things - with IBM and client projects
Why
didn't you just get them doing XP?
· too many constraints on interworking with other teams and asset owners
· code too detailed for people to hold in their heads as the design or requirements
· cumbersome delivery environment so daily builds can be done but daily test/deployment can't
· no sponsorship/leadership for major change while project under business pressure to deliver
So
argue your point
· the teams became more responsive, more effective, and also more aware of other possibilities
· the bank team is now ready for two changes, in requirements (getting business and developers closer) and test/deploy (rapid build/test). Both these are quite political and also technical
it's possible to make a difference - you get to real agility by working out, moving from lumbering to walking to running - before leaping and dancing
how to work with the people (my way) - it's no good inventing method and trying to sell it to a group - they have to create it themselves; the method has to build on the knowledge of the team(s) - building a community of practice around knowledge is key; a method needs a story, so that people can see that it's going to be worth the journey; a transition needs a leader to hold the faith (and occasionally punish the sinners)
what
to do about method
· separate artefacts from process, as artefact descriptions (purpose, notation, hints and tips) are easier to share than processes - this way you can get to a minimal set of artefacts for a project, something people can share, gather round, argue about, put content into - you do need some artefacts to hold the state as people come and go from the project
· it's hard to shift from waterfall to iteration, that's the process change that people find difficult - partly it's about fear, stepping out "before I'm ready", but actually, they never were ready anyway, just fed up or forced to move on by time pressure, or ready but too late for the business
· we have to get to our architecture early on - inception->elaboration->construction is right (RUP terminology)
· stories provide the end-to-end "things" that we can work on and implement in our iterations - we may cut bits out but I don't like "features" here
more of the same, but with larger scope - revisit the bank, cover other angles
work with a smaller team - have a chance with a small product company (too small for IBM to care about!)
When people tell me they are doing x, introducing X, moving to X - I never quite believe it until I see it - I wonder just what they mean - I watch the practitioners at work (including management) - I usually see some training and no leadership