Sprint or Marathon?

I have spoken to many candidates, clients and other ‘agile authorities’ and one point where I find inconsistency is the disparity between the duration of sprints within a project. These sprints seem to range from 1 week to 3 months, and in my opinion 3 months is more of a marathon than a sprint.  I am beginning to wonder if the Agile Manifesto itself needs refactoring.  The principles it laid out seem to have not been disregarded but refactored somewhat and quite rightly so, as one of the key principles is adaptiveness.  This disparity of the length of sprints is just one of many idiosyncrasies that perhaps could be clarified if the Manifesto itself was given a ‘make-over’ to reflect the current trends.  Perhaps this would result in an improved standard of ‘agility’ rather than an ever increasing volume of diluted principles. In my opinion there seems to be a whole host of individuals who could do with an Agile MOT of sorts.  Certification keeps rearing its head, but is that really the way forward?  (Even I, as a humble recruiter, have passed the DSDM Agile Certified Project Leader Exam.) There must be a way of validating projects as Agile, and therefore being able to provide some quantifiable means of assessing people’s real experience rather than their classroom or paper copy knowledge.

4 Responses to “Sprint or Marathon?”

  1. Andy Pols says:

    When you say ” I am beginning to wonder if the Agile Manifesto itself needs refactoring” – it’s not refactoring you are talking about as refactoring is making changes that do not not change the external behavior…. check out http://en.wikipedia.org/wiki/Code_refactoring

  2. Simon says:

    What I was trying to say was that the definition of Agile itself does not need changing (The main aims, ie. the external behaviour, do remain unchanged), but some of the processes and policies have evolved so perhaps they need redefining.

  3. Neil Martin says:

    Simon
    I have to say i also run super fast sprints to do clean down defect runs and in preparation for releases and they can last 2 days.

    We dont even bother with a card wall for these we use a big white board and we list them and then the pairs just walk up and cross them off as the defect is fixed and passed to QA. I think its about doing what is right for your environment.

    We quite often for focused developments use LEAN style card walls pulling the cards through the lanes into different areas of responsibility.

    But we also use more traditional card walls for our Day to day dev streams .

    I agree with you i just think you have adapt and do what is best in your environment.
    neil

Leave a Reply

You must be logged in to post a comment.