Hello fellow Salesforce Citizen Developers!

I’ve been working in some technology related function for most of my working life.  One of the key roles I have done is that of analyst.  Now analyst can mean different things to different people and even different things depending on the context of the work.  For this post think of an analyst as the person who helps the business clarify what needs to be done to meet a current business need.  In other words, analysts write requirements.

I know that some of you are cringing now with that simplistic definition but the point of this post is not to extol upon the definition of an analyst but to point out some key differences I have encountered regarding analysis work when working within a waterfall methodology and when working within an agile methodology.

Let’s first get some clarification around “waterfall methodology” and “agile methodology” in the context of this post.  In my experience what we call “waterfall” is basically defining everything that the business needs or wants upfront, documenting in detail each item, developing the solution, testing the solution, deploying the solution.  You can think of a waterfall where at the top is the business saying what it needs and at the bottom splashing into the river below is the deployed solution.

As for “agile” the steps are similar but the work is done in small increments (called sprints) and pieces of the solution are delivered earlier than with waterfall methodology.  You also need, as I discovered, to unlearn some things you did in “waterfall” or the analysis work will bog down the agile process.

So what have I found that I needed to change to more effectively work within an Agile methodology?

Create “Good Enough” Requirement Documentation

In Waterfall it is common to create a massive Business Requirements Document (BRD) that details every little thing.  You review it with your IT team and then walk away while they create a solution.

For Agile the business and tech work much more closely together so a doorstop of a document isn’t needed or, for that matter, wanted.  Instead the analyst should facilitate meetings between business and tech and talk through what needs to be solved and why.  The group then defines the requirements (stories) together at a level of detail that is good enough for everyone to be on the same page regarding the solution.

Meet More, Document Less

I like to create documents.  There I said it!  I even used to be called the Doco Queen because I created some whopping huge and detailed Business Requirements Documents.  I also prefer to send all my fabulous documentation to folks to review instead of meeting. I have since learned that this is not the best way to get things done in an Agile way.

When you only have a sprint (typically 2 – 3 weeks) to get something defined, developed, tested and accepted you need everyone in the room and talking through each requirement.  Even for a team not located together, talking things through via phone, Skype, telepresence or some other mechanism, is preferable to reviewing documentation.  You need the give and take of a conversation to understand what the business needs and how you might go about building the solution.

So I have learned to document that basic requirement in the form of user stories and leave the details to the group sessions (typically called “grooming refinement sessions”).

Define What is a Success

To help everyone understand what “done” means regarding designing and building a solution, I have learned for each and every requirement the high importance of answering the question – “How do I know that this requirement has successfully met my business need?”

As an analyst this is an important part of the job when working with business partners.  Helping them to articulate what they would need to have/see/etc in order to consider what has been built to successfully meet their need.  This step can be hard for some folks but it is vital.

In Summary

So as a citizen developer I wear the analyst hat often and with great gusto.  I just need to remember to put on my Agile Analyst hat when I am working within an Agile world and define good enough requirements with only what’s needed documented including well defined criteria for success.