5

I'm new to Agile as a methodology, although I believe a have a basic grasp on its principles.

My team is currently building a framework that will support our client's application in the future. As an input, we have a bunch of requirements and even a suggestion of how the application should be implemented, at a VERY high level.

As an approach, we decided to use some sprints to understand the requirements before actually build the system. Our output is more documents describing the system to be build.

After the first sprint I started to question whether this isn't violating Agile principles, since our output (documents) aren't testable or a goal of the project in itself, only intermediary byproducts.

Improve this question
5
  • 2
    Would you rather have confidence in the requirements, or confidence that you aren't violating Agile's lofty principles? To put it another way, which is more important: the product or the process? If you had to choose one or the other, which one would you chuck out the window?
    – Robert Harvey
    May 3, 2016 at 23:38
  • 2
    Requirements Engineering is really important, regardless of project management methodology. However, Agile takes the stance that it is often not possible to do a thorough analysis and then build the system, since the analysis will be incomplete, and the requirements might change during the project. Agile therefore favours an iterative approach where you build a simple system from the requirements known at the beginning, then expand that as new facts become known. Plan for this change! Don't be afraid to prototype! Get feedback on your prototype as soon as possible!
    – amon
    May 4, 2016 at 5:38
  • 1
    How is a document not testable? There's no one going to make the decision whether or not it accomplishes what the story said it would? It's either acceptable or unacceptable, that's the test.
    – JeffO
    May 4, 2016 at 12:34
  • @JeffO, good point, but my simple answer is no, it isn't. The pitfall here is that a document has less semantic value than the actual software -- a document may describe in detail a software that, once produced, does not meets the actual requirements. I always thought that this was one of the things that Agile tried to mitigate - instead of producing a high number of design docs (as old Software Engineering of late 90's/early 00's seemed to preach), you should try to do minimal docs and move to implement it. But maybe that was what I was looking for in Agile, not what Agile actually is.
    – Bruno Brant
    May 4, 2016 at 14:20
  • A client, customer, user or manager can approve of a document just like they do a feature of an app. I agree it is not an automated unit or integration test. Just because there is a risk of misusing a document, doesn't mean you get rid of them altogether. The goal is to have less documentation which, in theory, should be easier to maintain over time and don't have to be created first.
    – JeffO
    May 7, 2016 at 11:34

4 Answers 4

Reset to default
2

Who says that the output of a sprint is only code?

One of the deliverables of sprints can be documentation:

Once the team gets a business goal, it:

  • Figures out how to do the work
  • Does the work
  • Identifies what's getting in its way
  • Takes responsibility to resolve all the difficulties within its scope
  • Works with other parts of the organization to resolve concerns outside their control

Emphasis above is mine.

While documentation is not one of the preferred outputs, it is an option.

Improve this answer
1
  • But this documentation is input to a next step... What I'm perceiving here is a regression to a waterfall methodology, where each sprint becomes a project phase, and we fail to deliver something that's usable (that's the word I'm going with, but what I have in my mind is close to 'value') to the customer. Sure, they can read the document, but can they use it for something business-relevant?
    – Bruno Brant
    May 6, 2016 at 19:44
2

The danger is of course that once the documents are complete you then implement them in a waterfall fashion.

I think your approach is probably not a good one. Aglie methodolgies are a response to the problems generated by planning everything in advance and it sounds to me like you are trying to plan everything in advance.

Instead of wtiting the document describing the framework. Write the framework! If it doesnt work as required, do another sprint with the refined requirement

Improve this answer
2

When your project goal is to develop a framework to later develop end-user applications, you aren't writing the end-user application. Your users are not the end-users. Your users are future developers, and any user-stories should be written from their perspective.

However, the reasons why your users will use your framework is because they are implementing a user-story of an actual end-user. That means you can have kind of a "story in a story" in form of an end-user story which leads to a developer wanting to use your framework to implement it.

The programmer receives a user-story which reads "the user clicks on a red button to close the window". However, in the current version that button still has the defalut color. So the programmer searches the sourcecode for a call to closeButton = new Button() and adds the line closeButton.SetColor( red ) after it.

This story tells you what kind of requirements your users (the programmers) will have to deal with and how you design your framework in a way that such requirements can be easily implemented.

Improve this answer
1

The main point of Agile is to iterate instead of doing the big design up front. However, you still have to have the requirements for the minimally viable product which should be documented in some format: specification, user stories, whatever works for your team.

It's a lot easier/faster to correct problems in the requirements than to rework\throw out already implemented code.

IMHO, if a client asks me to a build a building, I should know if the client wants a shed, a house, a office building, or a shopping mall. I should also probably know what type of foundation the client wants. What color the roof should be, and the color of the walls are a decision\requirement that can be nailed down at a later date.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

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