“Specification By Example” – Initial Thoughts

I’ve been reading through the excellent “Specification by Example” in it’s early form from Manning. I’ve often struggled with the upstream practises of Agile. Recently I attended a work presentation surrounding capturing requirements and other work which BA’s undertake – it looked very “watefall-isk”! My concern was how to counter this discussion around sign off and the need for documentation.

I’m so glad that I was able to get hold of “Specification by Example” – it’s given me plenty of ideas of how to promote a different way to work. The benefit of living documentation has got to be a good starting/selling point!?

This lead me to ponder what the role of a BA was within an agile/lean organisation. It seems to have been an area that has been left behind over the years. This is primarily due to the fact that most of the original Agile Manifesto signatories where people from the software development field.

I’ve often wondered whether User Stories is all Business Analysts should do; in fact do you need Business Analysts?

Specification by Example answers a lot of questions around capturing requirements in the early phases of an agile/lean project. I’ve tried to map out how I see the process within our organisation – I’m not sure whether it’s what is intended but it’s something that I want to try out in the future:

I will write more about the book, but my first impressions are that I would recommend this to anybody who is developing software, it is extremely informative and well written.

4 thoughts on ““Specification By Example” – Initial Thoughts”

  1. Glad to see you've 'got it' 🙂 I like your picture, although I needed a magnifying glass to read – could you make it a bit bigger?

  2. Hopefully slightly bigger now. Although it's bled in to the margins!

    Still not sure of the benefit of a BA – but I think this all depends on how good your developers are at talking to non-technical people. Which may be a good reason for them!

  3. Hi Dave, firstly I think its very dangerous to dismiss an occupation. It is fair to question how the role fits into 'agile' methods but as with the discussion about devs and testers, do you need both, each brings different skills and mind sets. This feels to me an alignment discussion rather than a 'get rid' one. Going down that route could get very emotional.

    The value of a BA is derived from the teams needs. If you don't have regular access to the user or customer they fill this role. They can gather user stories or even key examples. I'm finding the Given, When, Then forumla very useful for that.

    This does not dismiss the real fact that first hand communication is above all the best. It does allow them to fulfill a real need in the team.

    Looking forward to reading further thoughts on the book. Cheers, Ady

  4. Oops a bit of controversy… It was more a tongue-in-cheek comment!

    I have to agree that the discussion should be around alignment rather than a 'get rid' of one.

    I have a blog post in it's early stages regarding roles in an Agile/Lean team. Watch this space!

Leave a Reply

Your email address will not be published. Required fields are marked *