Implementing agile practice in a subproject only?

Question

Imagine that you work as a contractor in a large project involving several systems, and you create one of them. The whole project uses a traditional process, but there are smells that tell you that a flexible process will be much better.

Now the question. Does it make sense to implement a flexible software development process only in your own group? There is no way to change the whole project, but you can probably change the process in your own group.

What are the main advantages and disadvantages of such a local process change? Are there special flexible processes that would work well in this case?

Answer 1

Read Effective Ways to Implement a Flexible Workplace and Joel seminal Getting Things When You Are Just Under the Ground .

In addition, it is probably mainly marketing / expectation management with superiors and customers. Both of them may object to investing in various flexible consumer "games." Both of them may also resent the “newfound” way of doing things.

Answer 2

Here's a great diary on how a guy changed his entire company to Agile for a couple of years - yes, starting with his own subproject, that is, bottom-up. But he goes in the pros and cons, trying to change the “top to bottom”.

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

Very interesting and intrusive material.

Answer 3

I think the answer depends on how isolated you are from everyone else. If they just tell you to do your part and come back with completed widgets, implementing Agile locally should be relatively easy. If, on the other hand, you have to follow many random dates and procedures, it will be more difficult.

You need to be flexible and make sure that in any sprint cadence you have land on similar dates with the rest of the system. You will have to plan your sprints ahead because central planners will probably want to get a list of all the features at an early stage and will not advocate a more delayed Agile approach. Just be careful about what you will deliver, and you should be fine.

The benefits should be the same as those of Agile elsewhere.

Answer 4

This is an interesting scenario. I had a similar situation over the years ago, and I would say that this substantially doubles the workload of the project manager (yours?). You will need to play a double face, with one set of cards in relation to the client and one set for developers.

If your developers are GOOD, I would go for it. If this is not the case and you need kicks and a handshake, be careful. If they are good, but can get carried away with their own agendas, be firmly responsible.

Sometimes it’s funny how organizations with a traditional project model emphasize secondary functions that are not related to the developer's mind and completely ignore the real hot spots. I still do not understand - maybe this is just stupidity and unprofessionalism. Expect that.

And remember, a test-based approach is the foundation of Agile. Run the tests first. This will be peculiar to the client, but it will be useful for them to see how the subproject works. You can get less “progress” early on, but more on the last yards.

Answer 5

Depends on your motives and what you strive to achieve.

Traps: The main thing is that agile development works by increasing visibility. Thus, the adoption of flexible practices in one subproject, if efforts are successful at all, can lead to the identification of problems that affect the entire project, which leads to the risk of a negative reaction. Keep in mind the parable of the two envelopes .

What practices you take first depends on how you want to deal with this risk. If you start by adopting planning practices (taskbar, release plan, user stories, speed), questions can quickly develop.

More precisely, more or less, if you start with practice in the field of requirements (user stories, automatic acceptance tests).

If you start with internal quality (test development, refactoring, continuous integration), you can improve the motivation of developers in the project, risking not necessarily being of great importance in a wider scheme of things.