The other day I got a ppt from a friend who got it from someone else about a project in my company which is a “success” because how they implemented “agile methodologies” and how it helped and the practices they followed with general patting of backs and lessons learnt and improvements still to be made.
It’s a 75 slide power point.
Get the picture?
Or lets see the Extreme programming principles. On one hand embrace change and on the other you must follow x,y,z to have a successful project(with no guarantees of success). What happens if you don’t pair program or do test driven development or whatever else is the latest breakthough in software engg? Is it that you don’t embrace change?
I think agile is best described by uncle bob , “never be blocked”. And once you accept that, the agile manifestos, the programming principles the slide guides aren’t all that necessary. True they might help, but the problem is any rigid process (agile extreme or otherwise) causes blocks.
Write junits for everything. Unit test are really low value for money. Integration tests are very hard( especially if it’s a distributed system, developed by multiple disparate teams )over space and time. All the wonderful stubs and mocks so loved by the TDD guys fail when the stub and mocks are replaced by the actual system. Which isn’t to say stubs aren’t good, but they give you a false sense of security. And can hide flaws. For e.g. There was a defined web service interface. It wasn’t ready we mocked it. All was well. Till we ran it with real data. Turns out we get stuff like ##YOUSHOULDNTSEETHIS## the xml structure is the same , the web service has the same interface but surprisingly none of us thought to write stubs and mocks that returned elements with junk values.Or what to do in that case or even how to identify them.
You can and should violate principles if the need arises. That’s agile. Embrace change. a
