Posts Tagged ‘agile’

Continuous Deployment changes your mind

Posted in agile, continuous delivery, continuous integration, deployment, management, software development, testing on August 14th, 2011 by Joerg – Be the first to comment

We are practicing Continuous Deployment since about a year. When looking back I realize the dramatic way this practice changed the way we work.

Just to draw the fine line between Continuous Delivery and Continuos Deployment I use the definition I once heard from Neal Ford. Continuous Delivery allows you to deploy every commit but you don’t do it every time. With Continuous Deployment you go further and really deploy every time.

I have recently been asked what the benefits of Continuous Deployment are compared to Continuous Delivery. I think the impact on your development practice is a huge thing.

In our company we practice agile development since about 2005. During that time I can remember many discussions about agile practices like:

  • Test Driven Development
  • Definition of Done
  • Potentially Shippable Product
  • Refactoring in baby steps
  • Not committing on a red build

Many of them do not easily reveal their benefits in daily business. So it becomes difficult to use them consequently.

The Definition of Done is a great example. It is easy to declare something finished or appropriately tested when there is usually a QA department that will find your mistakes during release tests. So the common recipe is write down your definition, post it on the wall and “be more disciplined”. Force yourself to write more tests, force yourself to declare things done only if they are really done and so on. This is not easy. In my experience it seldom works.

This changes dramatically when using continuous deployment. Between your commit and the production system is only an automated deployment pipeline, that usually takes something around 30 minutes. There is no QA department that does a extensive release test. Your mistakes will only be found by automated test that you wrote yourself. Well or they will be found by your Users.

Automated tests become your safety net. This again changes the way you think about TDD. It totally makes sense to have a near full coverage of your code. It also makes sense to have integration tests on API and GUI level to make sure your deployment pipeline catches most mistakes. It will not catch any mistake, but in my experience the same is true for most QA departments.

You will think differently about Potentially Shippable Products. Every commit has to be shippable and it will (not only potentially) be shipped.

This forces working in baby steps. It is just not possible to refactor a system by destroying it for several days.

If a build is red the deployment pipeline is halted. Nobody is able to apply more changes to the system unless this problem is fixed. Again something that used to be a discipline thing becomes a necessity. You need to help your teammates to fix the problem otherwise you can’t work yourself. The same is true if there is a red build in the evening. One of my teammates even talks about an addiction to fix the build before going home. It just gives you a good feeling to finish your day in a green state.

Continuous Delivery has several immediate business benefits I might tell you about another time. But most of them don’t need every commit to be deployed.

But I think the impact of deploying every commit on your development practice huge. Many agile practices make so much more sense. They fit naturally in this environment and you follow them easily. This will then result in benefits for your business on the long term.

A poor man’s countdown

Posted in agile, scrum on August 10th, 2009 by Joerg – 2 Comments

We all know those high-tech solutions that show the time left to a certain event. There are huge LED-Displays, Dashboard-Widgets or even iPhone apps.

countdown For an upcoming release of our software a colleague installed a very low-tech version.


You just need:

  • a tape measure
  • scissors
  • a wall (a glass wall in our case)
  • and something to attach the tape measure to the wall (some Scotch tape or Blue Tack will do)

Attach the tape measure to the wall and cut a centimeter off each day. That’s it.

It should not be a problem to raise the budget for this solution. Most of the stuff will be around in any office. A tape measure can often be found in furniture stores for free, although a plastic tape measure for a few cents usually looks much better.
I love this kind of low-tech solutions. It’s a nice contrast to the high-tech around and even marketing can understand it.

The Good, the Bad and the Ugly of one week sprints

Posted in agile, management, scrum on March 15th, 2009 by Joerg – Be the first to comment

I recently saw Bob Martins Keynote on Øredev. Around time index 14:30 he is talking about length of iterations. This reminded me on some experiences we made recently when trying sprints of one week in some of our teams. So here are some aspects we found.

The Good

  • Scrum zeremonies are done very often. The people on the teams were used to scrum, but the teams were new. So the training effect of doing planning, review and retrospectives so often was good. By the way, the zeremonies are proportionally shorter. There is no waste of time just because there done more often.
  • The short iterations gave a good feedback on where the project was going and how long this will take.
  • The focus is very high on completing the sprint-tasks, but this is not only a good side. See also the Ugly.
  • Teambuilding happens faster than with longer iterations. I think this is mainly, because teambuilding needs all phases of an iteration to be completed and shorter iterations mean the phases happen more often.

The Bad

  • Tasks need to be prepared very well. A one week iteration is not only challenging for the team. It is even more challenging for the product owner. Tasks need to be well prepared and small enough to fit into one week.
  • Some people on the team will not like such a short iteration. You need to get the commitment of everybody that they want to try this for a while.
  • Things that go wrong, hurt faster and harder. This is good as long as the real reason will be removed. But it is easy to think of the short iteration to be the problem instead of the real reason.

The Ugly

  • As already said, it is easy to get in a situation where the one week iteration is seen as the problem even if there are other reasons. This can remove this option for the future. So make sure the situation is ready, before you try.
  • People can feel like being in a hamster’s wheel. This prevents from taking a step back and seeing the whole picture. Short sprints can show a lot of problems in the process, but they can hide larger issues or prevent alternative approaches. Everybody just feels they have no time for it.

So what is your experience with one week sprints? Is it just like Uncle Bob says: “It takes a real man to do one week iterations”?