Introducing agile practices in a subproject only?

Question

Imagine you work as a contractor in a large project involving multiple systems, and you are creating one of them. The whole project uses a traditional process, but there are smells that tell you that an agile process would be much better.

Now the question. Does it make sense to introduce an agile software development process in your own group only? There is no chance to change the whole project, but you might perhaps change the process in your own group.

What would be the major benefits and pitfalls of such a local process change? Are there specific agile processes that would work good in such a case?

Answer 1

Read Effective Ways to Introduce Agile into the Workplace and Joel's seminal Getting Things Done When You're Only a Grunt.

Beyond that it's probably mostly marketing/expectation management with your superiors and customers. Both of which might resent investing in the various agile customer-inclusion "games". Both of which also might resent the "new-fangled" way of doing things.

Answer 2

I think the answer depends how isolated you can be from everyone else's process. If they just tell you to go get your portion done and come back with a completed widget, implementing Agile locally should be relatively easy. If, on the other hand, you are expected to follow lots of random dates and procedures, it will be more difficult.

You'll have to be flexible and make sure that whatever sprint cadence you have lands on similar dates to the rest of the system. You'll have to plan out your sprints ahead because the central planners will probably want an all-up feature list early and won't stand for the more laid back Agile approach. Just be conservative about what you'll deliver and you should be fine.

The advantages should be the same as the advantages Agile has elsewhere.

Answer 3

This is an interesting scenario. I had a similar situation years back, and I'd say doing this essentially doubles the project manager's (your?) workload. You will need to play double face, with one set of cards towards the customer and one set towards the developers.

If your developers are GOOD, I would go for it. If they are not, and would require kicks and handholding, be careful. If they are good but may get carried away to their own agendas, be firmly in charge.

It is sometimes funny how organizations with traditional project model emphasize minor features, irrelevant to the developer's mind, and completely ignore the real hot spots. I still don't get it - maybe it's plain stupidity and nonprofessionalism. Expect that.

And do remember test based approach is the heart of Agile development. Do tests first. This will be peculiar to the customer, but they will benefit in seeing how the subproject actually proceeds. You might get less "progress" early on but more at the final yards.

Answer 4

Here's a great diary of how a guy changed his whole company towards Agile over a period of a couple of years - yes, starting with his own subproject, i.e. "bottom-up". But he does go into the pros and cons of trying a "top-down" change.

http://jamesshore.com/Change-Diary/

Very entertaining and intruiging stuff.

Answer 5

Depends on your motivations, and what you aim to achieve.

Pitfalls: the major one is that agile development works by increasing visibility. Thus, adopting agile practices in one sub-project, if the effort is at all successful, can lead to exposing issues that affect the whole project, resulting in a risk of backlash. Keep in mind the parable of the two envelopes.

Which practices you take on first depends on how you want to handle this risk. If you start by adopting the planning-related practices (task board, release plan, user stories, velocity) matters may come to a head relatively fast.

Ditto, more or less, if you start with practices in the area of requirements (user stories, automated acceptance tests).

If you start with internal quality (test-driven development, refactoring, continuous integration) you may improve the motivation of the developers on the project, at the risk of not necessarily mattering a whole lot in the larger scheme of things.