When I started working for a software house our work was mostly made up of building and fixing, we were told what to build, didn’t do it very well and spent most of our time fixing it. If we delivered, it often turned out to be the wrong thing, but we left it there just in case, making future development harder. Fixing systematic issues was ignored in favor of fire-fighting, there was no time for improvement. Today our daily activities are a bit different so I thought I’d try to break them down
So what is it we do:
Discover
We spend most of our time in a state of discovery, this happens through conversations with each other, stakeholders and users, but most of our discovery happens, if we let it, from the build and delivery.
Build
We do it early because it’s an important part of discovery and enables us to deliver. Building something useful is our purpose but we build in such a way that we can adapt our design as we discover better ways of doing it.
Clean
If we are free to build rapidly we need a clean environment to build on. Cleaning activities include refactoring, automation and general removal of problems: day-to-day, social or systematic.
Deliver
We deliver often because the feedback leads to discovery.
Fix
If we discover the right thing to build and our code and environment are clean there isn’t much to fix
So. What’s changed? A mindset that values discovery, brought about by the realisation that we cannot know till we try. Discovery happens naturally if you let it, we soon discover that keeping clean is more effective.
Diary of a ScrumMaster 
Another thing that really helps avoiding the Fix stage is that in the Discovery phase we get the opportunity to question why something is required (and vice versa). This questioning process itself can lead to less complex solution and also leads to a much better understanding of the intention so we can write the right code.
We used to write code to cater for all sorts of things that “users might want”, now we write code to satisfy what we know is required, avoiding unnecessary complexity that is costly to maintain, then enhance as we get feedback.