Agile Database Development – The Sprint

Sprint Review Meeting

This meeting is for the development team to show all interested parties what has been achieved in the sprint. Literature on Agile often mentions that this should happen by means of an informal demo of the software. Usually we only demo the software when we are working on really huge stories that span multiple sprints to show the progress so far and that we have not been idle in the meantime.

Because we are sitting quite close to the business owner and many of our customers, we receive feedback on certain features before the end of the sprint when we hand it over to the customer to test it and sign it off. For this purpose we maintain several sandbox database stacks that are reserved for this or that user group. These customers then use their own sandbox to conduct their tests as to whether a feature meets their expectations or not.

All this enables us to keep the sprint review meeting quite short. The main point of the meeting is to determine if the goals or the sprint have been achieved or not. But even this becomes clear in the daily meetings before the sprint ends. Usually the sprint review meeting ends after 10 – 15 minutes and we directly continue with the sprint retrospective meeting.

Sprint Retrospective Meeting

This meeting is primarily for the development team and the project manager. Other parties can be encouraged to participate, but interest has been quite low so far. The whole point of this meeting is to determine:

  1. What worked well in the sprint and should be continued?
  2. What should be continued, and can it be improved?
  3. What did not work well that we should stop doing?
  4. What should we start doing?

When you have just started with Agile development, all analysis from the first 2 – 3 sprints is less meaningful. At least when it comes to statistics gathered about the sprint. It’s hard to assess what exactly a story point is and how much actual time it stands for. There were cases where our estimates have been completely off and where we had spent days for a task classified as “trivial”. Likewise we had complex tasks with a high number of story points that took just 1 – 2 hours to complete.

Furthermore we made the mistake of taking more tasks onto a sprint than could actually be completed. This is not necessarily only due to misjudgement on our behalf, but is also linked to the fact that we act as 3rd line support and that our highest priority is to ensure a smooth production service. These support tasks are unknowns that are almost impossible to assess upfront. There have been sprints during which there were hardly any support tasks, while on the other hand there were sprints with a significant number of support tasks. But even if we ignore the support work, we made the mistake of taking too much work onto a sprint. The result out this was that those tasks had to be carried over to the next sprint. This is not the end of the world, but still an annoying experience.

After several sprints we began to get a feeling for the number of story points that realistically could be handled in one sprint under good conditions. Also our assessments in general became more and more precise.

One other effect that I’ve noticed is that it becomes easier to breakdown complex stories and tasks into smaller units of work, which in turn enables you to give a more precise assessment on the task at hand and the sprint as a whole. The result is that less and less tasks now have to be carried over from one sprint to another. At least, if we ignore the confounding variable of “support”.

Conclusion

As already mentioned in the first part, we have used Agile methods more or less even before we officially introduced them. This probably made the move much less painful and problematic. In my opinion the move to agile happens to a large degree inside the head of a person. It is the different mind-set to think in small iterative steps that quickly and flexibly react to changing conditions, which sounds easy and straightforward in theory, but occasionally causes problems in practise.

So far this has been quite a lot of “theoretical” information. From the next part of the series onwards I will concretely address what tasks in a database sprint look like in our organisation, how we changed our whole environment to better address Agile needs towards testing (unit, integration and regression), and how this all has changed our release management.

Further information

Below are some helpful links that I have used to learn about Agile and scrum:

· Manifesto for Agile Software Development

· Agile software development

· Scrum.org

· Scrum Alliance.org

References:

[1]: http://en.wikipedia.org/wiki/Scrum_(development)

Pages: 1 2




Related Articles :

No comments yet... Be the first to leave a reply!

Software Reviews | Book Reviews | FAQs | Tips | Articles | Performance Tuning | Audit | BI | Clustering | Developer | Reporting | DBA | ASP.NET Ado | Views tips | | Developer FAQs | Replication Tips | OS Tips | Misc Tips | Index Tuning Tips | Hints Tips | High Availability Tips | Hardware Tips | ETL Tips | Components Tips | Configuration Tips | App Dev Tips | OLAP Tips | Admin Tips | Software Reviews | Error | Clustering FAQs | Performance Tuning FAQs | DBA FAQs |