Archive for June, 2013

Rules to design good Unit Tests

Posted: June 26, 2013 in Agile, Product Development, Scrum, Software Development, Testing
4

Hi guys, this post will be short but in my opinion it is really useful for agile developers. Some weeks ago, when I was reading the book “Agile Coaching” by Rachel Davies and Liz Sedley, I found an interesting part that I wanted to share: “Unit Test Rules” by Michael Feathers.

Michael Feathers tells us that a test is not the unit test if:

  • it talks to the database
  • it communicates across the network
  • it touches the file system
  • it can´t run correctly at the same time as any of your other unit test
  • you have to do special things to your environment (such as editing config files) to run it

He also tells us that tests which do these kind of things are not bad tests. Most of times, it is necessary to have these kind of tests, however, it´s important to separate them from true Unit Test so that we can keep a set of tests that we can run fast whenever we make changes.

This is a short pillar I wanted to share with you.

Thanks guys,
Luis

Why “Retrospectives” should not be pushed to the next sprint

Posted: June 24, 2013 in Agile, Product Development, Retrospectives, Scrum, Software Development, Team Building
10

Hi guys, first of all I want to apologize for not contributing with any posts. I moved to another city, changed the job and this took all my energy

During this week I had some interesting discussions with some colleagues about retrospectives and when to conduct them. Therefore, I want to explain why, in my opinion, retrospectives should be the last thing to do in a sprint and not dragged to the next sprint.

In my opinion, retrospectives are the most important part of agile software development. This is the time when teams analyse their way of working and suggest new ways to improve a current process. I believe everyone agrees that this is a mandatory artifact and cannot be avoided. However, not everyone agrees that retrospectives should be conducted within the sprint, thus I would like to explain why I think it´s important to do it within the sprint.

First, I see retrospectives as the closing part of a sprint, when team does a retrospective, the sprint is over and everything related to it is gone. This allows the team to start a new fresh sprint without any pending issues from the previous sprint.

Second, during the retrospectives teams come up with several action points and topics to be tackled during next sprint. If we allow the retrospective to be dragged two or three days inside of the next sprint, how can we take all items that will pop up within the retrospective into the planning? This is why I think it´s extremely important to have it within the current sprint.

Just wanted to share this with you.

Do you have any arguments/ideas? Please share them with me.

Thanks,
Luis