Experience report "Move from Waterfall to Scrum"

Hi Chrisitian,

Sounds like a bad start, especially in the adoption of Scrum / Agile in your organisation. Not the right project (fixed scope / fixed date) and a lack of knowledge and experience to be succesfull.
Get yourself an experienced Scrum Master who can facilitate your team and get your organisation aware of the potential of Agile / Scrum. And what you really need to be succesfull. A bit of Scrum is no Scrum. Just use it as it's ment to be...

Best regards,
Stan

> According to the fact that I (or we) are not able to solve also
> the bigger and harder impediments I believe that members of the
> development team are no longer willing to spent their time in
> the Retrospective to make our impediments transparent. This
> behavior is wrong, but I understand them, cause why should they
> spent their time in Retrospectives when in the end nothing
> (important) is changed?

That's a shame, because getting better transparency is a useful outcome of a Sprint Retrospective. The problems that you can't solve need to be made clear to those who *can* fix them. For example, this might be done by flagging blockers on a task board, or a RAID log or dashboard, or by only accepting work that you know you are able to finish.

> So, while the Development Team has finished the work on a PBI
> of the Sprint Backlog on which state does it sets this PBI?

What you need is a signal that a given item is ready for review by the Product Owner. This could be a state that is simply called "awaiting review". The Product Owner does not have to delay until the Sprint Review before reviewing items.

> Regardless of the described situation, I believe that we can
> reach our target and finish the work before the deadline
> expires. Perhaps people will think that we did Scrum inside
> this Project, but I think that we did a lot of work like
> we ‘ve did it before.
...
> What do you think about this situation? Have you made similar
> experiences?

I suspect that you have indeed done a lot of work the old way. When you talk about how you can "reach our target and finish the work before the deadline expires", that's a very waterfall and stage-gated view. It indicates that risk is still being deferred to a "deadline".

In Scrum work should be finished regularly in timeboxes - that is the essence of incremental release at the end of a sprint. For example, if there are 10 sprints and you are on Sprint 9, the accumulated risk should be very low at that point. You should have delivered value continually and the highest risks should already be mitigated.

What you seem to have achieved, however, is a greater level of transparency than you had before. That's the first and most important step in agile adoption, so keep on with this. In my experience, a problem that is seen clearly and acknowledged is on its way to eventually being solved.

Thanks for your opinions! I don't believe that it is possible for us to switch from one day to another complety from Waterfall to Scrum. Did this anyone before? I think this is a change process, and we are now doing some "ScrumBut", but it is clear that I'm not satisfied with the current process and I want to improve it.

According to Ian's Statements I have some thoughts:

That's a shame, because getting better transparency is a useful outcome of a Sprint Retrospective. The problems that you can't solve need to be made clear to those who *can* fix them. For example, this might be done by flagging blockers on a task board, or a RAID log or dashboard, or by only accepting work that you know you are able to finish.

According to the fact the our company uses the traditional waterfall process for all the other projects, I don't believe that we are in the position to refuse work. Further I think that we have quite most of the required skills to fix the impediments, but the problem is that we are not able to bring them in the next Sprint. There is a big difference on our side between the importance of the product (which matters) and the (un)importance of the process. Finally I think that it is also a shame, that we do the work the makes the impediments transparent, but we are not capable to fix them.

What you need is a signal that a given item is ready for review by the Product Owner. This could be a state that is simply called "awaiting review". The Product Owner does not have to delay until the Sprint Review before reviewing items.

I like this proposal. I'm just afraid that in practice this pattern will not work alway for us, because our Product Owner will be occupied with other tasks outside of this project. I think that this is an "impediment" which just could be fixed by the management if they really want it.

I suspect that you have indeed done a lot of work the old way. When you talk about how you can "reach our target and finish the work before the deadline expires", that's a very waterfall and stage-gated view. It indicates that risk is still being deferred to a "deadline".

In Scrum work should be finished regularly in timeboxes - that is the essence of incremental release at the end of a sprint. For example, if there are 10 sprints and you are on Sprint 9, the accumulated risk should be very low at that point. You should have delivered value continually and the highest risks should already be mitigated.

I agree and really like the point about the risk which is deferred to a deadline. What we do in each of our Sprints is to produce a working increment which is shown to the Product Owner, and quite only to him... So we have here in fact a much higher transparency than before for us as the (Scrum) team. But what happens on our side, when we don't see in a specific sprint much progress? Nothing! We just continue with the next Sprint and do there some of the work, which was not "done" in the previous one. As I've written it in my initial post, I think to better understand and estimate the risk of our work, we firstly need to setup a proper Product Backlog, because with this we will be able to estimate the work which left and so to estimate the end-date.

Greetings,
Christian

> ! I don't believe that it is possible for us to switch from one day to another complety from Waterfall to Scrum. Did this anyone before?

I've coached several organizations to do this. They change the process framework immediately (usually after a 2 day training class and about a week of "Pre-Game"), but the waterfall mindset and culture can take months or years to switch.

Posted By Charles Bradley - Scrum Coach and Trainer on 07 Nov 2013 10:13 PM
I've coached several organizations to do this. They change the process framework immediately (usually after a 2 day training class and about a week of "Pre-Game"), but the waterfall mindset and culture can take months or years to switch.

What do you thing are the key points for being succesfull in a most short time? How was the Management support in those cases? Did they known before the benefits of Scrum and being Agile?

Thank you for sharing a comprehensive description of your scrum adoption!

...

What you need is a signal that a given item is ready for review by the Product Owner. This could be a state that is simply called "awaiting review". The Product Owner does not have to delay until the Sprint Review before reviewing items.

I like this proposal. I'm just afraid that in practice this pattern will not work alway for us, because our Product Owner will be occupied with other tasks outside of this project. I think that this is an "impediment" which just could be fixed by the management if they really want it.

By making this visible, it's more likely to be fixed. The PO will see it on the task board (you do have a task board that's visible to everyone, right?) and when things start piling up in that column he may feel more pressure. The team should be trying to fix things themselves and not rely on management to do it, and this should also be discussed in the retrospectives (it sounds like it is). If it *has* to be management that fixes it, they could either see the problem from the board or it could be brought to their attention.

As I've written it in my initial post, I think to better understand and estimate the risk of our work, we firstly need to setup a proper Product Backlog, because with this we will be able to estimate the work which left and so to estimate the end-date.

If you want visibility on whether you will complete the work by the deadline, then yes, you need a full product backlog with all the PBIs that must be completed. Then you can do release planning, for example with a burndown chart by sprint.

As an additional comment about prioritization... you're migrating an existing product and are mandated to include all functionality, but some functionality will be more important than others, and the PO is the one to do this. You say that he talks about one or two PBIs as his priorities and the team selects other things to do. The PO is responsible for the backlog and at a minimum is responsible to have enough PBIs in sufficient detail to fill the sprint.

Dear Robert,
thanks for your helpfull input.

One important point which you have written concerns the transparency of the the task board. We 've got a task board about the current Sprint, but this one is just based on the (not-ideal) software tool which I've mentioned in my initial post. So, each person who is interested in our work has to "pull" the information by opening the tool. I know that this is not ideal. I think those information need to be more transparent to everyone, especially to our management. The information should be "pushed" to them. I believe what really would help would be a big screen at the entrance of our bureau which just shows the Sprint Taskboard, the Sprint Burndown, the Product Backlog, the Release Burndown and the Impediment Backlog.

About the responsibilities and the completnes of the Product Backlog I agree with you.

I suggest a physical whiteboard with post-its. Google "scrum task board" for images and you'll see what I mean.

You don't need software. I can't imagine doing an agile transformation without big physical information radiators. Maybe if you had a huge screen I could see it working with software.

It can be jarring to introduce that into a workplace, especially if the culture is one of clean and tidy desks but IMO it's very important. Nobody can ignore it, and it shows that the way of doing things is changing.

What happens is that everyone can see the work. People can also see when someone gets up to move an item from one lane to the next, it's a signal for the change in state of the task. Everyone can see how much is Done, which is also important, as we tend to forget the things we've finished and instead focus on all the things we still have to do.

Hello,
i think our impediments can be summarized, and those things should go in our Impediment Backlog:
- Missing transparency of the Scrum artifacts (Product Backlog, Sprint Backlog, Impediment Backlog)
- Missing Product Backlog Refinement Activity
- Missing Acceptance Criterias for PBI
- Weak Definition of Done (Missing Test automation, Missing Performance Test, Weak technical Documentation)
- Missing Product Owner and Scrum Master support (time-partial roles)
- Missing Scrum Knowledge
- Missing Management Attendance
- Weak Software-Tool Support
- Old waterfall tradition is still present (Organization structure, Gantt diagrams, steering meetings, Scrum Master is leaded by the Product Owner…)
- Missing “Definition of Ready”

Beside those points, I've got an uncertainty about the following aspects:
- For me it is still unclear how deep should the Product Owner check the created PBIs by the Development Team. How do you handle this in your projects? Does the Product Owner checks each criteria of the DoD for each created PBI?
- Does there exists exceptions for the idea of a cross-functional team? Our web-applications support for example different languages, and according to the idea of a cross-functional team I would except that we've got a language translator for just a few ours per Sprint in our team. Today we don't have this person in our team, just send the required translation to an external translator.
- I don't have a good understanding what should happen when PBIs of the Sprint Backlog are not "done". I know the Product Owner should check then if he can use the "done" work and put the undone work back to the Product Backlog, but my questions affects another point. What should happen when this happens over several Sprints, again and again. Does the Product Owner has any "tools" to push the team? I don't thing so, because the Product Owner just can "pull" the work from the Development Team. But what are the consequences of this? I think the only option for the Product Owner is just to stop all the work of the Development Team, but this would mean that the whole projects stop also...

Best regards,
Christian

I'll speak to your questions first from a personal perspective, realize that it differs from ideal scrum.
- PBIs for us are either stories, bugs, or tasks. Stories have acceptance criteria and story points. Bugs have expected results but not acceptance criteria. Tasks are things that need to be done (not coding) and also do not have acceptance criteria. At each review, the PO (me) checks that all the stories meet all the acceptance criteria. It's the teams responsibility to ensure that the stories meet the Definition of Done, I assume all stories meet DoD if they're in the Done column. If the development team says bugs and tasks are Done, I similarly assume they meet DoD. Full disclosure, I do check business critical bugs during the sprint but not at the demo. Our DoD includes coded, reviewed, QAed - all within the control of the team which is important. Since we have some regulatory compliance our process is pretty controlled and it would be hard for a story or bug to reach Done without meeting the DoD, so I can't remember any reworks based on not meeting DoD after the sprint review. So for us, checking the DoD for each PBI would be a waste of time. I can think of other environments where it would make sense to check the DoD for each PBI during the review, but for us, it's handled during the development process. But it sounds to me like your PO is not checking the PBIs enough which I'll get to in a moment.
- We try to avoid a PBI that cannot be completely owned and completed by our cross-functional scrum team. It really shouldn't be in the Sprint Backlog if the team cannot do it themselves. You can change acceptance criteria and/or DoD so that it is not dependent on external resources. Using your example, I would have a story that would have in its acceptance criteria that a page can be viewed in multiple languages, without requiring it to have the words translated properly. The actual translations by the external translator could be done after, during, or before the sprint but wouldn't be tied to whether the story is Done or not.
- If you are repeatedly having PBIs marked as Done, but then being put back into the development pipeline because they're not actually Done, then you have a serious problem. Did they not meet the acceptance criteria? Then you have a problem with PO inspection at the review. Did they not meet the Definition of Done? Then you have a problem with dev process or with the DoD. Did they meet both the acceptance criteria and the DoD but the PO is saying they are not working after the fact? Then you have a requirements problem and they should be new PBIs and not reworked PBIs.


I've just reviewed your first post again, and I think you'll have a lot of trouble actually adopting scrum in your situation, and possibly damage your ability to implement it in the future.

In the beginning of this year our team-leader proposed to use for our next project Scrum.

Why? Because you need to respond more quickly to the business? Because your waterfall approach is not working? You will need at some point to provide a business case as to why you should adopt scrum.

According to this situation our IT management decided to handle this project as an “internal IT-project” without as most as possible business interaction.

So scrum without business interaction? The whole point is to be able to deliver value prioritized by the business in small increments to allow for frequent requirement changes while shielding the developers from the problems caused by frequent requirement changes.

The deadline of this project is fix (April 2014) and also the content (Migrate all web-apps) is fix.

If your requirements are fixed, why do you need agile? But also, if requirements are fixed, why are so many PBIs being approved as Done and then needing to be done again?


On management support, it's important, and it sounds like you don't have it. But it will be difficult to get their support, because as you've said, this project has no business value except as a cost savings for IT. So the risk is that management will only pay attention if you miss your deadline, at which point the culprit may be "all the time wasted on this scrum stuff" rather than all the impediments that you identified during inspection and retrospectives. You will need to bring a solid business case to management as to why scrum should be adopted and why they should support it.

I think you've got a good summary of impediments, but are these impediments to getting the work done, or to adopting scrum? For example, why do you need management attendance? All of the scrum ceremonies are to benefit the team and management should not be required in a self-organized team.

Also, why is the team-lead who initiated the scrum adoption negligent in PO responsibilities?

Dear Robert,

your thoughts are again really helpful for me. Thanks a lot for this input!

…Since we have some regulatory compliance our process is pretty controlled and it would be hard for a story or bug to reach Done without meeting the DoD… So for us, checking the DoD for each PBI would be a waste of time.

I think an important part which differs between our companies concerns the regulatory compliance of the software development process. For our development team it is possible to deploy software on the “demo machine” without doing steps which would be required by the DoD. Some of those steps are for example reaching a specific percentage of test-coverage or creating a technical documentation.

In the beginning of this year our team-leader proposed to use for our next project Scrum.

Why? Because you need to respond more quickly to the business? Because your waterfall approach is not working? You will need at some point to provide a business case as to why you should adopt scrum

Well, I don’t know his initial thoughts, and the team had not known much about Scrum. There wasn’t a business case created for this decision. I think it is clear, that it was a mistake to not scrutinized this decision. I assume that some of his ideas were to foster team collaboration and to get an higher efficiency.

On management support, it's important, and it sounds like you don't have it. But it will be difficult to get their support, because as you've said, this project has no business value except as a cost savings for IT. So the risk is that management will only pay attention if you miss your deadline, at which point the culprit may be "all the time wasted on this scrum stuff" rather than all the impediments that you identified during inspection and retrospectives. You will need to bring a solid business case to management as to why scrum should be adopted and why they should support it.

This one is so true. I think it will not be enough to just make our impediments transparent, instead I agree with you for the need of the business cases.

I think you've got a good summary of impediments, but are these impediments to getting the work done, or to adopting scrum? For example, why do you need management attendance? All of the scrum ceremonies are to benefit the team and management should not be required in a self-organized team. Also, why is the team-lead who initiated the scrum adoption negligent in PO responsibilities?

The impediments hinder us in a establishing a better software-development process. Without this improvements we will not be able to be more effective and in middle-term we will not be able to provide “more” product-function into our Sprints. Nearly all which counts in our organization is the short-term benefit and so are the product tasks much higher ranked than the process improvements. Without management attendance we will not be able to change this. Also for the negligent PO responsibilities, our management has to understand that it can’t well work when people are overloaded.

Happy to provide input and enjoy the discussion. I applaud you and your team for attempting to improve. I hope the feedback you get on this forum is helpful.

I think an important part which differs between our companies concerns the regulatory compliance of the software development process. For our development team it is possible to deploy software on the “demo machine” without doing steps which would be required by the DoD. Some of those steps are for example reaching a specific percentage of test-coverage or creating a technical documentation.

It sounds to me then that the PO should be reviewing the DoD for each story in the demo as you alluded to earlier. Is the PO concerned about the stories that are accepted and then sent back into the Product Backlog? You could suggest that inspecting the PBIs more closely could mitigate this. After some time, the team will realize that a story won't be accepted without it actually being Done and will become more diligent. Once that happens, inspection of the DoD should become a formality.

(why did team-leader propose scrum?)
Well, I don’t know his initial thoughts, and the team had not known much about Scrum. There wasn’t a business case created for this decision. I think it is clear, that it was a mistake to not scrutinized this decision. I assume that some of his ideas were to foster team collaboration and to get an higher efficiency.
...
(management support)
This one is so true. I think it will not be enough to just make our impediments transparent, instead I agree with you for the need of the business cases.

Ok, so you are doing it to get better. One way to make a case for scrum adoption is to prove that it is making the team better, through higher quality and/or output. Unfortunately, it sounds like no-one outside the team is watching and will only notice what you are doing if you don't meet the deadline. So you could show velocity or have some other metric (# of features/sprint, # of pages/sprint) to show the benefits you've reaped so far (if there are any - are there?), but will they care since they are focused on short-term benefits and the product you're building has no value until it's totally complete and can replace the legacy system?

The impediments hinder us in a establishing a better software-development process. Without this improvements we will not be able to be more effective and in middle-term we will not be able to provide “more” product-function into our Sprints. Nearly all which counts in our organization is the short-term benefit and so are the product tasks much higher ranked than the process improvements. Without management attendance we will not be able to change this. Also for the negligent PO responsibilities, our management has to understand that it can’t well work when people are overloaded.

The impediments you list are your opinion of the impediments and not the team's identified impediments, correct?

You cannot count on management involvement for process change relating to this scrum adoption. They did not mandate it and might think that the short-term benefit IS more important than process improvements because maybe they think the process is fine. They might also think it's fine for the PO to not have enough as much time as you think is necessary for this project because the project doesn't add any value until it's done and the other things they have him/her doing may be more valuable.

Establishing a better process should happen naturally by the team identifying ways to improve (and implementing them - we use a did this improve checklist for all the proposed improvements each sprint). These should be things within the team's control.

For impediments, I reviewed the scrum guide and it seems to me that the removal or mitigation of impediments is owned by the ScrumMaster. On our team, we call out impediments during review/retrospective and have a mitigation strategy (although sometimes that strategy is 'live with it' if it's something that will not be fixable).

Keeping in mind the primary goal is to provide valuable working software (and not a working scrum team), here's a review of your impediments from your first post.

“time-partial Product Owner and Scrum Master” problem

Your PO and SM are overloaded with support responsibilities and can't dedicate the time required and requested by the team. Can those support responsibilities be transferred to someone else or can others without those responsibilities become the PO and SM?

Test Driven Development (TDD) is not established

How is this an impediment to completing your PBIs? Is there something in the DoD that would require TDD?

Code Quality was improved, but our process allows it still unclean code

How is this an impediment to completing your PBIs? Does the code work?

Technical documentation doesn’t really exists

How is this an impediment to completing your PBIs? Is it in the DoD? If so, see my previous comments about inspecting DoD by the PO.

I'd encourage you to engage the team on what they think the impediments are and how they think they should be mitigated. Maybe you've done that but the way you've presented it in your posts is what you think the impediments are. You're probably right, I've been there where I can see the problems, but you should focus on what the team thinks the impediments are and try to resolve those because then the team will be much more open to identifying impediments if they think they will be addressed. When you get an impediment where you think 'only management can fix this' try to brainstorm with the team as to other ways you could workaround or reduce the impact of the impediment. They may come up with some creative ideas.

Again Robert, thanks a lot for your inputs!

Is the PO concerned about the stories that are accepted and then sent back into the Product Backlog?

The PO knows which items were “done” and which are not “done”. According to the fact that he is “time-partial” his granularity of the different PBIs is not very deep.

So you could show velocity or have some other metric (# of features/sprint, # of pages/sprint) to show the benefits you've reaped so far (if there are any - are there?), but will they care since they are focused on short-term benefits and the product you're building has no value until it's totally complete and can replace the legacy system?

The benefits of our Scrum implementation is an really important points. Which is better since we use Scrum? According to our development process I’ve written several points in my previous posts. For me the biggest advantage is that we/I have now an better transparency about strengths and our weaknesses (potentials). One thing which I’ve not spoken about concerns the benefits according to our product. For me one really important aspect is here the earlier feedback from our test-experts and our business analysts instead of the old waterfall process. With Scrum we don’t wait until we ‘ve finished each parts of an application and then show the app to the tester and later to the business. We involve those persons much earlier and are so able to bring their feedback in the product, which increases the acceptance and the product quality.
But to be honest, there are other points which will usually come with Scrum which we haven’t yet. For example I think of the priority of our PBIs. Usually when an project has an fixed end-date, but the content is variable it is clear that just the most important parts are done, and for example not the lowest priority requirements.

The impediments you list are your opinion of the impediments and not the team's identified impediments, correct?

No this is not correct. The impediments which I’ve listed here are the sum of both (the Dev-Team and me as the SM).

Establishing a better process should happen naturally by the team identifying ways to improve (and implementing them - we use a did this improve checklist for all the proposed improvements each sprint). These should be things within the team's control.

I don’t fully agree with this. I believe also that the team should identifying ways to improve. One formal meeting for this is the Sprint Retrospective. To remove an impediment or to establish a process improvement, I believe that in most cases it needs an initial effort. Someone has to do something. I think that Scrum provides two possibilities to realize an process improvement. One possibility is that the SM does the work, or the other possibility is that in the next Sprint this task (process improvment) is planned and the Dev-Team will work on it. The problem in our situation is that in quite all situation I don’t have the required time to do the process improvement from my role as the SM, and on the other hand the PO and management don’t really care about process improvments in this project, because the prioritize the Product work much higher, and so in the end they are not planned in the next sprint(s). So, I don’t believe that improvement process is for us in our (team’s control) hand.

Can those support responsibilities be transferred to someone else or can others without those responsibilities become the PO and SM?

The idea is good. I thought also on it, but we are in an project with fixed resources and so there is no possibility to reorganize this.

(Test Driven Development) How is this an impediment to completing your PBIs? Is there something in the DoD that would require TDD?

For me TDD is not that important as automated regression tests, but TDD is a way which allows teams to build and establish automated regression tests. Inside of the DoD, the team has written “automated regression tests”, so this is an point which is violated for quite each “done” PBI. But who cares? The PO says, that he doesn’t has the required budget to establish an set of test data records which is the pre-condition to do the automated regression tests… But back to your question how this points hinder us in the completion of our PBIs. Scrum says that while a Sprint the product is not just developed (coded) but also tested. For the first sprint this is quite easy, because there is not “much” functionality which can be tested. With each Sprint the functionality of the increment increases and so the effort to test the increment. Now – without automated regression tests exists two possibilities. The first one is, that the regression test will be done by manual tester(s). It is clear that this one would be very expensive and time-consuming. The second approach is that just the new features of the sprint will be tested. In consequence the effort for the test is not so high, but in consequence the quality of the test will be worse. The result of this is that we will find bugs much later and the fix of them will cost us much more than it will be the case with automated regression tests. We do the second approach, but I believe that neither of those two approaches is something which is acceptable. The only “escape” is the test automation.

(Code Qualitiy) How is this an impediment to completing your PBIs? Does the code work?

A weak code quality affects us in each future Sprint and will decrease our velocity. When we ‘ve to enhance a component, and this one isn’t written well, it is clear that future changes will be more expensive. According to the fact that Scrum and Agile foster the idea of “Collective Code-Ownership” and try to avoid “knowledge-silos” it is obvious that for some new developers they will spent more time to understand the existing code, before the will be able to make the required changes. It is quite similar also for your third mentioned point about the technical documentation.

I think were a quite done in this thread, or at least we need a break. For me the next important task is to increase to transparency of our situation in the company. People firstly have to understand what Scrum is, what Scrum is not, and what miss to getting better. Then I’ve to make clear our impediments, and with each of them I should “estimate/calculate” the impacts (best in money). I think this will be a lot of work, but it is the only thing which will work. This information can be understood by our Management and so I hope that the required process improvements will get an higher priority than before.

Quick change was possible due to an outstanding Department Leader.

I participated in an agile-scrum department that was able to double programmer productivity almost immediately—but there was some temporary stress increase as the change from waterfall to agile was made—they were able to produce a User's Guide for each feature while the programming and QA was happening, and they were able to release features most needed by customers in a truly agile and quick manner.

They accomplished this by the following practices and some others:
An analyst prepares some ideas for a project's features and then schedules a meeting (Feature Blitz) where all the development team [domain expert(s), programmer, code reviewer, SQA engineer, the analyst, and any manager that really wanted to attend] decide the features needed, their specs, their implementation, the proposed order they will be coded and list of dependencies, breaks them into iteration-sized mini-projects, and at the end of the meeting assigns people to each of the above roles for each mini-project. The specs are the notes and digital photos from this meeting. Next each member of the team enters estimates of hours for them to finish their role's work for each iteration or mini-project. The managers, in Iteration Planning, then swap around any resources or mini-project to maximize the use of everyone's time, keeping in mind that changes may require the new team member to meet with the analyst or others to get up-to-speed on what happened at the Feature Blitz and that the new team member may not be able to do the role's work as fast as the one who helped decide the particular implementation in the Feature Blitz. Next there is a commitment meeting where the development team (the four roles besides domain expert) commits to their deadlines even if they have to do overtime, which rarely happened because people became good at estimating their work ability. Simultaneously during an iteration, the analyst writes the User's Guide, the QA engineer wrote a test suite with corner cases and exceptions that programming may not have thought about, the programmer and code reviewer discuss the details of the implementation and do the coding. Obstacles and progress were discussed frequently among the whole team and communicated to management and other stakeholders. QA tested each code drop so a programming path that wasn't going to work was caught quickly and little code had to be thrown out. QA had enough time to do their job properly and checked how the feature functioned with other features. Analysts, QA, programmers, and domain experts generated other enhancement ideas not only for the project, but for other projects as there was more time for exploratory testing, prototyping, and thinking about the entire product/program. At the end of the iteration, the released product was more closely bug-free than the waterfall methodology. Lastly, QA had test suites that could be assigned in the future to other QA members or customer support for re-testing prior to each product/program release.