Agile Retrospective: Summer Internship Hackathon

Herndon, Virginia – This past Friday marked the end of the 3rd week of our 6 week Summer Internship Hackathon and we all agree that Fridays are a great day because we get to demonstrate what we have accomplished at the end of our sprint, we get to perform a sprint retrospective and observe lessons learned, and we get to end the week and plan our weekend.

We always start our retrospective with a list of things that went well this past week.  It is uplifting to talk about what went right.  This week, those include:

  • Kanban board – the Kanban board lets everybody know where we are, what is left to be done, and the progress we are making
  • Best practices – many of the interns have learned How to… do something but they haven’t learnt best practices like version control.  We continue to introduce best practices every week.
  • Self organization – scrum teams, by nature are supposed to be non-hierarchical, self-organizing.  We were very impressed with how self-organizing these interns seem to be.

Of course, we learn the most from our mistakes and failures.  So,  we managed to list some opportunities for improvement and action items to make our subsequent sprints work more smoothly and perform at a higher level:

  • Last minute pushes – the demo should go smoothly.  This is the opportunity to show your stuff and be proud.  But, when you make a last-minute push to the staging branch, there is a high risk of failure and bugs.  We made the unfortunate mistake of pushing at the last minute and, of course, there were unintended negative side effects that caused the demo to fail.
  • Rigorous testing – when a developer proclaims that a user story or task is done, I know that it’s not really done.  In fact, it is “ready for testing”.  When the demo happens, it is inevitable that the environment changes, variables change, and people try unexpected things.  It is imperative to perform rigorous testing, with people not involved in the coding, to ensure that all the problems and bugs have been fleshed out.
  • Unit testing – before code is pushed to production, it is very important to perform unit testing and automated testing prior to the push.  In fact, the push should fail if the test fails.  The team needs to start thinking about Test Driven Development (TDD) and automated unit testing so we can ensure that all new features, branches, and software works individually and with its new environment prior to integration.
  • Better definition of done – Definition of Done (DoD) is always the stickler.  The expectation gap, what the Product Owner (PO) expects or envisions verses what the Developer expects or envisions is usually wide and different.  It is so important that the team include the product owner and that the product owner remain highly engaged and interactive with the team throughout the sprint so that definition of done can be clarified.  The team should not seclude itself and the product owner should not disappear.  There must be a level of transparency throughout the sprint to ensure alignment and clarity of definition of done.