The Gilb’s have started a series of posts against Agile. The first on is Wrong Focus.

“It is not about working software. It is not about your preferred working process. It is not about user stories. It is not only about your customer or user. It is all about delivering, to your set of Stakeholders, value improvements to them, to what they care about, what makes their world better, within agreeable, minimum or pre-determined costs. If that is not the main focus, if that is not clear to everyone on the team, you will eventually loose! If your methods are not focusing on delivering that value, as todays most popular Agile methods are not, they will fail to deliver, they will become last years fad.”

They claim Agile software development is flawed because it focuses on improving the process and environment of the team developing software. These improvements result in improved customer collaboration that ensures the team better understands what the customer wants. From my experience, the combination of improved environment, appropriately sized process, and customer collaboration results in mature agile teams doing a great job of delivering the projects and products. But I understand their point. There is a difference between understanding the customer and focusing on delivering customer value.

Wrong Focus

Whether the software development organization is building software for external clients or to enable the organization’s business processes, there are always more things that can validly be improved than there are resources to do the work. Not all of the improvements will result in the same return of business value to the overall organization. Some benefits are more valuable to the organization than others. If you don’t pick the one that is most valuable to the business it is not the right investment for the business. In any of these improvements, there is more improving that is valid than is necessary to achieve the benefit. If the team works on improvements that aren’t the focus of the effort, “while they are there”,  they are not focusing on business value. This delays delivery of the effort and is not the right investment for the business.

Nothing in the Agile Manifesto, nor most of the Agile methods, give the tools to pick the right improvements to focus on. They also create an environment where it is extremely likely to work on more then is the minimum necessary to achieve the targeted business benefit. In many organizations, close customer collaboration can lead to “gold-plating” of features. If you offer the customer whatever they want – they will ask for it.

Wrong Focus in Practice

I have a customer right now that is going to build some software to support their field employees. The business goal is to achieve a significant cost reduction in the field through improving quality and efficiency in the field. The developers are extremely interested in developing mobile applications, distributed collaboration, GPS interfaces, image capture and markup, mapping, barcode, and training training. They have started a new business to build this product with the hope of selling it outside the business in the future. The challenge here is how do they clearly identify those improvements in the field and in dispatching that will deliver the significant reduction in field expense. If they go and and talk to the dispatchers they might find 30 things that could be done better. All of these improvements would result in an improvement in work conditions or performance. But they may not be aligned with the current business focus. The same will happen in the field.

Just because it will improve satisfaction or make someone’s job easier doesn’t mean it will help with the current business focus. How do they align absolutely the minimum amount of technology to deliver on these improvements? Especially when their interests are in this bigger, more robust solution. Especially when this limiting of features is not in line with their future business objectives. Nothing in Agile addresses how to deal with this conflict.

Where’s the Answer

I address this in Feeding the Agile Beast. This is the domain of Business Analysis. As the Gilb’s point out, most Agile methods abstract this from the team. They focus on improving their processes and collaboration. In Scrum, Business Analysis is abstracted behind the Product Owner. In XP, it is abstracted behind the Onsite Customer. I don’t agree with the implication from the Gilb’s that this abstraction is a deficiency in Agile. It is just outside the scope. I also don’t agree with Agile teams that close collaboration with the customer is sufficient to ensure business value is achieved. This is not an OR conversation. This needs to be handled as an AND conversation. This is the next thing we need to learn – how to keep an Agile team laser focused on business value AND maintain the benefits of understanding the customer that comes with Agile software development.

The BABOK® says the purpose of eliciting requirements is to identify and understand the stakeholders needs and concerns, and understand the environment in which they work. This goes beyond documenting stated or superficial desires, it involves ensuring that the stakeholders actual underlying needs are understood. This is all great, but it is not useful if the requirements are elicited and documented in a way that a shared understanding is generated. Just getting the requirements documented and signed off on doesn’t help create the solution.

Failure to Establish a Shared Understanding

The myriad of stakeholders involved in an effort all have different perspectives. Their language, context, and intent are based on their particular experience. When my wife asks me to take out the trash she really means, “Talk out the trash right now, from every room in the house, replace the bags, and pick up any dirty laundry you find in the rooms you are in”. I didn’t share this understanding when we first got married. I do now – but it was more expensive than it would have been to take the time to get clarity on her context and intent. When requirements are elicited without establishing a basis of shared understanding of language, context, and intent there is the high likelihood that the requirements will be misinterpreted. This is particularly true when requirements are passed from stakeholder to business analyst to developer to quality assurance. This lack of common understanding and context often obscures the rationale for the requirement. When people don’t understand what they are doing and why they are doing it the potential for missing the mark is very high.

Establish a common language that communicates context and intent. This takes some time up front – but it is less expensive than the rework and delay associated with misunderstanding. Focus on context and intent more than detailed documentation. Verify the understanding of requirements between various stakeholders – not just a single sign-off. Clarify why each requirement is important in business language everyone agrees upon and can understand. Taking a minute to get clarity from my wife on intent would have resulted in a faster time to the desired outcome.

The problem with many current methods of Elicit Requirements on software development projects is that they don’t add economic value to the solution effort. Many projects develop unrealistically detailed requirements in large batches up front. Due to the impossibility of accurately defining exactly what the effort requires they aren’t completely useful. In addition to resulting in churn and rework they require a high level of effort to maintain. In response to problems with Big Up-front Elicitation efforts some projects have resorted to “too little” requirement definition up front. This also results in expensive churn and a lack of project focus that delays the time to value. In both cases the transaction costs associated with producing and maintaining the documents offset any value they might bring.

The How Trap

The How Trap is a very human condition. If you see someone at the fax machine and ask them what they are doing, they will say “Sending a Fax”. That isn’t what they are doing though. That is “how” they are doing something – not what they are doing. The How Trap is very common. Ric Merrifield, in his book Re-Th!nk: A Business Manifesto for Cost Cutting and Innovation talks about Dick Fosbury and the Fosbury Flop. Dick Fosbury realized the How of the high jump was to go as high as possible and abandoned trying to perfect any of the existing techniques that involved jumping over the bar so you could land on your feet. His focus on the What of jumping as high as possible led him to jump over it backwards and land on his back. His gold medal in the 1968 Summer Olympics pointed out the wisdom of his approach. When requirements are elicited on a How-Trap basis assumptions are made that limit options that should be considered to accomplish the goal of the effort.

To avoid the how trap elicit requirements based on outcomes and purposes. Avoid getting trapped in How specific language. You can be pretty specific about the purpose or outcome without falling into non-productive detail. For example, the outcomes and purposes associated with Pay Employees doesn’t change much regardless of the implementation. People need to be paid a specific amount, there are specific tax requirements, and there are clear governance and compliance needs. These don’t change whether Pay Employees is outsourced, done manually, or automated internally.

Remember Fosbury’s goal was not to jump higher it was to clear the bar at its highest point. Sending a fax is never the requirement. It is something like Communicate Status or Confirm Order. This is a subtle distinction but frees up the team to apply their creativity to the How and will lead to significantly different outcomes.

This is the final post in my review of the impact of Agile on the tasks within the knowledge areas of the BABOK®.  There are some interesting findings from this exercise. The implications are that while some business analysis tasks are performed within the development team, the business analyst role itself is more strategic and challenging on agile projects. A clear understanding of the BABOK tasks and how they should be addressed on Agile projects will dramatically increase your ability to deliver value through Agile projects.

So, What’s New?

First off, the business analysis tasks are not just aimed at documenting requirements. There are three primary targets of analysis activities. Many tasks address the features of the product. These are aimed ensuring requirements are elicited, communicated, and the solution is verified. There are business analysis tasks aimed at understanding organizational readiness and transition requirements. Finally, there are business analysis tasks aimed at understanding and improving the ability of the organization to develop and deliver the solution.

Secondly, all the tasks are still necessary. However, unlike a traditional project, where many of the analysis tasks are performed up front, they are performed continuously throughout the project. The requirements for the solution, the ability to deliver, and the readiness of the organization are evaluated incrementally throughout the project and the approach is adapted to improve fit and performance.

Finally, the understanding of requirements, organizational readiness, and development capabilities is progressively elaborated throughout the project.  In Agile, the development team itself performs detailed business analysis activities within the development iterations. The business analyst continues to operate in front of and after the development efforts. Lightweight requirements documentation combined with an emerging understanding means the business analyst become an advocate for the product. They collaborate with the team to ensure a shared understanding unfolds. The business analyst also facilitates the understanding and implementation of improvements in the business analysis and organizational readiness processes.

Summary of Business Analysis Knowledge Areas

Business Analysis Planning and Monitoring.  The tasks in this knowledge area are still primarily performed on the front end. The team will agree on the approach it will take in business analysis tasks. This means agreeing on who and how. All the task purposes in the BABOK still need to be planned – but planned to support the cadence of the team and the emergence of understanding through the project. The way the business analysis tasks are performed are not cast in stone, they will be updated through inspection and adaptation throughout the life of the project.

Elicitation. This knowledge area occurs continuously in a progressive fashion and responsibility for the product requirements changes hands during each iteration.  These hand-offs associated with the various levels of elicitation can contribute to lost knowledge and increased transaction costs.  An approach that ensures continuity of understanding is critical.

Requirements Management and Communication. The existence of Requirements Management and Communication in a single Knowledge Area demonstrates the closely held traditional belief that documenting and tracking something is the best way to communicate it. It is important that the method of documenting requirements at the higher level is lightweight while still facilitating understanding, focus and priority. In Agile projects, communication should be viewed as completely distinct tasks. At the detailed levels, there is a transfer of context, purposes, and outcomes requirements that is best performed through conversation between the customer and the development team.

Enterprise Analysis. The business analyst will still carry primary responsibility for understanding organizational readiness, transition requirements, and solution verification.  They will need to communicate findings from releases back into transition requirements to improve release performance. Gaps in the fit of the solution will feed back into the requirements backlog. Enterprise Analysis is very strategic, outside the scope of the typical Agile development team, and critical to the successful realization of business value.

Solution Assessment and Validation. These tasks happen continuously in a progressive fashion. The Big Solution Architecture will still be developed with input from the Business Analyst as well as Architects. The Business Analyst will need to understand and address the impact that progressive elaboration has on the transition requirements.

Requirements Analysis. Prioritization and organization of requirements happens as part of backlog prioritization. The business analyst should make sure that business value concerns and risks associated with assumptions and constraints are clearly understood here. Like Enterprise Analysis these tasks are very strategic, often outside the scope of the typical Agile development team (presumed to be understood by the Product Owner), and are critical to the team’s ability to burn down risk early and get to business value fast.

Missing Tasks

I believe there are at least three areas regarding business analysis on Agile projects that are not addressed by the BABOK.

Enrolling Stakeholders involves making sure everyone understands how they will participate. Just documenting a process or developing some templates don’t ensure appropriate engagement.  Stakeholders may play a role making sure shared understanding of the product requirements exists, they may be responsible for development process feedback, or they may need to participate in the transition of the solution.

Understanding Requirements is the new task or set of tasks that deal with generating the shared understanding of context, purpose, and outcome that is necessary for successful projects. Since the understanding of what is being developed and how it is being developed will emerge over the course of the project specific tasks must be in place to establish this shared understanding.  This may sound like a subtle extension of communicate requirements but this is social in nature and is fundamentally different than the push of communicating requirements.

Organizational Learning extends Enterprise Analysis. Not only does the readiness of the organization to use the product need to be reviewed, the ability to develop, deliver, and support the product needs to be evaluated. This task includes the introspection, retrospectives, operations reviews, and outside review of best practices that the organization performs to improve its ability to use and deliver solutions.

Agile Business Analysis Summary

The common concept that Business Analyst’s add no value to Agile projects is flawed. It is true that some of the detailed business analysis activities will be best served through direct interaction between developer’s and the customer. The high level planning and coordination around these direct interactions should not be abandoned but should be managed to facilitate focus on business value and shared understanding while minimizing transaction costs.

Additionally, there are many critical business analysis tasks outside the scope of the development team. Particularly, the tasks involving Solution Validation, Enterprise Analysis, and the inputs to Requirements Analysis are very strategic, outside the scope of the typical Agile development team, and critical to the successful realization of business value. A clear understanding of the tasks and purposes in the BABOK® demonstrates the strategic nature of Business Analysis tasks, highlights where the tasks should be performed within the Agile development team, and will increase the ability of the development team to achieve its objective of rapid delivery customer value.

Today I am discussing the tasks from the BABOK® associated with Requirements Analysis. These are the tasks to organize, prioritize, and model requirements and risks. There are six tasks associated with Requirements Analysis. I show the BABOK purpose. Then I discuss the impact on who and how in projects leveraging progressive elaboration, incremental delivery, close customer engagement, ongoing learning, and self organization.

Prioritize Requirements

Organize Requirements

Specify and Model Requirements

Define Assumptions and Constraints

Verify Requirements

Validate Requirements

Agile Requirements Analysis
All of the tasks in Requirements Analysis are important on Agile projects. The primary distinction in this Knowledge area is the support for the emergence of the solution over time. Particularly interesting is Define Assumptions and Constraints. While many Agile teams focus on the impediments to delivering code, they fail to manage the bigger risks and constraints associated with getting to business value.

Today I am discussing the tasks from the BABOK associated with Requirements Management and Communication. These are the tasks Ensure knowledge gained through business analysis activities throughout the effort is shared among the team. There are six tasks associated with Requirements Management and Communication. I show the BABOK® purpose. Then I discuss the impact on who and how in projects leveraging progressive elaboration, incremental delivery, close customer engagement, ongoing learning, and self organization.

Requirements Management and Communication: BABOK® Tasks

Prioritize Requirements

Organize Requirements

Specify and Model Requirements

Define Assumptions and Constraints

Verify Requirements

Validate Requirements

Agile Requirements Management and Communication

All of the tasks in Solution Verification and Validation are important on Agile projects. The primary distinctions in this Knowledge area are the support for the emergence of the solution over time. Particularly interesting are Assess Organizational Readiness and Transition Requirements as these are often overlooked in Agile projects (many software development projects). Remember, the product isn’t done-done until the customer is using it and achieving the benefits expected by the product owner.

Today I am discussing the tasks from the BABOK associated with Solution Verification and Validation. These are the tasks to determine which solution best fits the business need – although it includes assessing the performance and effectiveness of the solution. There are six tasks associated with Solution Verification and Validation. I show the BABOK® purpose. Then I discuss the impact on who and how in projects leveraging progressive elaboration, incremental delivery, close customer engagement, ongoing learning, and self organization.

Assess Proposed Solution

Allocate Requirements

Assess Organizational Readiness

Define Transition Requirements

Validate Solution

Evaluate Solution Performance

Solution Verification and Validation

All of the tasks in Solution Verification and Validation are important on Agile projects. The primary distinctions in this Knowledge area are the support for the emergence of the solution over time. Particularly interesting are Assess Organizational Readiness and Transition Requirements as these are often overlooked in Agile projects (many software development projects). Remember, the product isn’t done-done until the customer is using it and achieving the benefits expected by the product owner.

Today I am discussing the tasks from the BABOK associated with Enterprise Analysis. These are the tasks to understand what the enterprise is capable of performing. There are five tasks associated with Enterprise Analysis. Again, I show the BABOK® purpose. Then I discuss the impact on who and how in projects leveraging progressive elaboration, incremental delivery, close customer engagement, ongoing learning, and self organization

Task: Define Business Need

Task: Assess Capability Gaps

Task: Determine Solution Approach

Task: Define Solution Scope

Task: Define Business Case

Enterprise Analysis Agile Summary
All of the tasks in Enterprise Analysis are important on Agile projects. The primary distinctions in this Knowledge area are contributing to the continuous improvements of the organizations ability to deliver as well as the emergence of the business need through the project.

Today I am discussing the tasks from the BABOK associated with Eliciation. These are the tasks to Understand the underlying needs rather than stated or superficial desires. There are four tasks associated with Elicitation. Again, I show the BABOK® purpose. Then I discuss the impact on who and how in projects leveraging progressive elaboration, incremental delivery, close customer engagement, ongoing learning, and self organization.

Task: Prepare for Elicitation

Task: Conduct Elicitation Activity

Task: Document Elicitation Results

Task: Confirm Elicitation Results

Elicitation Agile Summary
All of the tasks in Elicitation are important on Agile projects. Again, the primary distinctions in this Knowledge area are planning for  continuous engagement with  the customer and the progressive elaboration of requirements. In the event that the enterprise has governance requirements or there are contractual obligation, the team will have to negotiate how they will deliver documentation that is sufficient to support the needs of the business.

Today I am discussing the tasks from the BABOK associated with Business Analysis and Planning. These are the tasks to determine which business analysis activities are necessary to support an effort. There are six tasks associated with Business Analysis and Planning. I show the BABOK® purpose. Then I discuss the impact on who and how in projects leveraging progressive elaboration, incremental delivery, close customer engagement, ongoing learning, and self organization.

Plan Business Analysis Approach

Conduct Stakeholder Analysis

Plan Business Analysis Activities

Plan Business Analysis Communication

Plan Requirements Management Process

Manage Business Analysis Performance

Business Analysis Planning and Monitoring Summary

All of the tasks in Business Analysis Planning and Monitoring are important on Agile projects. They won’t be dictated from existing policy, they will be decided on as a team. The activities will support the Agile approach. The primary distinctions in this Knowledge area are planning for  continuous engagement with  the customer and the progressive elaboration of requirements. In an enterprise that has governance requirements, the team will have to negotiate how they will deliver communications to the governance team that is sufficient to support the needs of the business.