My company is in the midst of a transition from waterfall-style development to Agile/Scrum. Among other things, we're told that the expectation is for us to have new working, testable (by QA) features at the end of each day.
Most of our devs lose around 2 hours a day to meetings and other enterprisey overhead. This means that in any given 6-hour (at best) period, we have to design, write, unit-test, build, and deploy (with release notes) enough code to produce a complete feature for QA to play with. I understand that the build/deploy/release notes could be automated with a proper CI setup but we're not there yet.
We also have a large offshore contingent writing our server-side code, and the 12-hour time difference makes this even more difficult.
We attempt to task out stories into narrow, deep vertical slices in order to complete features end-to-end as fast as possible, but most days feel rather frantic and I often catch people taking stupid, fragile shortcuts to ensure QA has their build. This problem is compounded after a sprint has been in progress for a couple of days, when the inevitable defects start rolling in and have to fit into the same 6-hour window.
Is this a normal pace for Agile teams? Even if we manage to implement a CI setup, I can't see how we'll be able to sustain this pace and still create quality software.
Edit: There are several good answers here. It made me realize that what I was really asking is, should Agile teams deliver new features daily. I updated the title accordingly.
Best Answer
The crimes that are committed in the name of Agile these days make me sad. Lots of people are having a hard time making this transition.
Agile Manifesto: "We value people and interactions over process and tools.". When the people are clearly hurting, the process is wrong. I don't want to tell you how to do it, but will share how I do it.
In my teams, the important part is to avoid committing to a shared repo code that is broken in ways that will waste the rest of the team's time. In this sense only, I strive to 'deliver working code every day'. Don't break QA. Don't block other developers. Ideally I never check in any bugs. (ha ha).
The implication is not that you have to commit something every day. The implication is that you should only commit good stuff, so that each day you can get a build of all the good stuff that anyone committed. This way the team keeps firing on all cylinders.
In my teams QA is constant. I build commercial products, so the project is never over until the product is obsolete. QA Engineers test the features that are available to test. QA Engineers always have a backlog. There is never enough QA time to test or automate everything we would idealistically want.
If developers need multiple days before merging in changes for a feature or fix, it's fine, encouraged if it helps them get the code right before risking our time. Developers can commit code to their private repo or branch without affecting the team or QA. Developers can run unit tests or regression automation on code built from a developer's repo or private branch. On particularly risky cases a QA Engineer will work with the developer to test before merging, to protect the team from delay.
In this sense, I practice what your managers want. Almost every day for the last 12 years my development teams have had code that works in the shared repository. We're always almost ready to ship. Occasionally we do not achieve this but we don't worry too much about it. Sometimes it is intentional, to accomodate major tools changes or difficult merges.
The Agile Manifesto, to me, sums up the best of the new thinking on development process that emerged in the 1990's. I'm pretty much a true believer in those principles, but the process details can vary. As I see it, the point of Agile is to adapt your process to your product's and clients' needs, not to be a slave to process.