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.

Agile methods are helping teams deliver software faster and with much higher quality than ever before. In response, Agile has emerged as a driving force in software development. Businesses want to achieve the benefits of improved quality and rapid delivery.   But getting faster at development is just part of the equation.  As I discussed in my presentation “Feeding The Agile Beast”, you have to identify, prioritize, and scope what you are going to build so that risk is managed and ROI is maximized.

So, What’s New?

Agile methods have emerged from a few simple concepts. Change happens and people trump process (Thanks to Ken Schwaber via Steve Adolph). In response to this, substantially all of the Agile methods describe a way of delivering software that support the following attributes:

• Progressive elaboration a little ahead of demand (for planning,  requirements,  architecture, testing,  etc)
• Incremental and iterative delivery (though not time-boxed in Kanban/Lean continuous flow)
• Ongoing learning through close customer engagement regarding product fit/business value that informs requirements and prioritization
• Ongoing learning regarding development/delivery approach and interactions that informs ongoing improvement efforts
• Self organization around the work (where the people performing the work decides how best to do their jobs within organizationally appropriate constraints)

In traditional software development, this identification and prioritization of what you are going to build falls in the role of the Business Analyst. However, traditional business analysis methods do not operate in harmony with the iterative and incremental cadence of Agile methods. For the most part, this is different than traditional plan driven projects.  Over the next week or so, I am going through the capabilities associated with Business Analysis and discuss the how Agile impacts how business analysis is performed.

The Guide to the Business Analysis Body Of Knowledge

I am going to build this discussion on work from The Business Analysis Body of Knowledge® (BABOK®) from the International Institute of Business Analysis. The IIBA® is the independent non-profit professional association serving the growing field of Business Analysis.  The IIBA has collected the current generally accepted practices within Business Analysis in The Business Analysis Body of Knowledge® (BABOK®).The BABOK® Guide describes Business Analysis areas of knowledge, their associated activities and the tasks and skills necessary to be effective in their execution.

The BABOK has six Knowledge Areas.

• Business Analysis Planning and Monitoring: Determine which business analysis activities are necessary to support an effort.
• Elicitation: Understand the underlying needs rather than stated or superficial desires.
• Enterprise Analysis: Understand what the enterprise is capable of performing.
• Solution Verification and Validation: Determine which solution best fits the business need – includes assessing the performance and effectiveness of the solution.
• Requirements Analysis: Organize, prioritize, and model requirements and risks.
• Requirements Management and Communication: Ensure knowledge gained through business analysis activities throughout the effort is shared among the team.

Within each Knowledge Area are several tasks. I will focus on how progressive elaboration, incremental delivery, close customer engagement, ongoing learning, and self organization impact who performs business analysis tasks and how business analysis tasks are performed.

Agile Business Analysis

Just to set my context. All of the Capabilities that are reflected in the BABOK happen on all projects – traditional or Agile. They may or may not be done by a specific role. They may or may not happen in a specific phase. They may or may not be done with any ceremony or intention. They do occur. Since the identification, prioritization, and scoping of requirements is so important to success, they need to be done well. And on an Agile project they need to be done so they enable – not constrain or impede – the delivery of value in projects leveraging progressive elaboration, incremental delivery, close customer engagement, ongoing learning, and self organization.

This post is going to go back over the past month’s posts and bring them together into a model I can use to discuss Big Agile. I took me a while to noodle this out so I haven’t posted in over a week. This approach is based on over two decades of improving performance in development organizations. The last decade has been spent working to explicitly articulate what I’ve done to consistently deliver results. It is amazing how much you learn when you take concepts practiced unconsciously and write them in a (relatively) concise format.

Enterprise Agility

Many companies are dependent on technology to be competitive. Either because they deliver technology as their product or because technology enables the processes they depend on. For those companies it is important to be able to operate faster than their competition.  This requires not only the ability to rapidly deliver technology – but the ability to adapt their organization.  This is the concept of operating within your competitors decision cycle. The model I use to demonstrate this concept is John Boyd’s O-O-D-A model.

This is Enterprise Agility, when the enterprise has learned to leverage technology and change management to develop an energized workforce frequently delivering value that meets the emerging needs of the customer.

Three Concepts for Achieving the Agile Enterprise

I am going to build on three concepts in showing how to build Enterprise Agility.

1. Theory of Constraints. You can’t get there all at once. It is necessary to decide where to focus. You have to develop the underlying capabilities from the bottom up. If you can’t produce quality product, the best ideas in the world will run into problems. The way of thinking about problems covered in the management system the Theory of Constraints provides the method for deciding where to focus. Identify the current constraint, get the most out of the capability that is the constraint, subordinate the system to the constraint, elevate the constraint, and then continue to pursue this cycle. This “Process of On-Going Improvement” is applied to the flow of value to the customer.

2. Creative Solution Finding. Once we understand where to change we need to understand what to change to. We have to apply a method to lead the overall adoption effort that supports aligning the capabilities with the overall goals of the organization. The stages of Creative Solution Finding are useful for identifying the situation specific approach to developing this road-map. There is no magic sauce for developing this road-map. By applying the seven principles, along with a knowledge of applicable best practices, a useful road-map that fits both the process and social context of the Enterprise can be developed.

3. The Learning Organization. Technology development efforts are knowledge based efforts. As such, they are performed through a social construct. To improve the performance of software development we have to not only improve the methods of development, we have to improve the performance of the social construct. First the individuals on the team must be willing to change. While the People Design principle in Creative Solution Finding will help prepare individuals for change, their personal fears and concerns must also be addressed. Once the constraint is identified and a road-map for improvement is developed, the learning organization concepts in the Fifth Discipline are relevant. The right individual competencies must be developed on the team to do the job (Personal Mastery and Mental Models).  The team has to be functioning well together (Shared Vision and Team Learning).  And the Team has to be functioning in a way that is aligned with the goal of the overall system (Systems Thinking).  The primary tool used to influence a social construct to create change and to improve performance is the conversation.

Discussing Big Agile

So the approach is to take the Big Agile capabilities, (1) provide insight to identify when a specific set of capabilities at a level of scaling are the current constraint, (2) leverage the solution finding model and best practices to define/refine the roadmap to move toward,  (3) and then identify the competencies to develop and conversations that are necessary to execute the change.  Then continue the cycle continuously.

This is the Big Agile improvement approach. It takes a model that I have been applying for two decades implicitly and evolving explicitly for the last decade. Clear direction combined with appropriate best practices and an effective adoption approach. All that’s left now is to build out the details of the capabilities, when they are a constraint, how to select appropriate best practices, and the conversations and change approach at each level of scaling for the model.

You’ve heard people say, “That’s great, but does it scale?” , we think we all agree on what that means. But, as with many words we use in this space, the word scale is potentially overloaded – everyone has a different idea of what the term means. This led to some interesting comments on my post Monday, What Does Scaling Agile to the Enterprise Mean?. Even though I explained the five orders of scaling, and that the practices were different at each order of scale, there is confusion about what I mean by scaling and what we are scaling.

I have gone to dictionary.com to gain clarity on what it means to scale.  I pulled eight definitions to determine which one we intend.

Scale (skeyl)

1. one of the thin, flat, horny plates forming the covering of certain animals, as snakes, lizards, and pangolins
2. a balance or any of various other instruments or devices for weighing
3. a succession or progression of steps or degrees; graduated series:
4. a succession of tones ascending or descending according to fixed intervals
5. the proportion that a representation of an object bears to the object itself
6. Australian Informal. to ride on (public transportation) without paying the fare
7. Dentristy scal•ing. The removal of calculus and other deposits on the teeth by means of instruments
8. a certain relative or proportionate size or extent

We don’t mean what comes off fish, what we weigh things with, a way of measuring temperature, a musical construct, making a model of something, riding without paying the fare, or cleaning teeth.

So we must mean taking Agile to a proportionate size. That’s to point of the different orders of scaling. That Agile will be expressed differently at each order. But what are we actually taking to a proportionate size? Do we want to have an Enterprise wide stand-up with thousands of people? Do we want to have every job done by two people? What are we scaling?

Small team agile, as guided by the Agile Manifesto for Software Development, is a set of values and principles. Agile, as practiced in many development teams, is a set of management, leadership, and engineering practices resulting in an energized workforce frequently delivering software that meets the emerging needs of the customer. For other definitions of Agile, I went back to dictionary.com.

Agile (aj-ahyl)

1. quick and well-coordinated in movement
2. marked by an ability to think quickly

Well, we aren’t hoping that every person in the Enterprise learns to write code. It isn’t the specific practices that we want to see scale. It is quick and well coordinated movement we see in small team agile. It is the ability to think quickly and respond to emerging customer needs.

What do we mean by scaling agile to the enterprise? We are scaling the benefits of agile – the benefits of an energized workforce frequently delivering value that meets the emerging needs of the customer. We want to take this up from small development teams  so that the entire organization can be more adaptive and responsive.

It turns out that the capabilities (not the specific practices) that make the benefits of small team agile possible can be expressed at each order of scaling. And when layered together, the benefits of agile can be scaled to the enterprise level. Over the next few weeks, I am going to go through the management, leadership, and engineering capabilities of small team agile and discuss how the capabilities scale to deliver benefits at the different orders of scaling.