Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

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.

share|improve this question

7 Answers 7

up vote 43 down vote accepted

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.

share|improve this answer
1  
+1: Awesome answer. Some really good perspective on what "agile" should really mean. –  Jim G. Aug 2 '12 at 14:58
    
Accepted. This is a great answer. –  Joshua Smith Aug 2 '12 at 15:09

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.

share|improve this answer
    
I worded the question poorly. I was really asking about the feasibility of delivering new features daily, not about keeping an existing product from being broken by daily builds. I've updated the question. –  Joshua Smith Aug 2 '12 at 12:04
    
@JoshuaSmith: if you stories are small enough, it is perfectly possible to have new stuff every day. And if you have a continuous integration server, having a broken product is not an option. If a feature is not ready, it is not sync with the server, or done in a private branch. I prefer the first solution. –  user2567 Aug 2 '12 at 13:15

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.

share|improve this answer
    
Sounds like someone's trying to get the questioner's team to do a sprint per day. You shouldn't offload anything to QA until it's been through a sprint (or is finished to everyones satisfaction) AND it's been deemed acceptable (minimum number of features working, known bugs documented). –  jozzas Aug 2 '12 at 4:52
1  
let's clarify: "You shouldn't offload anything to QA until user story is done and checked in." –  Yusubov Aug 2 '12 at 8:52
    
A little more clarification: A story isn't done until the code for the story has been tested. –  Bryan Oakley Aug 2 '12 at 11:23
    
@ElYusubov It was also my understanding that we were supposed to deliver new features/stories at the end of each sprint, which is completely reasonable. –  Joshua Smith Aug 2 '12 at 12:06

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.

share|improve this answer
1  
This is what we do now but new features seldom take only one day to complete, especially with offshore involved. –  Joshua Smith Aug 2 '12 at 13:03
2  
Which is fine, agile/scrum just says it will deliver potentially shippable code at the end of the sprint, not even new features! Many places have entire sprints where it's just improving performance or cleaning up code. Any place that expects you to have a new feature done each day is abusing scrum to take advantage of you. –  AlanBarber Aug 2 '12 at 13:11

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.

share|improve this answer
    
In some ways I think getting some new features to QA daily should be easier on a large project. eg If you have 5 devs/dev teams you could have them doing 1 week sprints each offset by one day from the next. –  Dan Neely Aug 2 '12 at 12:26

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.

share|improve this answer
1  
A thousand times, this. I told the project lead that keeping QA supplied with work is not my team's responsibility and was rebuffed, strongly. –  Joshua Smith Aug 2 '12 at 13:21
    
Try to come back with more convincing facts: developersurvivalguide.com/how-to-convince-your-boss –  user2567 Aug 2 '12 at 13:24
    
@JoshuaSmith: I edited my answer to match your recent edit, but I'm afraid it's not the answer you are looking for... –  user2567 Aug 2 '12 at 13:28

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 .

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.