Agile Business Analysis (ABA)

Have I grabbed your attention? Yes, 'Look How Far I Have Come' is a song title from the renowned Broadway Musical, Hamilton, but it is also a phrase used by many of us to highlight or showcase their careers and their life progression.

An example perhaps is “I am the CIO now, and this did not happen overnight. Look how far I have come.” In IT, this is used in a similar fashion. From legacy systems, even before, to today—it’s human nature. Look how far we have come, and where we have come from. We were once students getting in line at the University’s computer science dept’ to punch cards for a lousy Fortran IV application, which may have been for a homework or for a midterm/final, and  now we drag and drop to put together an app or a UI (a GUI) for iOS or Android. A huge progress, a long journey (not that long ago actually), on our path to excellence, right?

Have You Heard of “Wa-Agile”?

Post-pandemic, there is a clear trend that technology projects are seeing the highest level of approvals. Everyone is looking to not only grow their technological footprints, but to also achieve it in less time and while on a budget. Agile projects are being planned and executed in every organization, which appears to be the best approach to move forward. 

Organizations following a waterfall model for technology project deliveries have tried to go Wa-Agile (Waterfall + Agile); another popular term used for Wa-Agile is “Semi-Agile.” This is a step forward to achieve Agile maturity. In organizations where Agile is being used for delivering projects, they are commonly moving towards a 90-days to Go-live approach as opposed to the traditional long-term 180+days delivery approach.

How to Know if a 90-Days to Go-Live Approach is for You?

Editors Note: The BPMInstitute is excited to share this article written by Omer Schechter. This article was originally published on Toptal.com, on June 3, 2020. 

Product backlogs are a critical component of product development: Comprised of a prioritized list of features that guides a product from its initial vision to its execution and formal release. By converting high-level concepts into working details, the product backlog facilitates the creation of a product. Let's take a closer look at the key steps and the core elements of a product backlog and how a product manager is responsible for creating, prioritizing, and maintaining it.

Split the Backlog into Two Lists

When creating a backlog, define its scope, whether it applies to the entire company's product line, a subset of products, or just a single product—this helps you manage the features.

Here at BPMInstitute (BPMI), we’ve taught agile business analysis and business process management courses to numerous Business Analysts and BPM practitioners. A frequent question from our students continues to be - can we apply agile to business process management?

The answer is YES! By combining agile with BPM, you can create agile BPM to benefit your organization with more efficiency, consistency, and quality in your BPM initiatives.

Most importantly, you will deliver value to your process users more frequently. 

This new methodology is created by applying the agile values, principles, and concepts to BPM initiatives and projects. The agile software development life cycle becomes the agile BPM delivery life cycle. Agile ceremonies and techniques are adapted for use in BPM; BPM techniques benefit from having agile concepts applied to them as well. 

Early on at Process Street, we knew we wanted to be a more process-centric team. Certain processes had poor adherence (rendering them ineffective), and new processes were only being designed by management. As a result, these processes weren’t being documented efficiently. Without the correct documentation, teams didn’t know how to use them - or even that these processes existed. 

We needed to improve how our systems were constructed, and how our infrastructural tools were used. 

"Col sporcar si trova": Creating processes within calculated disarray 

 When transitioning to agile, the key is to shift your thinking.  Here are three critical areas that you should consciously work on changing.

There is a recurring myth in the IT industry that Agile projects do not require documentation, that giving stakeholders the opportunity to respond to fully functional software replaces that need altogether.  This perception (or, more accurately, this misperception) often stems from a misunderstanding of the following statement in the Agile Manifesto (https://agilemanifesto.org):

" We have come to value…. Working software over comprehensive documentation"

The creators of the Agile Manifesto have clarified this statement numerous times, emphasizing the following qualifying condition at the end:

"That is, while there is value in the items on the right, we value the items on the left more."

Agile has become an industry buzzword, a marketing term that organizations use to try to show that they are responsive to their clients and adaptive to industry changes.  In fact, the perception of being an Agile organization has such strong market value that claiming to be Agile often becomes the objective unto itself.  If the goal of your organization is to say that you are Agile, then you may be missing the point.  

Trying to be an Agile organization is like trying to be a happy person.  You do not achieve Agility (or happiness) by making it your primary objective; you achieve it by making constructive changes and taking positive actions that get you there.