In an Agile environment, you are likely keeping in mind the following 3 Agile principles when working.
Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
Working software is the primary measure of progress.
So if asked to make a feature, say Feature A, you split the work up into smaller, working, and deliverable pieces. Keeping also in mind the simplicity principle,
Simplicity--the art of maximizing the amount of work not done--is essential.
you decide to split the work so you do the simple but useful things first:
- Feature A1: some subset of the final feature set that is useful but simple and quick to code up
- Feature A2: an extension of A1 delivering all the required behaviour and complexity
After you've done Feature A1, keeping in mind the Agile principle
Business people and developers must work together daily throughout the project.
you demonstrate the functionality so far. Then comes the feedback
This is great! We can really see how this solves our problems. Feature A1 acheives 90% of what we need. The last 10% from Feature A2 is quite low priority now, and we're even talking about never doing it. Instead, can we make a start on Feature B?
Fortunately, when coding up Feature A1, you also kept in mind to
Welcome changing requirements
so you didn't make a start on the complexity for Feature A2 because you suspected the requirements would change after Feature A1 was seen by the business people. You also kept in mind
Continuous attention to technical excellence and good design enhances agility.
so you didn't make Feature A1 in any way a hack: it is safe, tested, what it does and why it does it is extremely clear, and there isn't any unnecessary code. You have spent no time working on something that isn't useful, and you could not have given the developer of the next feature a better gift.