The last month has been spent working with new people, on new things, in new ways. It’s been a great experience, but no great learning is complete without a little retrospective and internalisation of what’s happened. Interestingly enough, though, I have learned a lot more about running a waterfall project better than I’d expected.
Here’s a few thoughts..
Doing agile properly is definitely something of a mindset. You can’t just run the ceremonies and processes and maintain a rigid mindset. Agile is intrinsically collaborative, incredibly open, and relentlessly value focussed. In waterfall projects, because the value is often a long way away it’s easy to lose focus. In the agile world that’s not the case.
Openness and collaboration are things that I always tried to encourage and foster on my teams. I have had varying degrees of success in doing that, but here are a few things I see now that I could have done better.
Reporting, not collaborating: I allowed my projects to get caught in a cycle of daily reporting upwards on progress. Only one or two people represented any given team, as the mouthpiece. The cultural impact to the team was simple; we were being watched, and issues were essentially always escalated through this reporting process.
The daily stand up has a very different focus. It focuses on units of work (stories) and elaborates for the entire team what’s going on, whether there are any blockers, sharing any interesting learnings or successes.
If I had my time again, I’d be pushing back on incessant reporting and encouraging people to attend daily stand ups, with that cultural mindset, instead.
A reasonable workload
I’m generally estimating as it comes, with the greatest amount of information available at that time. In contrast with the general practice on large waterfall projects, this means that I’m generally much more accurate and, most importantly to me personally, therefore not working crazy hours to hit a deadline. [Read more »]