Re^2: Beyond Agile: Subsidiarity as a Team and Software Design Principle

I see Waterfall as an unsuited methodology for software development. I see Agile as an improvement. In my experience, Waterfall does not work well because requirements are rapidly changing. Yes they are. Yes they are.

The idea is to simply decrease the amount of time it takes to deliver features and fixes by reducing the iteration cycle to adjust for these rapidly changing requirements we software developers face. Stake holders must be on board, for it is they who sign off on which features and fixes to prioritize. Automation and tests with high value are also key.

But let's check some history, shall we? Read up on Winston_W._Royce , the important quote i wish to point out is 'According to Royce in the process model "the design iterations are never confined to the successive step", and for that model without iteration is "risky and invites failure". As alternative Royce proposed a more incremental development, where every next step links back to the step before.'

And isn't that what Agile strives to be? More incremental? More immediate feedback? This is just evolution of software deployment.

jeffa

L-LL-L--L-LL-L--L-LL-L--
-R--R-RR-R--R-RR-R--R-RR
B--B--B--B--B--B--B--B--
H---H---H---H---H---H---
(the triplet paradiddle with high-hat)

Comment on Re^2: Beyond Agile: Subsidiarity as a Team and Software Design Principle

Replies are listed 'Best First'.

Re^3: Beyond Agile: Subsidiarity as a Team and Software Design Principle
by einhverfr (Friar) on Jul 22, 2015 at 00:08 UTC

I see Waterfall as an unsuited methodology for software development. I see Agile as an improvement. In my experience, Waterfall does not work well because requirements are rapidly changing. Yes they are. Yes they are.

But they aren't always. Consider embedded development of computers controlling cars, or things like control software for radiotherapy. Bugs there can cost lives and the requirements are well defined, so full-blown waterfall processes are appropriate.

Moreover they aren't rapidly changing for all parts of a project. Usually with a little experience you can identify those areas where requirements are likely to change most. If everything else is well componentized, up-front design really isn't a bad thing. And if the components are small, iterations don't need to be long.

That's why subsidiarity is important, because it focuses on the design and development of small components by small teams, not big nebulous projects by very unstructured teams. A project may have a part of that but the more contained your rapidly evolving requirements are the quicker you can deliver them.

[reply]


Problems? Is your data what you think it is?
	PerlMonks