Friday, April 29, 2016

Retros Suck

This week I attended a Schaumburg Microsoft .NET Technologies meetup.  The title of this meetup was “Improve your Retrospectives with Agile Kaizen!" and was presented by Angela Dugan.  I decided to attend after reading the first three words of the title, “Improve your Retrospectives”.  In today’s world, there is so much information at your fingertips that it would be very easy to do a little research on Agile Kaizen.  I didn’t know if Agile Kaizen was a tool, a process, or something else.  What Agile Kaizen was didn't seem important to me as I knew Retrospectives suck or at least many of the ones that I attend do.  This was enough for me to want to attend with an open mind without doing any other research on Agile Kaizen.

Overall, the presentation was good with half of it on Retrospectives in general and half explaining Agile Kaizen.  I won’t go into detail on the content, but wanted to share one of the main points that I took from the presentation.  That main point may be obvious after hearing it, but it took attending to really step back and understand.  That main point to me was to get a refresher on Retrospectives.  To be clear, it is not that I don’t know what a Retrospective is and what it should accomplish, but sometimes listening to someone present and go over basics helps you step back and get those basics back into memory.  To me, this is similar to tackling in football or shooting a free throw in basketball.  When you get bad at either of these, you step back and either self-analyze or get someone to explain how to tackle or shoot a free throw.  Simply saying my free throws suck or my tackling sucks is not acceptable and the same applies for Retrospectives.  

With the basics fresh in my mind, I can focus on those first before bringing Agile Kaizen into the mix.  After that, I can try to convince the team to have our Retrospectives at a bar with a one drink minimum for everyone.  Ok, maybe Angela recommended it was a one drink maximum, but I won’t count.


Peace yo!

Thursday, April 28, 2016

It's easy, it will be "done" in 5 minutes

"It's easy, it will be done in 5 minutes" is something that you hear a lot in the development world.  This week, I had a question come through from our QA department that eventually resulted in a small development change.  The time from inception to completion seemed to go really fast, so I decided to see how long it actually took to complete such a small change and the results are below:


8:34 - QA sent an email with a question about requirements.
8:38 - Product responded with clarification.
8:41 - Developer responded with ownership of the change.
8:42 - Developer wrote a failing unit test for the change.
8:43 - Developer made a code change (removed 3 lines of code) to allow the test to be successful.
8:50 - Developer checked in code.
8:54 - Build was successful on Team City
8:55 - Code was deployed to three environments via Octopus Deploy
8:56 - Developer begins verification in all three environments that the change was successful.
9:05 - Developer sent email verification
9:12 - QA verification complete for system 1
9:23 - QA verification complete for system 2

Even though the change was very small and required removing a few lines of code, it still took took 49 minutes to get from an email into an environment where the change can be seen.

So, the next time someone asks why it takes so long to make a change or why you billed what you billed, show them the above or provide the details of your timeline.

I may write a future post and add to this with some real life examples that could have caused this simple change to turn into a multi-hour headache.  The examples that I may introduce are real situations that I have experienced in the last few months and not something that is unrealistic.

peace yo!