What to do about "Failure Driven Development"?

Question

At our shop, we strive to be agile. And I'd say we are making great strides. That said, a few of us have spotted a pattern we have started calling "Failure Driven Development".

Failure Driven Development can basically be desribed as an agile release/iteration cycle where the bugs/features are guided not by tasks and stories with acceptance criteria, but with defects entered in the defect tracking software.

Our team has a great Project Manager who strives to get the acceptance criteria from the customer(s), but it's not always possible. From my development chair, this is due to the customer either not knowing exactly what they want or (and this is the kicker) two different "camps" at the customer's main office conflict with how a story should be implemented. Camp A will loosely dictate that Feature X works like this, then Camp B will fail it due not functioning like that. Hence, the term "FDD". The process is driven by "failures".

This leads to my question: Has anyone else encountered this and if so, any tips/suggestions for dealing with it?

We have, of course, tried to get Camp A and B to agree prior, but everyone knows this isn't always the case.

Thanks

Answer 1

Wildly conflicting requirements is not unusual in the corporate world. And this is frequently the reason for business process automation projects to "fail." It can be as simple as "the policy and procedures manual says to do X" while the people that actually do the work do Y. Making the software do Y means that the people paying for the software will insist that the software is defective from their perspective. Making the software do X means that the people who actually get the work done cannot get the work done.

Normally, most development companies will choose what the managers say over what the workers state because that's how the bills get paid. In the ideal world, there is no impedance mismatch between written and actual policies; in the real world much office work is informally partitioned and undocumented.

Camp A will losely dictate that Feature X works like this, then Camp B will fail it due not functioning like that.

The mismatch between CampA and CampB is a political issue and not a software issue. Solving the problem is going to involve talking to people and getting one clear winner.

Answer 2

One of the main reasons to use iterative development is because you have a customer group which does not have a good idea of what it wants.

This isn't failure. Many customers simply don't have an idea of exactly what they need until they get something in their hands. This is why they first time the customer sees the system should not be after all the fit and finish has been done. Let them see it early and often.

In other words, if that was the only problem, there's no need to panic unless you end up in a situation where you just have endless retries.

The problem of disagreement among the customer body is a Product Manager issue that should not leak over to you. The most you should see is backlog/tasks/whatever. Of course, the PM will often vent in range of development because that's the only place they can, but it shouldn't affect you.

How it's managed will greatly depend on who Camp A and Camp B are.

If Camp A and Camp B represent two higher ups, then bring in someone who will actually use the system to tell you what you need. Sometimes you get rarefied air in management land causing a disconnect with reality. Someone who is hands on can often cut through the idealism and point out what is really needed.

On the other hand, if A and B are user groups, you use the opposite tack of getting someone from management to lay down the law.

In all cases, perfection is the enemy of good enough.

Answer 3

What you describe is a typical wrong implementation of Agile. You don't embrace change, you are its slave.

Do you have a product owner? Can you talk to them as needed? Are you doing sprint review with the users? Are users involved in the process (through the product owner) in sprint planning? Do you have testers in the main team?

I highly suggest that you hire an Agile coach and/or send your team to a training.

Another solution is to stop doing Agile.

Answer 4

If they are ping-ponging (A says do x, B rejects, says y, then A rejects and back to x), then your leads (PO or whatever you've got) need to beat up on them to make up their minds.

It's OK if the first go ends up not meeting their needs (the whole point of this is to give them something to look at) but if they sit there and swing back and forth on subsequent iterations you'll never get done.

Answer 5

The problem here doesn't seem to be "I'll know it when I see it". Wireframes can help (up to a point) with that particular problem.

The problem here is, it seems to me,the two competing factions within your client. Ideally camps A and B would come up with some negotiated shared vision that they could present to you.

Perhaps they might be forced to the table by you explaining how much the in-fighting costs them as you yet again redo what A asked for for B (or vice versa).

Keeping detailed notes of your time expenditure would help here. (My work wrote a lightweight timetracking application: easy to use, and easy for reporting, and reports time in 15-minute chunks. It makes it easy to say "I spent n hours on feature X.")

It does mean you're at a bit of a risk of upsetting the client or looking bad no matter what you do, since what you do for B might upset A (or, again, vice versa).

Hopefully you can find a champion at the client who can take care of the infighting for you.

Answer 6

As I see it, the problem can only effectively be solved one place, at the customer's, which is going to be difficult.

You're mentioning that you are striving for agile, so I'll take it from the perspective of scrum, which is the agile process I know best.

According to scrum, you have a specific role, the product owner, who is responsible for prioritizing user stories/bugs/releases, etc. This should ideally be just one person. If there are many interested parties with different views on the same software, it is the responsibility of the product owner that the product satisfies all interested parties.

It sounds to me that your project manager has this role. But since he is called a project manager, and not a product owner, I am led to believe that he is burdened with other tasks as well (traditional, non-agile, management tasks?), and does not have enough time to pursue the product owner role.

So I believe that you need one person with the responsibility of coordinating the needs between the different teams at the customer, ensuring that the requirements/user stories that is delivered to the developers have been verified by both teams at the customer. Pursuing this role can easily be a full time job, especially with the customer that you have.

What would really be ideal is to move this responsibility to the customer, to have one of your customer's employees have the product owner role. As long as the customer does not have this role, the customer is not committed to solving their own internal disagreements, and they leave it up to you to solve that, which you most likely will not be able to. And that is why I believe that the only effective solution is to give the customer this responsibility.

But given the fact that you already have started a collaboration, I believe that you will have a hard time implementing that change.

Answer 7

In order to get your software accepted by your customer it must fullfill the requirements set by the customer according to the acceptance criteria.

You do have a set of user requirements in the form of stories and acceptance criteria but parts of the customer organisation have differing interpretations of the user stories, leading to ambiguity.

You can get out of this situation by describing the functional design and the bussiness rules implemented and getting these signed by the customer. These will then be what is tested against during acceptance. This must be agreed upon beforehand by the customer to prevent discussions about the meaning of all documentation afterwards.

As long as your group cannot describe the software you are building in such a way that both groups agree on it, you are still in the requirements analysis phase of the project.

Your project manager could/should offer paid consultancy as part of the project to resolve the ambiguity in functional requirements.

Answer 8

I think we've all seen the case where we get detailed requirements from the user, implement them, then hearing from the user "Wait, that's not going to work for me" once it's implemented.

One thing that would help is doing a form of QA on the requirements by giving the user detailed examples with the expected system behavior. For example, you might say: "Here's an example case. If we implement X, then Y will be the result, and Z one of the consequences." That way, you can get to "Wait, that's not going to work" before you write the code instead of after.