I'm Matthew J. Morrison.

A Passionate, professional software developer & hobbyist; Language nerd & regular user of Unix, Python, Ruby & JavaScript.

Fork me on GitHub

Welcome to the 11th installment of My Crusade for Agility. In my ten previous posts I’ve discussed just about everything I can think of relating to championing agile adoption at my place of employment. This is a very exciting installment because we just finished our first development sprint. We definitely have room for improvement. This week was a very unfortunate week to be ending a sprint, and maybe last week was an equally bad week to start one for lots of reasons.

The reason that this was an unfortunate timing for a first sprint is because:

  • We just got new hardware, so there was downtime setting that up.
  • I am taking vacation for the second half of the sprint, so we will be short-handed.
  • We are getting a new team member this week, so there will be some training and whatnot involved with bringing them onboard.
  • One of the first issues that I noticed with this sprint was that we “finished” all of our stories on the 7th day of a 10 day sprint. So our planning was off and we ended up without enough work to do… or did we? The reason that I say, “or did we?” is because of the second issue. The second issue is that besides the story and task cards we didn’t have any acceptance criteria or acceptance tests so as we “completed” most of the stories they seemed to drag on and we continued to code even though the card’s criteria was fulfilled. That seems like it could get dangerous because we, the developers, start to make assumptions about how things should work. Another issue is that now that all of the code is written, unit tested and deployed to staging it has not been QA tested.

QA testing is a very important thing that needs to happen. Since we finished the development work with 2 days left we, the developers, could take off our developer hats and put on QA tester hats, however developers don’t make good QAs. I say that because if I write some code, then QA test that same code there is a good chance that I am going to be aware of the brittle bits and intentionally avoid them. The whole “switching hats” idea that I mentioned before starts to seem pretty waterfall-ish. We do not currently have a dedicated QA testing team member, hopefully we will one day.

I think our biggest issue that needs to be resolved, at this point, is our broken feedback loop between completing development and QA testing. The reason that loop is broken is pretty obviously a gap in staffing. There just isn’t anyone at our disposal who can dedicate their time to quality assurance. Unfortunately, adding to staff is completely out of my control (not a responsibility that I want, btw).

Finally, because I’m going on vacation our retrospective is probably going to be delayed. I think it would be ideal to deliver all of the QA tested and signed-off-on changes sometime on the 9th day of the sprint, have the retro meeting that afternoon or on the morning of the final day then demo everything on the final day. That, unfortunately, is not going to work out this time (for me at least - maybe this is something that the rest of the team will do while I’m gone).

At the end of the day, and the end of this post, I think sprints are going to be a huge win for my team. Adding a full time QA team member would help improve our process significantly, but in the meantime there are plenty of things that we can improve. I plan to write more about our first sprint after we have discussed it as a team, so tune in next time for the 12th edition of My Crusade for Agility.