Continuing our series of industry perspectives, I recently chatted with Laura Brandau, an experience Business Analyst and editor of Bridging the Gap blog.

Jama: Laura, how long have you been advising organizations on the best practices of requirements management?

Laura: I have been involved in various aspects eliciting, defining, reviewing and verifying software requirements for the last 7 years and established business analysis practices in two organizations over the last 4 years.  As a BA consultant, I’m always looking to help organizations improve the value delivered by technology solutions and a core competency is getting the requirements right.

Jama: During your experience, which aspects of the software development process have you seen evolve over time and which aspects have remainded constant?

Laura: What has remained constant is the core challenge of bridging communications between business and technology teams.  Individuals on both sides tend to have very different perceptions about what success means and how to get there.  The best software development teams engage the business in understanding what they want and need and are proactive in offering up solutions.  The best business teams are clear with their requests, communicate how they perceive value and are open to alternatives.  In successful organizations there are some powerful communicators (project managers, product managers, business analysts, architects, technology managers and the like) facilitating this level of communication.

What has changed, at least in my experience, is the delivery mechanism for requirements.  We are seeing things shift from large, difficult-to-consume requirements specification documents to smaller components, such as use cases and user stories.  Another significant change is in the proliferation of available tools and services.  When it comes to smaller projects, organizations are much less likely to invest in building software applications from scratch than they were a few years ago.  The cost of building versus the value of buying or leasing is tipping.  This changes software development cycles, especially the requirements process, significantly.

Jama: What compelled you to start your Bridging the Gap blog?  What specific gap did you see between IT and business that needed to be addressed?

Laura: I am passionate about being a business analyst and wanted to make a contribution to the profession by sharing my experience and perspective.  The gap I saw was that our profession focused more on process and deliverables and less on the proactive communication, leadership skills and professional talents necessary to achieve valuable results through technology projects.  BAs can and should be leaders in their organizations by helping the business understand what they want and need, and facilitating the delivery of the best possible solutions.  To achieve this level of business architecture/analysis, emphasis needs to be on the partnership and collaboration over and above the process.  I address these ideas in my blog by sharing my experiences and providing practical insights.

Along the way, I’ve been lucky to cross paths with many people who share many of my views and professional values.  So what started as a bit of a soap box has become a more collaborative blog.  As such, my focus with Bridging-the-Gap.com is to provide a forum for sharing perspectives.  Some tactics I’ve implemented so far are linking to relevant, topical resources and initiating a guest post program.

Jama: What’s your perspective on the role of requirements management for organizations adopting newer Agile development methodologies?

Laura: Agile represents many significant shifts in the requirements process and there are whole books written on this topic.  I’ll speak to just 2 of the core differences I have experienced.

First, requirements become fully integrated with the delivery cycle.  In traditional methodologies, requirements were specified upfront and the problem of delivering them iteratively was left to the project management and development team.  Often times, the testers felt the brunt of this problem as it was never quite clear what requirements could be tested in a given iteration.  Agile pushes this activity back to the product owner or requirements manager.  Aligning requirements with delivery eliminates questions about what “done” means and those dangling requirements at the end of a project.  But, as an organization implementing agile, recognize that you need to establish a new set of accountabilities for the person(s) in charge of requirements and that fulfilling these objectives incurs some additional overhead.  The delivery efficiencies seen by agile teams are not free.

A second fundamental challenge organizations should prepare for is maintaining a focus on value while managing requirements in a highly iterative agile cycle.  Traditional methodologies support fairly long runways for upfront definition of a product concept, project planning and requirements analysis.  In agile, emphasis naturally shifts to delivering working software in the next 2-4 weeks.  It is an understated challenge to maintain this delivery momentum and create valuable working software.  Under pressure to define requirements and make good decisions quickly for the current or upcoming sprint, it’s easy to side step the big picture planning and prioritization activities that keep us focused on value.  I’m encouraged that we’re seeing a lot more about getting the requirements right in agile within blogosphere discussions, particularly from Mike Cottmeyer’s and Dean Leffingwell’s series of posts on the product owner role.

Jama: Bonus music question – If you were stranded on an island and had only 1 album with you, which would it be?

Laura: It would have to be a mixed CD of sorts.  I have rather eclectic music tastes and the CD would have a bit of everything – from country to hip hop, some classic rock and roll, jazz and blues.

Jama: Thanks Laura for the insights.