Scrum: How Sprint Retrospectives Can Really Improve Your Sprints

I am writing too much about Scrum in a Mongodb blog, but this is a really good post over at Loomio called Occupy Scrum: How Sprint Retrospectives Brought us to Agile Nirvana.

I do not agree with them 100%, but I do agree with them for the most part. And in particular, the retrospectives part. Too many times I have seen teams say they are using Scrum, but they are not learning and improving as much as they could in each scrum.

The real magic of Scrum is not just the Scrum techniques themselves, it’s that continuous process improvement is built in. You can’t do that without retrospectives.

Good stuff. &#0153

Occupy Scrum: How Sprint Retrospectives Brought us to Agile Nirvana


Another Week, Another Sprint

I am a big fan of Scrum. I think it is very easy to do Scrum, but very hard to do well.  If you are just starting in Scrum, take a look at

This project I am doing 1 week sprints, Monday to Sunday, with the weekends for integration. Just a habit I have had for a long time. My sprints would be one week, and then the weekends were for integration and planning the next weeks sprint.

This weeks sprint is

[1] Get the first Android app up and running for the company that shall remain nameless.

[2] Get the API in  respectable shape

Using the Mock Server

For agile development in the API space, I think a mock server is essiential. When you are revving quickly, waiting for others to update the API to test can be a real pain.

With a mock server, you can rev the API and keep development running. Without one, you start getting into dependancy issues.

Our goal here is to keep the Scrum sprints on schedule and that leads me to They have a mock server when you define the API. It kills two birds with one stone in that in writing the documentation, you are also writing the mock server.

Will this work ? I don’t know this is the first time I am using their service, but time will tell by the end of this sprint.