Refusal of transition, transition to a waterfall - Is this right?

Question

I work in an Agile environment, and everything has gone to a state where the client feels that they will prefer Waterfall due to failures (what they think) about the current Agile script. The reason they think so will be the sheer number of design level changes that occurred at the final stages of the sprints that we (the developers) were unable to complete within the time that they indicated.

As usual, we both blamed each other. From our point of view, the changes said at the end were too many, and the design / code changes were too much. Whereas, from the client’s point of view, they complain that we (the developers) do not fully understand the requirements and come up with solutions that were “not” that they assumed in this requirement. (for example, they asked us to draw a tiger, and we painted a cat).

So, the client felt (not us) that the Agile process was wrong, and they want to switch to the waterfall mode, which IMHO will be disastrous. The simple reason is that their level of satisfaction in the Agile mode was not enough, while they will end up after spending so much time at the design stage of the development of the waterfall?

Please give your suggestions.

Answer 1

First of all, ask yourself, are you really doing agile? If you were then, you should have delivered most of the useful functionality to a client who met his requirements in earlier sprints. Theoretically, the “damage” should be limited to the final sprint, where you find that you need big design changes. In this case, you had to prove your ability to deliver and now need a dialogue with the client to plan the necessary changes.

However, given your description, I suspect that you were trapped in a newly developing two-week cycle without actually going into production every time and having a fixed end date in mind for the first correct release. If so, then you are really making an iterative waterfall without front-end requirements / design analysis - a bad place that usually should be.

A full waterfall is not necessarily the answer (there is enough evidence to show what the problems are with it), but some preliminary plans and design are generally much more preferable in practice for the “pure” Agile ethos of the emerging architecture (which fits with Lean’s approach to actually). Large projects simply cannot hope to achieve a reasonable, stable architectural foundation if they simply start to crack the code and hope that all this comes to a certain amount of sprints along the line.

In addition to the above, another common issue with pure Agile is managing customer expectations. Agile is being sold as this wonderful thing, which means that the customer can delay decision-making, change their minds and add new requirements as they see fit. HOWEVER, this does not mean that the end date / budget / required effort remains fixed, but people always seem to skip this part.

Answer 2

Flexible development methodologies are especially appropriate when you have unclear requirements and when you may need to make design changes at later stages of your project. In this case, a waterfall is a less suitable approach. The waterfall approach is suitable for well-understood projects and when the requirements are unlikely to change during the life of the project. It doesn't seem like that.

How long does your sprint last? An alternative approach may be to reduce the length of the sprint - at least at the beginning of the project. More often offer the client new versions and discuss changes with the client. If you do not do what they need, it will become obvious faster, so less time will be spent on implementing solutions that do not meet the requirements of the customer.

Answer 3

I'm not sure which store you work for, so it's hard for me to find good recommendations. I can offer two guidelines:

• If you have poor communication with the client, no development methodology will save you.
• None of the eateries, as the chef organizes the kitchen, while the food is delicious.

Answer 4

It looks like you have serious problems with project management and architecture / design, and it looks like your posts are also broken. Essentially, I don’t think that changing your dev methodology will eliminate all of this, and therefore it’s wrong to do it (although this may restore some client confidence).

I would be especially worried about going to the waterfall, since now you choose to essentially capture the requirements only once (of which we know you have a problem) without the ability to enter. This rigidity is good for inflexible delivery purposes, but it is completely inappropriate here where you are constantly changing - it is flexible!

• In the short term, I would step back and double-check your requirements at this point. Review and confirm your current status in relation to them.

• In the medium term, I will open more communications with the client - try and engage them in the daily battle for a while (until you restore confidence, then you can be more flexible). A.

• In the long run, you need to worry about how your prime minister and senior developers managed to get you in this position. If the client is not feasible, that is one thing (but it is still before PM to handle this, so that you are not relieved). It’s not wise to complain that you have too many changes, it just means that you are not coping with the definition of requirements (this is a dialogue, not a monologue) or that you should have more, but probably shorter sprints.

First of all, I do not see that the movement to the waterfall may be correct. It does not capture anything directly, and I can see how this exacerbates the problems that you have already identified.

Caution: I am not very capable of a balanced view of the waterfall, since I have never seen it work efficiently, and imho it is just completely outdated for corporate projects.

Answer 5

Agile or waterfall are just words. There is only what works, and things that do not. Software development seems virtual to many people, and they don’t understand why it’s hard to change the small thing that they request.

Your customers should understand that creating software is like building a house: when you have built all the foundations and walls, it’s hard to change the whole final plan of the house and the design of the room.

Some methods help to avoid such a problem: data modeling, data dictionary, data flow diagrams ... the goal is to fully know each requirement. Cutting your product in many independent blocks helps you start coding while continuing to develop or define other parts of your final product.

See Steve McConnell's book: Rapid Software Development: Taming Wild Software Schedules for all practices that work.

Answer 6

Agile development does not relieve you of the burden of actually designing a design that both you and the client understand in a similar way. Agile just allows you to come up with a design in smaller increments and not all at once. And, in the case of a difficult client, developing a suitable design takes time.

So, I would spend more effort on sitting down with the client, with the board, going over what they really want. I do not think that it really matters in this case if the development process is flexible or a waterfall.

Answer 7

The reason they think so will be the sheer number of design level changes that occurred at the final stages of the sprints that we (the developers) could not complete within the time that they indicated.

Scrum is a “short waterfall” and you must be isolated from the changing requirements for sprint duration. This does not seem to be happening! Therefore, do not dare that you will get anything from going to a traditional waterfall, but you must adhere to the freezing requirements for the duration of the sprint. Maybe your iterations are too long? (I assume you are following Scrum as you mention sprints).

Talk with your customers and agree to the following:

- Shorter iterations, up to 3 weeks max. - No changes in requirements during the iteration. - Features are planned at the beginning of the iteration - Every iteration ends with deliverable: fully functional software with all features that are fully operational - Iteration length does not change. Unfinished features are left for the next iteration (or maybe discarded if client changes his mind). - Number of "feature points" you can deliver in a single iteration should be based on the team metric, not client insistence. This is your "capacity". - Client decides what features (but not how many of them) are planned for the iteration 

Another thing you need to ask yourself is why there are so many “design level changes” in your application. By now you should have basic architecture and design. Perhaps you should look at the actual design and try to impose some design recommendations and implement some templates. For example, in a typical enterprise web application, you probably end up using something like DAO. When you add new features, you create a new DAO, but the underlying architecture and design will not change.

It seems that you are not delivering what the customer wants. In this case, it is extremely important to deliver the work product to the client so that he can provide reasonable feedback for the next iteration.

Relatively

"we (the developers) were not able to complete within the time they indicated."

The client should not indicate the iteration time. The iteration length should always be the same. The requirements that enter into the iteration should be obtained as a result of prioritizing clients, but the volume of requirements that are planned for the iteration should be based on the assessment made by the team and the number of “points” that you can provide during the iteration.

Answer 8

For me, it sounds like there wasn’t a “big plan [TM]” in a flexible project. Using a flexible process does not mean that there is no long-term plan, it is more associated with growing uncertainty in a denser future. For example, there should be a release plan with planned features for all releases over the next 2 months (and a more detailed plan with features for releases after that), so it’s clear to the client when to expect the feature, and when there is a possibility of changing requirements.

It also seems to me that in the process there was not (enough) client participation in this process. I know that this is a very problematic moment, but it helps a lot if the current progress can be discussed with the client at the end of each iteration. As @Mark Byers already wrote, the more reviews you can get from your client, the better you are.

Also try not to blame, as this causes people to block. Try using the validation and acceptance method to get a better process.

Answer 9

It is not clear what design changes you have in mind. Graphic design? User experience design? Code design?

In any case, the best solution is an earlier and earlier discussion with the client. Collaborate on specific case studies that meet customer requirements. You can include these examples in regression tests to make sure that you continue to satisfy them.

Also, continue the discussion as you go. Show your result, as it is available - do not wait until the end of the sprint. And work on the part is likely to create problems in the first place. Also look at ways to make it easier to change things that you often find.

The bottom line is to attract more customers, even to iteration of the design. You might want some discussions to focus only on design.

Answer 10

Customer fire. Even if it’s your fault for not understanding what they mean, the waterfall will give them a chance to give you feedback instead of a chance at the end of each sprint. Some people / clients are literally so stupid that they should not work. Fire them or let them know that you are using a waterfall without actually switching.

Answer 11

Your client does not know how to develop software or how to manage the software development process. Do not expect the customer to provide meaningful instructions on these issues. As a special case, the client does not really know what conditions, such as “waterfall” and “moving”, mean; do not expect them to provide meaningful input to your development methodology. Moreover, the client will not care about these details if the requirements are met in accordance with the agreed budget and time frame. Do not expect them to leave or confuse them with a large number of inadequate assemblies and irrelevant information about your internal process.

Here's what the customer cares about and tries to talk to you (partly using his own technical jargon): their requirements, their frustrated expectations, and how you communicate with them. On these issues, the client is an absolute authority. Interpret what they say as your relationship and product, and not as a helpful commentary on the internal process. Do not clothe your internal deadlines and processes; discuss progress and expectations and attitudes. (If they insist on talking about internal components, you can reassign the terms: for example, what they understand as the “next release” may be internally known as the “next major release” or something else).

It seems to me that a client may need a higher threshold before they are asked to receive feedback or play with a poor build. It is worth checking if this is true. If so, you must abide by it - and still use flexible methods inside if that is what your team feels. If they say “waterfall,” you can interpret it internally as meaning “we set a deadline for requirements, and then we don’t allow you to add additional features for a while.” Discuss with the client whether the deadline for submitting the requirements is appropriate for them, followed by such a freeze.

Someone from your team should be the defender of the client and sit on top of the problems with clients and fight for them. This lawyer should not be on the side, and they cannot take the side of the team against the client; they must be a proxy boss. Then you can separate the internal communication of the process (the protect command) from the external communication (protect the client). A defender can to some extent isolate a client from chatter and assemblies that they don’t appreciate without artificially introducing a certain type of control or planning your internal process.

To clarify, I do not think at all that you should be secretive or distant with the client, but you should (A) listen to what the client says about the relationship and how you communicate and honor it, (B) keep it separate from the internal development process, which should be managed in any way, ultimately, to meet customer expectations.

Answer 12

The obvious problem here is communication with the client. If you really want to be flexible, you need to communicate with the client on a daily basis. Only the client should be able to make a decision. If you communicate with the client only in the middle of spring, and at the end of the sprint it is natural that later you will find problems in your application. Also, the functions implemented in the sprint must be accepted and tested by the client. Until these functions are completed.

I am writing this because I have a similar problem in my current project, but I know where we failed.

Answer 13

If the communication problem between the Team and the Client is not resolved, the situation may be worse with a waterfall if the client sees the product only after its completion (tunnel effect).

You commented on the changes from sprints 6-7, began to cause refinement of the tasks achieved in previous sprints. These changes should have been detected earlier - during the Sprint review.

If there is a misunderstanding in the description of the function, and the command does not implement what the client expects, this should be detected no later than Sprint, where the function is implemented, and is ideally fixed in the current Sprint.

If the client has changed this opinion, new ideas should be added to the product lag, priority and chosen for Sprint, like any other element of the magazine. This should not be considered a remake.

Do you provide software to the client after each sprint, or are you just demonstrating it?

The origin of the misunderstanding can be in Sprint Planning: The team should only fix the lag element, which is clearly defined. The definition of items should include eligibility criteria. Is the customer the owner of the product and is he the owner of the product?

Answer 14

Remotely debugging the development process is quite complicated, and I hesitate to offer any opinion on what you should do. It seems to me that none of your team can have enough information to make a very useful judgment about this.

An easier transition to conclusion would be to make an assumption about what went wrong. From your description, this sounds like early results, which, in your opinion, were progress in the bank, were eventually reworked.

One of the common reasons for this is the late opening / creation of “all” requirements, which should be true throughout the project. They can be quite fatal if taken seriously: something as simple as “all dialog boxes must be changed,” for example, seems to go beyond Microsoft's ability to modify Windows.

The classic accounting for this type of failure (albeit in an opaque project) can be found here.

"Once they saw the product of the code we wrote, then they would say," Oh, we have to change that. This is not what I had in mind, "said SAIC Reynolds." And this is when we started to register the change request after the change request after the change request. "

For example, according to SAIC engineers, after eight teams completed about 25 percent of the VCF, the FBI wanted to add a “crumb page” to all screens. Also known as “bread crumbs,” a name inspired by the tale of Hansel and Gretel, this navigation device provides users with a list of URLs identifying the path traveled through VCF to reach the current screen. This new feature not only added more complexity, SAIC engineers said, but also postponed development as completed threads had to be complemented by a new feature.

Key phrase: "all screens." Therefore, in the face of changes of this nature, if you do not have preliminary support for the tool, you can just turn it on (changing all background colors should really be trivial), you have problems. The progress that, in your opinion, you have made up to this point, retroactively would be illusory.

The only known approach to such problems is to get them right first. If this fails, live with the mistake.

Answer 15

Many stores add Agile finishes to make Agile look like for customers who expect it. Perhaps you just need to add some cropping to the waterfall and show them the product every two sprints.

Answer 16

I believe that your client is wrong to go to the waterfall. It treats a symptom, not a disease. The problem that you describe is communication - the customer wants a tiger, you give them a cat.

The waterfall model includes many steps to verify that the requirements specified in writing are delivered — but this does not guarantee that the written requirements are in accordance with the requirements of the business.

I would look at techniques such as exposure mapping , behavioral development ( BDD ), and storytelling to improve communication.