Why you shouldn’t use sprint as a name for an iteration 2

Posted by Jens Jäger on June 12, 2012

In agile development, especially the scrum approach, we often use the term “sprint” as a basic unit of time in order to measure each stage of the development process. As a definition of time, however, it really does a disservice to developers because the word itself evokes the sense of constantly doing things as fast as possible. Depending how the team is managed, a sprint can be anywhere from one to four weeks–it just has to be a timeboxed effort–but attaching the word “sprint” to every stage, instead of calling it an iteration, can have a detrimental effect on a team over time.

The Negative Connotations of “Sprint”

When it comes to sprints, it’s not the length of time that’s the problem, but the use of the word altogether. As mentioned above, the word “sprint” makes you think of doing something really fast, running headlong towards your goal. This might seem like splitting hairs, but we only need to look at the theory of linguistic relativity to see how calling each iteration a sprint can be harmful in the long run. By holding to the concept of extreme programming all the time, it becomes more and more mentally and physically draining to maintain that mindset. Eventually, you and your team probably start to feel exhausted and overextended towards the end of a project, right?

Sprinting is Necessary, But Not All the Time

That’s not to say that we should do away with the term “sprint” completely. Rather, we should call each stage an iteration instead of a sprint, which is a much more neutral term, and then save sprinting for those times when the team really needs to put their efforts into overdrive. For example, we need sprinting for right before a release date when we know exactly what’s left before the project is finished. We also need to sprint if there’s only a few weeks to go before a trade show and we want to ensure an effective software demo. In the beginning stages, however, we should be looking at the development process as a series of iterations, giving our team the mental breathing room to work at a more measured and sustainable pace.

Seth Godin has a great example in his book, Linchpin, of when sprinting is necessary and why it’s short-lived by it’s very nature. In his example, he talks about trying to launch a major brand of computer games, but at one point was faced with the prospect of the whole project falling through. He spent 20 hours completing the equivalent of six weeks of work in which he thoroughly redesigned the entire project and its launch schedule. The resulting business plan helped him convince the board not to scrap the project, but it was also a burst of effort that was really only possible in that particular moment under those circumstances.

Agile Needs Both Iterations and Sprints

Sprinting has its place in agile because it helps us overcome our fear of doing something wrong since we only have so much time to get it done period. Moreover, sprinting compels us to keep moving forward without worrying about the minutiae that would normally force us to stop and weigh the pros and cons of certain choices. However, we do need to stop and think sometimes; so although sprinting is an important tool in scrum and agile development, we can’t sprint forever. Instead, we should think about each timeboxed stage as an “iteration,” thus giving ourselves the ability to slow down psychologically, even if it’s still the same period of time when all is said and done.

Impressions from ICSE 2012 2

Posted by Jens Jäger on June 04, 2012

I just came back from Zürich from my trip to ICSE. I’ve seen some great talks and had some great discussions in the breaks. Zürich is also always worth a visit. There was a strong breeze at Lake Zürich yesterday. It was sad that I had no time to charter a sailing boat. Maybe next time. Here are some impressions from the conference and Zürich.

The 3C Approach for Agile Quality Assurance 3

Posted by Jens Jäger on June 03, 2012

Today I gave the talk The 3C Approach for Agile Quality Assurance on the ICSE in Zürich. The work on this was in cooperation with André Janus. Here is he abstract of the conference paper:

Continuous Integration is an Agile Practice for the continuous integration of new Source Code into the Code Base including the automated compile, build and running of tests. From traditional Quality Assurance we know Software Metrics as a very good approach to measure Software Quality. Combining both there is a promising approach to control and ensure the internal Software Quality.

This paper introduces the 3C Approach, which is an extension to the Agile Practice Continuous Integration: It adds Continuous Measurement and Continuous Improvement as subsequent Activities to CI and establishes Metric-based Quality-Gates for an Agile Quality Assurance.

It was developed and proven in an Agile Maintenance and Evolution project for the automotive Industry at T-Systems International – a large German ICT company. Within the project the approach was used for a (legacy) Java-based Web Application including the use of Open Source Tools from the Java Eco-System. But the approach is not limited to these technical boundaries as similar tools are available also for other technical platforms.

You can download the full paper on the ICSE conference website.

The slides of the talk are available here:

3C talk slides

Talk: The 3C Approach for Agile Quality Assurance 1

Posted by Jens Jäger on May 30, 2012

Next Sunday (on 3rd June 2012) I will give a talk on the 3rd International Workshop on Emerging Trends in Software Metrics (WETSoM 2012). It’s a satellite workshop of the  ICSE 2012.  The ICSE is one of the largest annual software engineering conferences with a great history. I’m really happy to give a talk there.

The topic of the talk is: The 3C Approach for Agile Quality Assurance. It’s about the integration of software metrics into agile projects. I will publish more details, the slides and the link to the conference paper when I’m back from Switzerland.

Hacking javascript: a contact form in a google maps info window 3

Posted by Jens Jäger on May 06, 2012

One of my goals last year was to be a better javascript programmer. After I finished the travel map I searched for ideas for new small projects. I came up with the idea to add a contact from to a google maps info window.

Beside the google maps api and jquery mapped contact form uses jquery.validate for fancy offline validation. Jquery.form is used to send and ajax request with the entries to a simple php backend. The backend php script just sends an email with the input.

It was a bit tricky to make the form and the jquery plugins playing well inside the map info window. But finally i found a nice solution. Thats how it looks like:



Mapped contact form works really well if you have multiple offices or stores and offer a user friendly way to contact each of them.

It’s available in different flavours for some dollars:

Javascript edition – Mapped contact form pro

Php edition – Mapped contact form pro Php

WordPress Edition – Mapped contact form pro WordPress