Retrospection and learning time

Just recently, my engagement to my project since Nov of last year has ramped down. So the past couple of weeks has been a time of transition for me into my upcoming project and also from me to the new PO of my previous project. This allowed an opportunity for retrospection, and also a chance to pick up on new stuff.

While looking up the available knowledge sharing platforms within the company, I came across the option to host stuff in our enterprise GitHub instance. One link led to another, and I came across…

  • MkDocs – This is for project documentation; it allows the use of Markdown for writing content, and then you generate static site contents from that.
  • Documentation as Code (docs-as-code) – While I’m not a programmer, getting familiar with the concept wouldn’t hurt. And as I read more, it’s not really exclusive to programmers.
  • Diagrams as Code with Mermaid – Part of the family of stuff-as-code, this doesn’t trail far behind. I think what I find promising about this (apart from being free) is that this is going make comparison of versions easier since you’re comparing text files.

As mentioned, I did some retrospection. I collated some of my personal lessons learned and posted it in our project’s Confluence page. I also revisited Software Development’s Classic Mistakes. I tried rereading The Scrum Guide and some stuff on anti-patterns to see where we’re somewhat deviating (for guidance if it’s something we should continue or if we should “realign”). Then I tried to pull out project-agnostic stuff that could be helpful to me for starting a new Agile Scrum project and collated my notes.

With the notes in hand, I’m starting to use it as a reference for the new project, and I plan to just tweak accordingly as I find other useful stuff to add in. At this stage, there’s already a team working on the prototypes, and in theory, they’re prepping the solution or the design which will be handed over to the implementation team. So I’ll be keen on learning a lot more and looking for process improvements for the handover from Design Thinking to prototyping to implementation. Exciting stuff! 🙂

On retrospectives

When things slip, a typical reaction is to add processes especially for tracking and monitoring. Just take the overhead effort for effort tracking for example. I’ve been in a lot of projects that at one point or another have gotten so delayed. A knee-jerk reaction is to have the team prepare more reports — daily status updates from everyone, summarized daily progress reports from the leads, reports for upper management, reports for client, etc, etc. This has its benefits — it provides more visibility on what’s going on in the project, and it can pacify stakeholders since it gives the impression that you’re on top of things. What it doesn’t do is get more of the actual needed work done. It doesn’t get more work coded. It doesn’t get more tests executed.

dilbert-19950217

Instead of just diving into the “more reports” bandwagon, what I’d like is for the team to look into how we’re currently doing. What’s working for us? What isn’t? What do we need to do differently? These are questions that usually get asked in a retrospective meeting. If we google “retrospective”, a definition that turns up is “looking back on or dealing with past events or situations”. Reflecting on what has happened is but a part of it. In retrospectives, you also try to identify what you need to bring forward to keep your project successful or to recover so that your project will (hopefully) be successful.

I think I can pretty much go ahead and do a little retrospective on my own. We all can do it individually. But that just won’t suffice. I can plan all I want but if the folks who will execute are not aligned with the plan, then the plan will just fail to materialize. And you can come up with all brilliant sorts of ideas and workarounds but if you can’t get the other guy to execute then it wouldn’t matter so much (but I’ll credit your brilliance, of course). Retrospectives need to be a team thing. WE need to come up with plans for improvement that WE are ALL willing to execute or follow through. In the end, there is no one else to drive the project’s success but US as a team.