In this episode, Ryland Leyton, author of The Agile Business Analyst: Moving from Waterfall to Agile, joins us to talk about what it means to be an agile business analyst and how to be successful in an agile environment.

 

After listening to this episode, you'll understand:

  • How a business analyst can support organizational change
  • How to use the Discovery and Delivery framework in an agile environment
  • How to be transparent in your analysis work
  • Why agile isn’t simply a series of short waterfall phases
  • How to use an elevator pitch to show your value proposition

Show Notes

How can a business analyst support organizational change in the move from waterfall to agile?

Think in terms of enterprise analysis. The business analyst is well-positioned to think about all of the impacts of the project across the enterprise including funding, managing, supporting, training, and any number of business processes affected by the product. By keeping enterprise analysis in mind, were able to interface with all affected groups and individuals to ensure any impacts are identified and addressed.

Because of our nature of being communicators and interacting with many areas of the organization, we’re well positioned to help the various groups within our organization to understand the change needed and how to adapt to those changes.

 

Applying the Discovery and Delivery Framework

The Discovery and Delivery Framework provides a way of thinking about what you’re doing in an agile context.  The Discovery and Delivery Framework provides several concepts including:

  • See the whole – Are we looking at everything in the context of the entire system?  One technique to use for this is value stream mapping.
  • Think as a customer – Understand who is going to use the product and the value that the customer expects to get out of it.  Personas and story mapping are techniques you can use to think like a customer.
  • Get real with examples – Do you have an example of how the customer will use the product? This allows you to have a better understanding of how the customer will use the product and any impacts or challenges.  Behavior Driven Development (BDD) is a frequent technique used here.
  • Understand what is valuable – Understanding who the customer is and the challenges they face will help you to understand what will be valuable to the customer and design the product to provide that value in the fastest way possible.  Some of the techniques that support this concept are backlog management and Kano analysis.
  • Analyze to understand what is doable – Understanding what can be done to provide value given what we know about the other areas of the Discovery and Delivery Framework.  One technique you can use here is real options.

Keeping these concepts in mind helps you maintain an agile and value mindset when speaking with customers and stakeholders.

 

Make Analysis Visible with the Analysis Wall

The Analysis Wall is very similar to the development wall, which is a physical wall (or electronic version of one) that shows the progress of a user story.  The progress can include stages such as ready, development, testing, and deployed.

Instead of showing progress of a piece of development work, the Analysis Wall shows the progress of analysis work in getting a user story ready to be picked up by the development team.  Stages on the analysis wall may include backlog, analysis, sent to Product Owner, sent to UX, ready to estimate, ready to play.

The analysis wall allows you to prioritize analysis work, avoids creating a full analysis upfront, and makes transparent the progress of getting a story to a ready state.

 

Iterative vs. Phases

People often ask “Isn’t iterative development just waterfall done in very short phases?”  On the surface, there are many similarities between iterative development and a phased approach.  It can also be a step in the right direction to make your waterfall projects a little more adaptable.

What’s missing with simply implementing small phases is the ability to learn.  With iterative development, the cycles are very short (usually between one and four weeks) to product a tested, working product.  Users can then interact with the working software and provide real feedback that can be incorporated into the backlog and prioritized to adapt the product to the user’s needs.

The faster feedback loops allow you to learn and adapt the product so that you build the product for customer value and don’t build shelf ware.

 

The Business Analyst’s Value Proposition

Ryland has developed a short elevator pitch to articulate the value proposition of the Business Analyst role in an agile environment.  The elevator pitch can help others to understand how you as an agile business analyst can support the team, organization, and its customers.

“As a BA, I free the product owner to focus on the needs, desires, and interests of the end customer.  The product owner can then maximize the value of the full suite of products and features that our company offers.
“While they’re doing that, I’m making sure the project deliverables are analyzed all the way from marketing through ordering, delivery, billing, accounting, and customer support.
“My focus is on making sure internal and external customers will be satisfied, that the impacts identified and managed so the company has no blind spots, and that the development team has a smooth flow of work to deliver”

Elevator pitch from The Agile Business Analyst: Moving from Waterfall to Agile by Ryland Leyton

 

Don’t forget that as business analysts, we can help coach everyone on prioritization issues and proving out the value of the product.  This may include defining minimum viable product (MVP) and prototyping to get early feedback.

Listen to the full episode to hear all of Ryland’s tips and advice.

 

Z

Your Homework

A lot of what a business analyst can do in an agile space is around collaboration.  Here’s are few suggestions from Ryland.

  1. If you’re on a team that’s just starting out, start by explaining to them the value that you bring to the team.  This helps to level set expectations within the team.
  2. For more experienced teams, observe changes from iteration to iteration to have a longer term view.  This allows you to see the big picture while knowing the details and gives you line of sight if the team is going off track.
  3. Above all, you should look for opportunities to collaborate and get feedback.

 

Links mentioned in this episode:

 

 

 

 

Ryland Leyton

Ryland Leyton

Consultant, Slalom Consulting

Ryland Leyton is a Certified Business Analysis Professional and a consultant with Slalom Consulting.  He’s also an agile coach for the Atlanta IIBA nonprofit volunteer program and a frequent presenter at industry conferences.  Ryland is the author of The Agile Business Analyst: Moving from Waterfall to Agile.

Thank you for listening to the program

To get more valuable content to enhance your skills and advance your career, you can subscribe on iTunes.

Also, reviews on iTunes are highly appreciated! I read each review and it helps keep me motivated to continue to bring you valuable content each week.