Should Agile teams deliver new features daily?

Question

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.

Answer 1

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.

Answer 2

If you had working software yesterday, why wouldn't it be working today? If you didn't finish any tasks today, todays build will be the same as yesterday. Daily builds and the pace of development are separate things. Just because you have daily builds that doesn't mean you have new features in every build.

When finally some feature gets finished and checked-in at the main branch, then you should have automated process that builds the software and runs tests. If there is a problem with building or running tests, team is notified and they focus their effort to get it working again. That is how CI works and how it helps you release working software all the time.

Answer 3

Short Answer: No. It just simply can not be accomplished daily.

However, agile team supposed to deliver working software pieces or user stories in each sprint. Usually, status meeting are held daily to see the progress and impediments.

In regards to quality software, continuous integration(CI) processes in place will make sure that quality control is applied to small pieces of efforts (check-ins), and done as frequently as configured. It also targets to improve the quality of software, and to reduce the time taken to deliver it, by replacing the traditional practice of applying quality control after completing all development.

Answer 4

No, there should not be an expectation of delivering new features every single day. Not all features can be broken down to such a small size as to be able to have a developer finish the feature in ~6 hours of development time.

If you are doing scrum you should be doing at the minimum 2 week sprints, with features sized to take roughly from 0 to 8 days to be finished. The promise to the product owner is to deliver new, tested and verified correct working code that could be put into production at the end of the sprint. (NOTE: You don't have to actually put it into production but the goal is it could be if you wanted to)

Good methodology suggested you setup a CI (Continous Integration) server in which you automated the creation of at least one daily build of working software. The idea being you check in your code as soon as you finish the feature so it can be in the next build cycle and then in the hands of QA for testing.

Remember the goal is to to have features done and tested by the end of the sprint! You wouldn't want to have to make QA wait until the last day of the sprint for you to make the build and then have them test all the features. They won't have time to test it all and you won't have time to fix any bugs...

If you cannot setup a CI server then the practice should be that you need to manually create a new build for QA each time a developer checks in his finished code and claims he is done with a feature and ready to hand off to QA.

Answer 5

It actually depends on the size of the project; if the project is a large one there is no feasible way to achieve this.

Daily (or even more often) builds which come out of continuous integration tools, does not mean working software; it barely means compilable code.

Answer 6

There are many projects out there that deliver daily builds, which thanks to continuous integration, are working software. At least in theory.

It means it's not necessarily containing new features. Maybe few minor bug fixes, or nothing at all.

In theory, if you are unable to provide more work to your QA daily, you must either increase the number of developer or reduce the number of testers. Terrible idea!

Your job is to get things done.

Tell the QA that they will get something to test when it's done. You need to explain to them why.

Answer 7

I think you are confused about the idea of "CI" . You may want to visit this excellent article by Martin Fowler on how CI works in practice.That should answer your question correctly .