Last night’s XPMan was really good. We did some TDD but with no code – essentially we created tests and then created a sequence diagram to pass the tests. We then applied the RGR (Red, Green, and Refactor) to the sequence diagram as we built up the tests; I found it a really good exercise in returning to the basics of TDD. One key thing for me was that it’s really important to do the simplest thing first and get this to go red before you do anything overly complex. During the second kata and my second pair of the evening this became quite pertinent.
However, there is one discussion which provoked some thought and quite a heated exchange. This came in the form of, “I’m a code monkey and I should just fulfil the requirements given to me by the BA’s/customers.” This provoked quite a debate about if a BA asked you to jump of a build would you do it? Another comment was about reading the Agile Manifesto.
So here’s my 50p worth. Yes I am a code monkey, but professionally I need to question what I’m doing. However, this has to be done in the correct manner – asking what the business value is of a specific requirement/user story is? Rather than just saying no. By asking this question – you are just ensuring that the person asking for the work to be done has considered whether it is valuable. If the answer is yes, then you have to fulfil this obligation to the customer and complete the requirement/user story even if you deem it as spurious. This is the professional thing to do.
It’s really important not to blindly accept what people are telling you what to do, but to ask questions and occasionally say no in the right manner – but the manner in saying no has nothing to do with the Agile Manifesto, more the way you say it.
Maybe an unrelated thing – the Agile Manifesto say’s that we value the things on the left more than the right – but remember the things on the right we still value. Something I sometimes forget about is that we still need a plan, we still need a contract negotiation – it’s just we value the following changing requirements & customer collaboration over the other two.
So yes I am a code monkey, but it’s important to question what you’re doing before committing to it.