Agile methods have a gap on how to do deal with requirements that often leaves business analysts confused about what to do. From an analyst’s point of view, user stories seem to be the only technique agile methods prescribe. When people are new to agile, they take this as agile’s “only” way of modelling requirements. What isn’t made explicit often gets forgotten, so I want to make this clear: Agile methods don’t discourage thorough analysis or modelling. They don’t discourage the use of diagrams and other visualisations that help people better understand and refine their domain representation. They want everyone to focus on value and communication by using the rights tools for the job.
When coaching analysts, I often find myself telling them, all the tools they draw upon to question, to challenge, to refine and capture their understanding is important. Agile methods focus on better understanding of value, not better note taking. Writing things down does not automatically translate into understanding between two people. Cockburn’s already demonstrated a model that talks about the richness of communication methods, with written documentation being one of the worst.
The best business analysts I’ve worked with have little need to write things down, having absorbed what needs to be done, understood the real requirements, and constantly available ready to help clarify them. Conversely, the worst business analysts see their job only as writing “requests” and “demands” down, doing little to question and challenge what is really needed versus what is merely articulated. These I call overpaid scribes.
Question what value your tools are using and if they help you either better understand or better communicate with other people. If you find modelling in UML helps you better see relationships, do so but avoid spending all your time polishing the model and getting the syntax correct. Be wary of investing yourself too much in one particular model or document that makes you potentially more resistant to changing it. Neal Ford describes this as Irrational Artefact Attachment. If you find yourself writing something down to remind yourself of what is important to get across, do so but don’t use it as a way to avoid helping others understand it.
Agile methods appear nebulous to many people because “user stories” simply appear. It’s not prescriptive about how you get there because there are simply too many different ways to get there. Whilst being prescriptive will help some projects, it would no doubt hurt many others.
Image of Shh! taken from Anthony Gattine’s flickr stream under the Creative Commons Licence
I wonder if the phenomenon you describe is an instance of a more general pattern of behavior. When people are learning about any new process, framework, methodology, set of practices (or what-have-you), they seem to have a tendency to assume that anything not explicitly spelled out in The Book that defines the new methodology must not be “allowed” when using the new methodology. If true, I would chalk it up to general human silliness. It’s funny that we have to keep telling people it’s okay to do what makes sense, even if The Book doesn’t mention it.
BTW, when you coach “analysts,” do you encourage them to expand their skill sets along the lines of the generalizing specialist concept, so that eventually we can reduce the problem of role silos?
One of my “Greatest Misses” involves time spent asking business analysts to provide really small stories, and only stories, to the programmers while they get their design house in order. I needed the stories small enough that the programmers could feel a sense of completion every few days. (I hadn’t yet seen how to foster closer collaboration, so I punted on that for the moment.) I stressed to the business analysts not to provide the kinds of analysis models they’d provided in the past, because I wanted the programmers to focus on minimal design from examples.
Somehow, the lead business analyst interpreted from all that “Don’t draw diagrams”. That floored me. He spent almost a month trying to work this way, not modeling and not drawing diagrams for himself, before he finally brought his objection to my attention. I couldn’t believe it. I had to tell him that he should draw whatever diagrams and prepare whatever models help him understand the problem, but that I didn’t want him to expect the programmers to use those models to drive their design. He thought I told him not to model!
I learned from that experience to pay closer attention to what people do once I give them any kind of instructions. They might find a way to interpret them to do them harm, rather than good, and I have the responsibility to stop that as soon as I can.
@Dave – I agree with you that this is definitely a pattern of general behaviour. It’s the same thing I think we see when new methodologies hit. Methodology X doesn’t encourage Y but we do…
Re: Expanding the skills of analysts – I encourage analysts to take ownership of more than just one functional area and to understand a bit more of the technical issues. I haven’t found much success trying to get them to take up development skills with the best success helping them relate to development problems. This probably deserves a whole other post.
@J.B. – I’ve found myself in a similar situation and learned from this. I think it’s natural for people to hear “do X” equivalent as “don’t do Y” as a blanket statement. I agree with you it’s important ot pay very close attention to behaviour after giving instructions. Thanks for your story.