In a world where “Waterfall” is the cardinal sin, and “Agile” is the new faith, how do we as Business Analysts keep structure and stay in control without being swept back down the waterfall? To discuss this topic  the IIBA NL Chapter held a knowledge sharing session on Agile User Stories and Documentation on a warm, sunny evening at the end of May. The venue? ABN AMRO’s office at the Foppingadreef, conveniently located only a few minutes’ walk from Amsterdam Bijlmer Arena station.
 

At arrival, the members of the IIBA were welcomed by ABN AMRO staff and led to the Congress room where food and drinks were arranged. Even though the location was a bank office, the setting was fairly informal and allowed for easy exchange of knowledge, experiences and general talk.
 

I was walking past the various groups of people, a sandwich in my left hand and a Coke Zero in my right. This was my first time attending an IIBA knowledge session and, frankly speaking, I wasn’t sure what I could expect. Well, apart from “knowledge sharing”, that is. I glanced at my bag which contained a little old fashioned paper note block. I usually take notes at knowledge sharing sessions, sometimes to turn these notes into articles for those who couldn’t attend. When this news got out, I was asked if I could share my insights. Capture a bit of the magic of the evening.
 

While certainly this session was not a magical ball from a fairy tale, the ease with which the interactions took place, and the ease people included the new face (me) in their conversations was somewhat remarkable. Every person in the room had chosen to sacrifice their warm, summery evening for a work related knowledge session. Everyone had come with certain expectations. Some wanted practical examples to go with the theory they’d read. Some wanted tools to deal with little hick-ups in their Agile projects. Others were just starting on their Agile journey and wanted tips on how to write proper user stories.

A mere two hours later, all these people left with the happy feeling of having their expectations met. The talks delivered had been brimming with flow, tools, examples and interaction and were overall entirely too short to touch more than the tip of the iceberg called Agile. But they had been useful to both new and experienced practitioners of Agile Business Analysis. Kees van Wingerden and Maarten Leune had done a wonderful job in informing and engaging the audience.

Now, here I am, with fourteen pages A5 of handwritten notes, faced with the admittedly daunting task of trying to convey parts of the evening. How much atmosphere and how much information should I include? The PowerPoint slides, albeit in Dutch, would be available by request. But many of the things covered are not explicitly stated in the slides. So many insights from the attendees. So much implicit knowledge. Would people benefit from me writing down the talks from memory?

What information should I include or focus on? Should I focus on models where you’d have all process or architectural information captured in one image with a few pages of explanations. I would need to include the personas who represent the end user – the person for who we build the application. By knowing them, we can focus on use case examples and ask ourselves how the user (persona) would react to certain changes. No, maybe I should do something about how the user story format of “as a… I want.. so that…” helps keep in check who your stakeholder is, what the business need you’re covering is and what the requirements are (the last via acceptance criteria). At the same time the stories can be used for test case writing and fulfilling the role of functional documentation. If they’re small enough, that is. So then I’d continue with how you can slice these user stories down to very small pieces of business value that can be tested (maybe even automated so that you’ll always have automated checks for the project). Or maybe how you should have less up front project documentation, but keep the product documentation up to date. Your documentation should be functional and reflecting reality. Living documentation, if you will.

 

Documentation. This article could be a document where I try to write down everything I learned, everything I heard during the evening. But would I ever be complete? Would people bother reading it? If I tried to write everything down, you’d be reading a 159 page document (or at least five pages A4, as that is how far I came with my original summary document before changing tactics). But that would be ignoring my reader’s needs – business people with little time. That would be ignoring the desire for functional documentation. And most of all, that would be ignoring one of the points the speakers tried to make: Documentation is good, but keep it minimal.

There is explicit knowledge (in writing) and implicit knowledge (in our heads). The explicit documentation is for the high over points, maybe with high risk details mentioned to prevent everything from going down in flames the second a big red button without label is pushed (you see, in the documentation it explains the button is the self-destruct mechanism). The implicit knowledge is fast, flexible and Agile. And you access it by talking. Not writing. Not documenting. Not by sending twenty mails to and fro. Grab a coffee (or a Coke Zero), grab a person and TALK. Talk with your customer, your stakeholder, your team member, your PO, that random attendee at a knowledge session in May. Have a conversation and learn.

So that’s what I’ll do. Record the bare basics here, point you to the slides (you can request them via info@dutch.iiba.org) and invite you, my dear reader, to attend the next knowledge sharing session (check the IIBA NL Chapter site for details). Come attend and mingle. Ask away. The IIBA NL Chapter and its members are looking forward to exchanging knowledge with you.