I have always had a concern about the way User Stories are sometimes regarded as all you need to build something.  Don’t get me wrong, they are a good technique to focuss the mind and provide high-level statements of intent.  The problem is when people do a workshop, come up with a set of stories, and before you know it development is starting.  Very worrying.

Before User Stories become the norm, people used a variety of techniques for expressing these statements (the requirements in other words…) but often it became problematic.  Typically you ended up with granularity problems – some statements represented massive pieces of work taking weeks or months, others were very small, but hard to progress because they had a large number of dependencies.

User Stories at least give an ‘out of the box’ solution to some of these issues, but they still need to be supplemented by something more.

“I think we’ve demonstrated on this project that you can build a system just from User Stories”  One lead developer said to me not so long ago.

“Of course you can” I said. “You’ve been on the project for a year and a half. You’ve had time to build up your knowledge. What if someone new came in with no knowledge of anything?  How confident would they feel, do you think?”  Silence.

He had a point, of course.  If you are woking on something for a long period you have the luxury of getting to know it ‘inside out’. This gives you the ability to ‘travel light’ and also gives you the confidence to think beyond the work itself and to start considering about how you structure and organise it.  The lead developer in this case probably didn’t need the User Stories either, frankly.

Being on a single thing for a long period and getting to know it intimately, is what you would expect in the lean world, given it’s background in production and manufacturing. In production environments people will be working in gangs or on lines doing a single activity. They become experts and then gradually become confident enough to make judgements about how the process itself should be altered.  It occurred to me the other day, that most of the ‘lean’ and ‘agile’ proponents I have met within IT, also tend to be people that are working on single products or single developments and have done so for some time.  They are therefore, to some extent in a ‘comfort zone’.  I never seem to encounter many ‘lean’ proponents that are spread across multiple projects with multiple stakeholders, and that require multiple domain and technical knowledge day to day.  This might be pure coincidence of course, but personally I think it is quite significant.  The people that work in this type of environment are the ones less likely to want to ‘travel light’ and more likely to want a different approach to agile – or rather agile ‘supported by something else sitting outside it’ perhaps.

As I have said previously in this Blog, if you think User Stories are all you need, all I can say is – good luck.

« »