Is FPA incompatible with Agile?

Question

I am currently working in an Agile + SCRUM based project. I work on a lower level module. This leads to a peculiar problem. The work I do cannot be directly associated with a user story many times. Since I cannot relate a user story directly to my work I often face the problem that my requirements are unclear. Also I tend to "miss out" a few things which only become clear to me late in the sprint. And my layers work cannot be tested directly.

On a similar note our GUI team was generating a lot of bugs due to missing out minor implicit requirements. For instance, the text field width was less than anticipated, etc.

I had used FPA before in another project and I think it is a good way to break down requirements to the tiny atomic details, clarify the minor points and then build your software using the points as a checklist. I really felt that it would benefit our project and my layer in particular. I suggested it in my team meeting bit it was turned down because of the documentation involved. The "wise guy's" rationale: FPA is documentation-heavy and Agile frowns on heavy documentation. I argued that Agile is about producing good products and if an Agile process cannot be molded to add a process that will reduce defects and produce good code, then it simply isn't "agile". In the end the team voted down the proposal claiming that it wasn't "Agile". however I suspect the reason was more likely to be laziness.

Is FPA really incompatible with Agile due to the amount of documentation involved? What about the lofty aims of the Agile Manifesto? Is it just "working code" or "good working code"?

Answer 1

This is a classical case of a mislead SCRUM implementation. You (and your team) need to follow this basically from the point of break-down back to the changes that need to be made (remember: SCRUM is an adaptive process, the second half of the review meetings is supposed to be used to figure out how to make it work better in the next sprint(s)!).

The point-of-breakdown is clearly all the bugs raised by the GUI team. There is another point-of-breakdown in the fact that your code cannot be tested directly. Both of these point to insufficient story definition. This level of detail (length of text fields, etc.) does not have to be done up front, it can happen during the sprint, but it requires close interaction between the team members and the product owners (you DO have product owners, right?). If this interaction takes place, then no additional documentation is required. In the interaction does not take place, then you have a problem and the scrum master needs to step in.

Also, if your work cannot be associated with user stories, then the product owners are not doing their jobs properly.

I have used SCRUM for many years, and I am a certified SCRUM Master. I can tell you from experience, if you follow the basic principles, it works beautifully. But you have to follow ALL of them, not just the ones that suit you (you in this context means the entire scrum team including the product owners).

You don't need FPA, just fix your SCRUM process.