Oliver writes:
I become frustrated at trying to introduce more innovative methods of software development at the large IT consulting firm I work for. Are there any methods to trying to get 1980’s waterfall lovers to even think of rapid development techniques as anything but “silly crap suitable for start-ups but with not place in Real Development Companies” (paraphrased), or should I just quit and find somebody more exciting to work for?
Most people fear change because they overestimate the risks and underestimate the gains. If you want to convince them to change, you have to address both issues.
In my experience, the only way to address the perception of risk is through first-hand experiences that Nothing Bad Will Happen. Anecdotal, or even hard, data rarely sways anyone unless they’re already in a desperate situation.
So pick something small in your organization. Internal systems are usually a good fit. The worst that could happen is usually that you’ve wasted a little time (and organizations running waterfalls should be intimately experienced with wasting time for much less noble causes). You don’t end up looking foolish to clients (a common fear).
Pitch this system as a test balloon for another way of doing things. To smooth things further, you could throw a boon to kick it off the ground, like “Peter and me will come in on Saturday to set everything up for this”, so that you reflect that you have some skin in the game too and that you care.
Odds are that people will like how things work on the test trial (i.e., they’ll start reevaluating the gains). They’ll appreciate that you’re working in iterations, how quickly you can adapt to changes, and how enthusiastic people on that project seem to be.
If all goes well, this will lead to “why can’t we work like this on project X?”. Maybe this call won’t come from top decision makers right away, but it’ll come from anyone else who’s been exposed, and it’ll hopefully start an internal debate based on first-hand experience.
Then again, maybe it won’t. But at least you’ve given it a shot, so you won’t feel bad at all when you hand in your resignation and move on to a place that provides a more rewarding work environment.
Anonymous Coward
on 01 Oct 07My experience is that this doesn’t work, but it probably has a lot to do with the managers I’ve had to deal with.
One of the things the waterfall model provides is the illusion of control. In theory, the manager says, “let it be thus,” and the developers scurry around fulfilling the manager’s wishes. For a certain type of manager, this illusion, even if it results in useless garbage software, is so much more satisfying than any alternative; if you have that kind of a manager, your best option is to polish your resume and consider the dual meanings of Change Your Organization.
I followed your recommendation (before it was your recommendation) at a former place of employment; built an internal system using agile practices, and asked end users to request new features by filing or commenting on bugs. It worked brilliantly, and I managed to get a lot done. In particular, there was a lot less wrangling about requirements, because I would put up my best guess and get useful suggestions rather than trying to get a specific description of the desired behavior up front, and end users were thrilled about the responsiveness, because I could ask them what features they really needed and deliver them in the next iteration. Still, the only reason it worked at all was because it was a low-status internal project that managers didn’t feel the need to put their fingerprints on: there were no manager points to win by being the one who dictated requirements, so nobody put in the effort.
ML
on 01 Oct 07You might also want to check out the intro to Getting Real which contains a counter to the claim “This won’t work inside my company.” Excerpt:
sandofsky
on 01 Oct 07My first real job out of college was at a large company that got little got done, and what was done was terrible.
Our senior developer fought hard to change things, but I watched her frustration eat her alive until, months of misery later, she finally quit.
Her mistake was trying to change people.
Yes, take a shot at educating them. Educating, not changing. If they still cling to their ways, waterfall is only a symptom that they don’t share your values. You won’t be happy until you’re out of there.
Geof Harries
on 01 Oct 07For lack of a better term, I’ve found that getting yourself an upper management sugar daddy on board is more economical than trying to run everything yourself.
Having someone with major sway who wants to fly the same flag will allow you to circumvent much of the corporate red tape and just get the job done.
I used this process for pushing a web analytics agenda (what? we need to track and measure what we’re spending on advertising?! crazy!) to great success. Sugar daddies, that’s where it’s at.
Carl
on 02 Oct 07One of the notions of Outside-in Software Development is to introduce some of the values of highly agile development (e.g., focus on client / stakeholder interaction, consumability of the product, etc.) in a way that can work in a waterfall model.
Thing is, a less waterfall model will work better for many projects, but instead of introducing agility / iterations (scary for many folks in a waterfall culture), it introduces small steps that add visible value even in the waterfall. The expectation is that teams will see this value and be encouraged to move – however slowly – in an agile direction.
James
on 02 Oct 07There is a saying in IT (paraphrasing) ‘No one ever got fired for buying IBM’. The same is true with dev practices. Truth be told, switching to agile methods is not a silver development bullet. Often the practices work only when everyone on the team (from devs to managers) gets it and works towards it. On a large team of older programmers and managers who have shipped really hard and long projects – asking them to change is almost selfish.
Not to get too philosophical, but this is why capitalism works so well. If a start-up with new practices out preforms an old model it will naturally supersede it. Some companies (google comes to mind) foster a start-up atmosphere within themselves to try and benefit from this creative energy.
Just don’t be surprised if the theoretical model which seems so good on paper fails to deliver. The majority of new ideas are bad ones – don’t blame your company for being conservative.
Jon Vaughan
on 02 Oct 07I’d get another job. There are plenty of big firms following Agile development methodologies these days – and anyway, if its the sort of place where new ideas aren’t welcome, do you really want to work there?
Nik
on 02 Oct 07I agree with your advise David but with a slight change in where to apply it.
Having worked on a mgmt consulting shop with insight into how IT consulting firms behave you will almost have no chance to implement the advise in internal systems. You are billing and invariably travelling to actually make a pitch to the internal IT group (which is an ocean away).
I would reccomend that if you are in a position of authority (Senior consultant or PL/PM type roles) to have a smaller module where you can follow an iterative approach. The institution is far likelier to accept the iterative approach in a smaller piece.
For e.g., Almost all large IT projects have a reporting element to whatever you are building. In my opinion reporting is perfect for an iterative approach instead of the VERY long process of specing a report. Maybe, you just build a report, take it to the client and see if they like it. If they don’t you can go back and ask for more feedback.
You are likely to make every one happy. The client, the team and the partner.
Mad William Flint
on 02 Oct 07See this is interesting, because I’m having the opposite experience. I just became our internal Agile champion and am moving into a coaching role.
We have “management mandate” to push for Agile practices, iterative development, etc. without having to shove it down people’s throats.
My BIGGEST resistance is the developers and QA teams themselves. The “bunch of crap” mindset is all over the place. I get alternating “prove it” and “yeah, but that’s a contrived example” (when it’s their example I started with.)
I no doubt have to change my approach somewhat. But I’ve been pretty solicitous about where the challenges are and what I’ve found is that in many cases, what they’re looking for in these sessions is not to learn, but to shoot down something they feel being thrust on them.
v. strange.
Jan
on 02 Oct 07James Shores Change Diary might offer a bit of insight into such an endeavour:
Jan
on 02 Oct 07I messed up the link somehow: http://www.jamesshore.com/Change-Diary/
Michael Schubert
on 04 Oct 07Oliver, you could always apply at ThoughtWorks, an IT consulting firm that doesn’t do waterfall. ;-)
But seriously (well actually that was serious too but I’ll give some other answers)... change like that either requires a champion at the top to give an agile project a chance or you have to carve out enough of a team to give it a go… but in doing that you will have eyes on you and if the project fails it will probably be seen as a failure of agile… regardless of the real reason for the failure (and god knows projects can fail for so many more reasons than process).
If you really want to stay I’d suggest very slow and gradual change (as others have here). Find a small, perhaps non-contentious piece to bring in… and more specifically target making change in just 1 aspect of waterfall… bring in continuous integration and perhaps TDD to development where you can argue for the value of improved development quality and team cohesion. If it is a new technology, ask to do pair programming on the merit of knowledge transfer to members across the team. Ask to do “spikes” (quick throw-away code prototypes) on requirements gathered early on to increase accuracy of development estimates.
If you going to go and try and change the beast you have to make little tweaks and twists in small ways that are not seen as an attempt to change the status quo, even if that is your eventual intent.
And remember, agile only works if people want it to work. If your heart or head is against using it, and that goes for anyone on the team, the process will suffer and it will seem like agile isn’t work… it might be fine… it is the people who aren’t.
Cheers.
Franck
on 05 Oct 07Changing an organisation, furthermore a large organisation, is a often a very difficult task, because you face many “people” issues. There is a very interesting account of this journey presented by Joe Rainsberger at the Agile 2007 conference: “My Greatest Misses: XP 2000-2007“ (http://www.agile2007.org/agile2007/downloads/handouts/Rainsberger_414.pdf)
Stephane
on 07 Oct 07I have found this book very interesting : “Fearless Change: Patterns for Introducing New Ideas” (Addison Wesley).
Simon Kiteley
on 08 Oct 07Found myself in this situation most of my working life and the funny thing is that for quite a few of them I was supposed to be working in dynamic, cool and hip companies… how some companies like to kid themselves.
I found the following three quite useful but be warned its hard work and only some of your good work will stick. The bits that do will become part of the way of working at a particular company no matter how made they thought you was when you introduced the idea.
1) You probably actually do already do some reasonably sensible rapid/agile development behaviours. Though they are done when the project has already failed and everyone goes into panic mode by doing incremental releases.
Try to get some of these behaviours started earlier when things are less of a panic. Say lots of things like “gosh, don’t we make a lot of progress while doing these increments, we should do this earlier in the lifecycle.”
2) Start doing your process or method yourself but try to fit it in the existing process. So you are going to do increments but your test team won’t until a couple of months before the end of the project. Well let them know it is ready and when it is ready and someone will test it early (by accident maybe) and get to like being able to tell you about your bugs a few months earlier than usual.
I have often also found that when you are better to your internal customers, either because of better quality (documents or) code they it comes hard for your manager to undo your good work without getting it in the ear from internal and external customers.
3) Get a consultant, either young and bouncy or older and in a suit… not sure it matters to come to your company and point out what you already know to your boss. Even though this will help to get the boss fired up you need to be quick before the new mission statement becomes high priority again.
This discussion is closed.