I’m writing up how the planning went wrong in our last sprint, because I find it interesting thinking about how it actually went wrong, and what I can do to prevent the same sort of issues in the next sprint.
First off, here’s what our software is supposed to do:
- It integrates into a (payment) system developed by a third party.
- Within the framework as defined by others, the main method in the component receives a parameter, which contains information that can be used to get the file name of a file exported by their system.
- The file is in their common format (XML) and represents a batch of debit orders to be sent to the bank, which our code must then transform into a flat file that conforms to the bank’s format. (This is an over-simplification but is good enough for this blog.)
- The third party kindly gave us a (StreamReader-derived) component that reads their file into strongly typed transactions via a GetNextTransaction method.
- I undertook to do the development of transforming the transactions to the flat file format.
- I was aware that the file also required writing one or more headers and one or more footers, but I wanted to take a step back and not be solely responsible for all the functional code this time around, so…
- I tasked our companion (who is no longer with us, pending the result of his performance hearing) with the header.
- No task was created for the footers. Oops.
- No task was created for the “contra” lines, which are summary lines. Oops again.
My task planning was done solely from the point of view of the transactions.
The other developer wrote pretty patterns, a class factory to determine what to do when which bank is involved, and so on. He also didn’t notice that a bunch of things were not catered for in the development.
Lester (the departed developer) didn’t really do anything at all. Well… he did do one thing sort of… The reader component given to us gave access to the file header, also as a strong type. Our dim-witted friend saved that header into a local variable, which he then did not use. (i.e. He didn’t even write anything to the output file. He just saved a reference to something we already had into an unnecessary variable, which then immediately went out of scope. Fucking brilliant.)
Maybe if dumb-ass had done something more, he could have noticed that there was also a second header to be considered, and brought it to somebody’s attention. And maybe then we could have realized that there also two footers and the contra lines. But that didn’t happen.
What did happen was, as mentioned last time, I then did all the functional code myself while the rest of the team slept, and then the whole team had to work late into the night to test that code and fix the bugs, but at least we made it, barely.
I take responsibility for this… I mean, I did not read the fucking manual.
My typing of this entry was just interrupted by our sprint retrospective, and I thus raised RTFM as one of the “What we can do better” issues. Everyone mostly agreed on what I wrote here otherwise… except that they didn’t blame me alone for the issues. Anyway, our major stumbling blocks thus far have been mostly our insufficient pre-planning and then also planning itself.
The main user story for the next sprint is more or less the reverse of what we did this last sprint. (Convert a file that comes back from the bank into the XML format and pull into payment system, which then does what it needs to do, like update subscriber account details, and reverse presumed payments made in the event of failed debit orders.) The main difference this way around is that we don’t have a “reader” for the file; this time I am writing it (I started the prototyping already) and will make sure it does a thorough job, leaving out nothing of the specification. Prototyping it and discussing it with my colleague should ensure that the planning is not lacking this time. (And most importantly for me, though it has nothing to do with the point of this post, is that in this relatively simple project, I get to write the code that is more interesting, leaving the simpler task of writing out the transformed file, and the syntactic sugar of creating pretty code patterns, to my colleague.)