Thanks to Gemma Cameron (@ruby_gem) for providing the impetus for me to blog again for the first time in ages.
A colleague of Gemma's - Jim Jeffries (@jjeffries1) tweeted today that breaking a waterfall project into sprints didn't make you agile.
Whilst I agreed, I felt that I'd been noticing that certain practices could yield benefits to teams even if their understanding of them, or more importantly *why* they were followed was quite shallow, and so I asked whether Jim felt that it could be a step in the right direction.
For instance, imagine a new starter into a team which observe a healthy daily stand up meeting. Does this person need to know the alternatives to this ceremony and have a deep appreciation of the principles which went into formulation of this ceremony, in order to enjoy its benefits?
Jim clarified that in his scenario, the only change from waterfall he was thinking of was to call each phase of the waterfall project a sprint, for example Sprint 1 == Analysis, Sprint 2 == Design etc.
Had this not been the case, had the scenario been breaking a long waterfall project into sprints but also enforcing that a product increment be released at the end, then I think that its possible that this might be a beneficial step towards agility - even if no depth of understanding was reached.
I think that a person's 'journey towards agility' is quite fractal, and that you can keep coming back to old practices and beliefs and re-analyzing them after you've had new experiences and learned new things.
And I think that you can, in some contexts, "fake it until you make it" by copying the practices of those who have been on the journey before you, and still gain at least some of the benefits.