Developing scalable applications using Agile methods

Question

Maybe someone can share from his experience about developing an application that is meant to scale big time where just throwing more money at better hardware isn't a realistic option using development methodologies such as SCRUM and XP.

1. Did you need to rewrite substantial parts of your app because of current framework couldn't scale enough to fit current sprint's stories? how do you avoid that?
2. When do you do stress (or load) testing?
3. In what stage did you make your SMART(TM) design concerning bleeding edge requirements?
4. Did you add more stages to the dev-cycle of write-a-test, code-to-pass-test, refactor?
5. Did you just refactor everything in the end to meet demands?

Answer 1

Fast paced development that doesn't take into account all requirements (since they are added one by one) may lead to unsuitable design in the infrastructure level of the application.

That is not true. The design follows requirements. If your team commits to delivering feature it also commits to its acceptance criteria (definition of done). The acceptance criteria for the story can contain demands for scalability and performance and if these criteria are mentioned you must provide automated test to validate their passing to show that story is complete and to make sure that acceptance criteria will not be broken in future by regression.

Your product owner can even declare such acceptance criteria as a global so they will be part of every user story and team will be able to take it into consideration during estimation of stories (requirements).

If you ask about "tuning" application for global performance than it is similar as with any other. Premature optimization is source of evil so until you have solid code base with implemented features there is nothing to optimize and refactor toward performance.

As a side not if you want application to scale "big time" you need money and hardware - or even better you need to make application on cloud and pay for HW you will really use.

Answer 2

If you are dealing with requirements one at a time with no knowledge of other requirements, you are doing agile wrong.

An agile project still has an up front design component - it is just far less than you have in a waterfall project, and there is no need to define all the details - just high level stuff like platform choice and overall system design that you can't handle at the individual feature level.

Since scaling issues usually aren't tied to individual features (the ones that are are easy to fix), the solution is in that initial design - no different from any other type of project.

If you do find you need to change the framework part way through a project, you did that first step wrong and will need to return to all the previously developed features. Most likely it will be quicker than the original development as you have some code you can reuse, but the process is the same as for a complete rewrite.

Answer 3

In most cases, your customer should have some idea of the scale of the application. For instance if you're building an in-house CRUD app or the "next facebook". That on-demand customer context is sorta the point of Agile, you don't have a team of developers running off with outdated specs hoping to hit a moving target.

In that way the customer is somewhat responsible for prioritizing the stories, so if performance is mission-critical, it doesn't fall off until the end of the project. There's also the side effect that the whole team is aware that there is a story in the backlog that requires certain performance criteria and it will naturally provoke a conversation if finishing story X in this iteration might throw off the estimate for that performance story later.

Now, discovering a performance requirement could really go badly with any methodology. Agile may or may not be more efficient at handling this problem. A waterfall team could easily say it wasn't in the requirements, so it's not our problem. An agile team would likely at least try to change course. Both have a high possibility of failing to deliver what the customer really wanted.