- November 8, 2013
#BDD, #data, #development, ...
BDD is an enjoyable way to develop and test, but introduce business and that pesky client, it can rapidly change into stressful Waterscrum or (the even worse) Scrummerfall. Transparency is an easy word to throw out there, but who wants it? No-one wants to hear bad news and show and tells rapidly descend into a perception game, to pander to client expectations of how development process works. As with any engineering, most are shocked to learn that engineering is very much an incremental learning process, involving regular mistakes and learning exercises.
The average client expectation is still of having a tangible product, and not to be drawn into the more painful side of development process. It’s a two steps forward, one step back style process. And with BDD, even more so, as the business side is defining a lot more than just high level user stories – they are defining expectations on more granular level. And in natural language. Why the last point is very valid is that developers inherently have problems visualising the natural language of requirements in terms of code. When in fact a scenario line could be viewed as a chunk of functional code.
When reviewing user stories, where the eyes should immediately be drawn to are the “Given” statements. These generally can appear innocuous, but can hide a whole host of requirements upon development and QA. Usually used to specify location, authentication and test data. Test data itself can be a hugely underestimated task, and usually the specifications are wrapped up the the Given statements. Also smart to analyse any example tables for assumptions. It may look like innocuous input/output data, but it may be referencing part of a system that are not built yet, or have existing caveats.
BDD gives Agile a sledgehammer edge, and all the better for it – as long as you stay on top of the process, and can manage the client concerns over their over-exposure to the process.
- September 29, 2013
The easiest Agile trap to fall in, is tools driving process – I still sail close to that one
… ironic because company executives and human resources say they want self starters, innovative hires, a certain entrepreneurial spirit.
This article, Entrepreneurs need not apply: Companies shun the self employed, comes as no surprise, as companies attempt to hire contractors and the self-employed, as permanent employees. I have been in some comical permanent job interviews over the years, where it is plain they liked my wide variety of skills and experience, but plain nervous when we talk about terms of commitment. It seems that anything I say is met with suspicious eyes, unable to take in what I am saying. I do not lie, I don’t have to – as far as I am concerned, they should be persuading me taking a permanent job is worth my while.
With Waterfall step-down process, a lot relied on skilled people – skilled analysts to interrogate clients for requirements, skilled project managers to keep project on track, skilled developers to code the requirements and skilled testers to ensure the beta release fulfilled the requirements to the letter. And with Agile, it is exactly the same. A change in Waterfall costs more money, and same with Agile. The point with Agile is that change was easier to introduce, and clients did not have to necessarily get all their requirements done from the outset. I am not sure if this was a good attitude to have, given that Agile required a continual feedback loop that included the oft-unavailable client. While clients and management liked the idea of Agile principles, at the same time, they behaved as if they didn’t apply to them. More often than not, clients would become indignant if change involved cost, even though naturally increased time = increased cost. Getting vision right from the outset is a sensible thing to keep in mind – whether Waterfall or Agile.