I was looking back over a post I wrote a couple of years ago where I described some learning cycles that I’d noticed myself going through with respect to code and although at the time I was thinking of those cycles in terms of code I think they are applicable at a project level as well.

The cycles I described were as follows:

I think I’ve followed similar cycles with respect to how an overall project is run.

To start with I didn’t really know what it was that made a project run with an agile mindset different to anything I’d seen previously so I spent a lot of time observing the approaches my colleagues used, the processes they tried to drive and generally trying to understand what made a project tick.

Having worked on quite a few projects and seen similar underlying concepts working despite differing contexts I started to notice that the situations coming up were often the same or very similar to ones that I’d seen before.

At this stage I was more convinced that some of the approaches I’d already learnt could be useful but often deferred to more experienced colleagues or suggested improvements and relied on them to help drive them.

When I worked with Dermot he pointed out that the next step was to now be the one who can drive the changes that I want to see rather than relying on someone else to do it.

I’ve been trying to do that more recently and it’s not all that different to the way that I already try and influence the way that code is designed except it covers a wider spectrum of situations.

Books like 'Fearless Change' and 'Agile Coaching' certainly have good tips for how to influence change but I find that more often than not I only really understand how to do something after I’ve made a complete mess of it the first time around.

I guess the downside of trying to influence situations more is that you put yourself in a position to be shot down so perseverance and knowing when to push and when to back off seem to be skills that will be particularly useful.