Agile Business Analysis (ABA)

90-Days to Go-Live Approach

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?

The Product Backlog: A Step-by-Step Guide

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.

Introducing Agile BPM

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. 

Agile BPM: How to apply Agile Concepts to Business Process Management and Business Analysis

Join Gregg Rock and our lead Agile instructor, Joanne Carswell, as they introduce a new methodology – Agile BPM.

This webcast discusses five agile concepts that can be directly applied to process improvement and management as well as to business analysis initiatives. We’ll discuss how to adapt these agile concepts to provide value more frequently to the process users. You will leave this session with tangible action items as well as a better understanding of agile. A more in-depth view of this concept - infusing BPM with agile - may be found in the new curriculum offered by BPMInstitute.org.We will also provide a brief overview of each of the courses in our Agile BPM Certificate Program:

Agile Methodology for BPM: Discusses how to apply agile concepts, principles, and standards for members of Business Process Management including analysts, project managers, and leaders. Providing value more frequently in BPM is emphasized.

Webcast Date: 
Thu, 02/04/2021 - 12:00

Using Hackathons to Create Process-Centric Teams

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 

Distance Learning for Professional Development

The Distance Learning Leader

BPMInstitute.org has been delivering online training for more than 15 years for individuals and groups. We can even provide training to groups across multiple time zones and around the world.

We've put together this short webcast to help you understand all of your options for online training.

View the webcast now >


Download the pdf (but you miss out on the audio)

(Keep an eye out for a special discount on the last slide.)

Webcast Date: 
Tue, 03/24/2020 - 13:00

3 Key Mindset Shifts to Make Your Agile Transition Successful

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

What is Good Enough Agile Documentation?:The minimum requirements for every Agile project

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."

Stop Trying to Be Agile: Agile is a process, not a goal

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.

Comparing Agile with Cross-Functional Project Teams

For some time now, since a conference I ran in July on Agile and New Forms of Organization, I have been trying to get clear in my mind what the difference is between an “agile team” and a “cross-functional team”. Also, I recently participated in a cross-functional team looking at ways to improve the performance of corporate functions.

Cross-functional teams have been a feature of organisation since the 1960s, when Boeing first developed a new aeroplane using a multi-functional approach.  This successful experience was documented by Jay Galbraith, who called it a “matrix structure”.  It was the first documented use of matrix organisation ideas: in Boeing’s case a function/project matrix.  At various points in time since then, cross-functional teams have been much written about and much used.

So what is new/different about Agile compared to cross-functional teams?  Here is my list

Syndicate content

Shopping cart

View your shopping cart.
Remind me later

What are your professional development goals for 2022?

Take our Professional Development Survey
Take the survey now for an opportunity to win an online course worth up to $795!

The survey is just five questions long and only takes a few minutes.