Sometimes I find it difficult to explore new pieces of work in a structured way. When given a new challenge / piece of work it’s easy to jump straight into a solution. However as BAs we first need to understand the problem area better.

As more organizations move toward agility, development and project management teams still struggling to define a common language and standard regarding the agile framework. In addition, many organizations that are implementing agile approaches have not fully planned the transition and are still unclear on how to fully optimize the approach. One area that continues to remain vague is the role of the business analyst (BA). Below are some steps to help business analysts navigate their way through the transition to agile and add the most value to their agile teams.

Surely facilitation is an important part of a business analyst’s job, but it is far from the only part. Analysis in itself should always form the core of a business analyst’s responsibilities.  We are called ‘analysts’ for a reason! Facilitating information gathering and translating it to ‘requirements’ doesn’t make you an ‘analyst’. Go above and beyond, and add value by ‘reasoning backwards’ and ‘reasoning analytically’.

One of the Sidebars to the Business Agility Manifesto introduces the notion of Reconfiguration Agility. It’s a fundamental capability your organization needs in the Knowledge Age. What’s it about?  In the big scheme of things, you have two basic choices for conceiving, and ultimately implementing, business capabilities: procedural or declarative. They are fundamentally different.  Traditionally, the vast majority of business systems have been modeled and constructed on a largely procedural basis – virtually all things tied together step-by-step in processes. Unfortunately, that procedural approach simply doesn’t scale.