Agile Business Analysis (ABA)

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

Agile Processes and How They Work in Content Marketing

Content marketing is all about producing quality content and making it reach your target audience. It’s a sort of strategically planned content development which is supposed to lead to profitable actions by the customers. The traditional “heads-down” content production is how things were done before Agile. Now, Agile is bringing in some serious changes.

When we’re talking about Agile marketing, we’re talking about innovation. It represents a non-traditional approach to work organization and structure, which makes room for positive changes and better workflow. In order for you to understand how going Agile works in content marketing, we’ve prepared useful facts and explanations. Let’s take a look. 

The Development of Agile 

Maximizing the Value of Your Product Backlog (Part Two)

Valuating and prioritizing your features

The Product Backlog is the heart of defining any Agile solution.  The requirements that are identified in the Product Backlog drive the priorities that the Agile development team works on, they establish the scope of the delivered solution, and they ultimately determine the business value that the organization will receive from their Agile investment.  This is the second of two articles that provide you with techniques for maximizing the value of the features in your Product Backlog.  The first article, Maximizing the Value of Your Product Backlog (Part One):  Gathering the full scope of req

Maximizing the Value of Your Product Backlog (Part One): Gathering the full scope of requirements

The Product Backlog is the heart of defining any Agile solution.  The requirements that are identified in the Product Backlog drive the priorities that the Agile development team works on, they establish the scope of the delivered solution, and they ultimately determine the business value that the organization will receive from their Agile investment.  The challenge is that most Product Backlogs are based on input from selected stakeholders, rarely representing the full scope of requirements - and constraints - that need to be considered before priorities and business value can be accurately identified.

This is the first of two articles that provide you with techniques for maximizing the value of the requirements in your Product Backlog.  This article focuses on ensuring that you have considered the full scope of potential sources for identifying what the solution needs to deliver - and equally what it should notbe delivering.

Don’t Over Plan! Let the Plan Evolve for an Agile Approach

We all know how to plan.  From waterfall, we know how to over plan.  But how much planning is necessary if you are using an agile approach?  Here’s an idea…try starting the first piece of a project before you have the full plan.  Radical thought?  Did your heart skip a beat?  Here’s why this experiment might change your attitude about planning.

 

How to Be Agile in a Non Agile Organization (Part 2): Aligning Agile projects to corporate reporting structures

This is the second in a series of articles that will give you strategies for aligning your Agile work to your organizational structures.  The first article focused on delivering Agile projects within existing Project, Process and Quality Management frameworks. In this article, the focus is on delivering Agile projects within the existing corporate reporting structures of your organization.

Agile approaches provide a number of mechanisms for tracking progress, including formal reports (e.g. executive dashboards), status update tools (e.g. WIP boards and product backlogs), and ongoing communication with stakeholders.

The ideal Agile reporting environment would leverage these tools without asking staff to do extra (often redundant) work to meet corporate reporting requirements. Specifically, this would involve using:

 

7 Agile Concepts You Can Apply Successfully to IT Areas Other Than Software Development

Agile is an iterative form of software development. Through its rituals and ceremonies, it provides a quicker way to deliver value to the actual customer of the software. Through its focus on prioritization, agile insists that the work most important to the customer be completed first. Through its dedication to team empowerment, agile pushes the “how” to the team level where the team takes ownership of delivery and quality. As agile has proven its value in the software engineering field, it also has many concepts that can prove beneficial to other IT areas. Listed below are some of those concepts and examples of how they might be implemented.

Syndicate content

Shopping cart

View your shopping cart.

Business Process Management Jobs