Software Engineering Stack Exchange is a question and answer site for professionals, academics, and students working within the systems development life cycle. It only takes a minute to sign up.
Sign up to join this community
As I understand, the idea with Agile methodologies is that you deliver something functional and you deliver it often. The application gets into its final shape increment after increment.
But in the early iterations you might build the framework or foundations on which the application will stand so it's something important but not visible to users.
What gets delivered to the client in these first iterations? How do you show progress in the right direction when you build scaffolding code?
It is typical to have 2 week sprints.
For me, the first sprint or 2 will likely have less "visible" features than later sprints for this exact reason (for some tenuous description of "less").
That being said, it certainly should not take you 2 weeks to build your entire scaffold and have nothing in the UI visible to show for it.
Maybe you do not flesh out every scaffold item in the first sprint or 2. Maybe parts can wait and be added later.
Maybe your first sprint has "Create webpage X with dummy data" so that you can get something shiny to show your customer. And then the next sprint has "Change webpage X to use data from the database".
The Agile Manifesto suggests that Working Software is more valuable than comprehensive documentation, and the Scrum framework takes this notion to suggest that delivering tested, working software with business value to be a requirement every sprint.
Why? Well, among other things, designers and developers often fall victim to spending lots of time on YNNI (you'll never need it) items. Unfortunately, those frameworks you are talking about are often a big liability in this area. The developers start building in all the stuff that the framework MIGHT have to support and suddenly you are 3 months in and don't have anything of business value to show for it. Then it turns out the framework doesn't even really support what they end up needing.
So the suggested approach is to build only what is actually needed now, and deliver it now.
This does NOT mean that you can't build reusable parts and the like, you just always do it in support of building a current need. Moreover, it does not mean you have to completely wear blinders to what's coming down the road--don't build things so that it's impossible to change/enhance them later. But the key is to always be delivering business value.
There often are some key things that absolutely need to be established before anything can be delivered, such as setting up environments and the like. For these things, a lot of teams find it useful to have a "Sprint 0" in which the groundwork is laid. Sprint 0 can be a bit longer than your other sprints, in that it is not applied to your product backlog or burn-down, but it should still be time-boxed to a reasonable duration.
What gets delivered to the client in these first iterations?
What has highest business value for the user. For example, if the applications has complex business rules, the first iteration(s) will only contain those business rules encoded in the form of code. Customer should be satisfied as long as you have code for those business rules. (The problem of actually persuading customer to accept such a thing is completely different matter.) For example, you might show the customer's business experts your unit/acceptance tests that express what the domain should do and that code passes it with green result. Or even better, make the business experts help create those tests.
There is also question of
you might build the framework or foundations
Which I believe is much more important than what is actually delivered. There is big thing for Evolutionary Design, which says, that you should create the architecture over time instead of trying to create it in the beginning. As for foundation, this usually means some kind of database or UI framework. In which case, there is idea of "Good architecture is one which allows you postpone important decisions." And choosing database or UI is an important decision. For example, you might be fine with just in-memory storage for data instead for trying to use DB from the very first iteration.
What we try to do is to deliver in the first iterations the simplest application possible (a hello world version of what we are delivering). We see 3 important benefits in this:
You can deliver pretty much anything you want. The building the infrastructure idea is simply wrong/not agile/unsustainable.
For example: building a fully functional Hello World app can be built in hours. Bringing up a server (even temporarily) in the cloud or as a VM can be done in hours.
These are enough to start developing. Then, if you need CI, you can add a CI story, if you neeed a physical server, sure, add a story for that.
But start delivering on Day 1 and never stop!
But in the early iterations you might build the framework or foundations on which the application will stand so it's something important but not visible to users.
This is wrong, since you do not need to build a framework you may use in the future. The idea is to build only what is needed (see also YAGNI).
In the sprint zero, you need to prepare for the real work. Lots of people argue what should be done in this sprint, but in my opinion, it is finished when you can start working on the items in the backlog. This step includes setting PCs, setting build process, picking frameworks, etc.
When you are done with sprint zero (or iteration zero), you can start working on your application. Take items from the backlog, and finish them one by one. After you finish iteration one, you are going to have something useful. The first iteration usually includes some of most important features.
What gets delivered to the client in these first iterations? How do you show progress in the right direction when you build scaffolding code?
After iteration zero, obviously you do not have anything to deliver. The deliverable comes after iteration one. It contains features that you set for the iteration.
If your question is "how to pick what goes into iteration X?", then take a look into these videocasts (videos for iteration 0 A and part of B).
Early iterations, especially the 1st, will contain or should at least plan for architectural spikes, which include a certain amount of discovery time and maybe some architectural prototyping.
Like you said, generally, there are structural requirements which may not mean much to the stakeholder / customer, but are required to form a strong platform or pattern orientation. You cannot get around this as you can't start building B until A is complete.
Part of the Agile approach is to have the customer close so documentation is not needed because all you need to do is pick up the phone / send email, and it's expected. The customers expectations should be set appropriately and any work completed should be very terse and NEEDED. No gold plating, no "You might need it", etc.. Build what you need in A to move onto B.
Depending on how you're attacking the project, you may only build out the required foundation in order to complete a certain module, so during the sprint planning meeting you would lay out the plans for the current sprint based on the priorities set forth by the customer, depending on what is needed for that sprint, there may be some foundational requirements, so that's what goes into sprint 1. After the 1st sprint is complete and A has been built and then plan to complete B.
If you've agreed on a timeline with the customer, as long as you're going to meet that agreement, the customer probably won't care what you do 1st or 2nd. You could always show them the unit test results, but if you say we'll have something for you to see after sprint 2 (or 3), and you deliver, it will set a strong precedence. Customers are expected to be reasonable as much as developers are and both are working towards the same goal. A completed project which meets the needs of the customer and works as expected. So worrying that there's nothing to see after sprint 1 is a moot point because the customer just wants to make sure that after sprint 20, the project will be done(-ish).
