Business people have trouble with agile. Consider this recently-overheard exchange:
Business: It seems like [the project architect] just wants to do the bare-bones necessary.
IT Guy: That's his job.
A valid point that was brought up was that this sometimes results in delivering functionality later than originally planned. But I'd point out that 1) this happens all the time in software anyway and 2) the functionality is often prioritized below bug fixes (sometimes rightly, sometimes wrongly).
Something I like about agile is that you only write the functionality that's needed, as it's needed (and ideally you've written previous functionality well enough that it's not very hard to refactor).
Another thing I like is that it recognizes that there's only so much time to spend on anything, and the business has to be frugal about what's needed, or the project will run out of money before finishing basic functionality. This can, however, be difficult for business people.
On the other hand, developers used to the waterfall approach (or other non-agile methodologies) tend to over-develop out of habit. (Sometimes I even find myself doing this.)
Production-ready code at the end of each iteration is good.
Good merge tools are worth it. (Not agile-specific...)
QA and UAT should be integrated ASAP (how else will you have production-ready code at the end of the iteration?).
Despite what Dilbert's Pointy-Haired Boss says, it's not "start coding and complaining" (though we do code a lot, of course, and complaining is the developer's past time).
I'm going to try to apply some of the agile/scrum practices to other areas, like DPO (though I'm not going to tell them that's what I'm doing).
No comments:
Post a Comment