Posts Tagged ‘Business Analysis’

Agile Requirements Analysis

Posted on October 20th, 2009 by Dennis Stevens  |  No Comments »

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

Purpose Agile Impact
Prioritization of requirements ensures that analysis and implementation efforts focus on the most critical requirements. In Agile, requirements are progressively elaborated. Throughout the Elicitation Task, Elicitation results are progressively broken down and elaborated. At each point of elaboration the constituent parts need to be evaluated and prioritized based on business value contribution and risk burn-down.  In Agile, this is not a one-time up front activity. This happens throughout the life of the project on all remaining work and new work brought in from learning about the product.

Organize Requirements

Purpose Agile Impact
The purpose of organizing requirements is to create a set of views of the requirements for the new business solution that are comprehensive, complete, consistent, and understood from all stakeholder perspectives. In Agile, it is important to organize requirements to minimize dependencies between feature sets. This reduces complexity and risk and improves testability at the business value level. Since requirements are progressively elaborated, this can be shown as the Solution Architecture from a business standpoint. Expect this Solution Architecture to evolve based on feedback from the customer once they start to experience the product. Requirements should be organized around business value – and not technical implementations. Only within component teams – where the business value arises from delivering enabling technology – is it appropriate to depict technical requirements. Even then, these requirements need to be prioritized and filtered based on risk burn down and business value contribution.

Specify and Model Requirements

Purpose Agile Impact
To analyze expressed stakeholder desires and/or the current state of the organization using a combination of textual statements, matrices, diagrams and formal models. At different levels of elaboration there are different methods for specifying and modeling requirements. The approach should support progressive elaboration, is adaptable to change based on learning, and doesn’t box in the team to solutions too early.  It should also ensure that intent and intended business value is communicated consistently through the elaboration.  Agile teams tend to use Stories and Tasks at the lowest level of decomposition. These Stories and Tasks can be supported by detailed documentation and use cases. It is becoming increasingly common for acceptance tests to be produced as part of specifying and modeling the requirements.

Define Assumptions and Constraints

Purpose Agile Impact
Identify factors other than requirements that may affect which solutions are viable. On Agile projects this is handled through a risk management approach that treats risks as stories within themes. Risk mitigation activities are prioritized along with stories and burned down and re prioritized as they stories are performed. This is typically produced by the business analyst and project manager along with the team, prioritized by the product owner, and performed by the team.

Verify Requirements

Purpose Agile Impact
Requirements verification ensures that requirements specifications and models meet the necessary standard of quality to allow them to be used effectively to guide further work. Requirements are verified by the team during the project. Through retrospectives and operations reviews the team may decide to modify the level of detail to or the method of specifying and modeling requirements to improve the performance of the team.

Validate Requirements

Purpose Agile Impact
The purpose of requirements validation is to ensure that all requirements support the delivery of value to the business, fulfill its goals and objectives, and meet a stakeholder need. Requirements are verified throughout the development and delivery of the solution through continual involvement of the product owner and customer. This happens at release planning, iteration planning, during development, and at customer acceptance.

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.

Requirements Management and Communication

Posted on October 19th, 2009 by Dennis Stevens  |  No Comments »

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

Purpose Agile Impact
Prioritization of requirements ensures that analysis and implementation efforts focus on the most critical requirements. In Agile, requirements are progressively elaborated. Throughout the Elicitation Task, Elicitation results are progressively broken down and elaborated. At each point of elaboration the constituent parts need to be evaluated and prioritized based on business value contribution and risk burn-down.  In Agile, this is not a one-time up front activity. This happens throughout the life of the project on all remaining work and new work brought in from learning about the product.


Organize Requirements

Purpose Agile Impact
The purpose of organizing requirements is to create a set of views of the requirements for the new business solution that are comprehensive, complete, consistent, and understood from all stakeholder perspectives. In Agile, it is important to organize requirements to minimize dependencies between feature sets. This reduces complexity and risk and improves testability at the business level value. Since requirements are progressively elaborated, this big block architecture results in the Solution Architecture from a business standpoint. Requirements should be organized around business value – and not technical implementations. Only within component teams – where the business value arises from delivering enabling technology – is it appropriate to depict technical requirements. Even then, these requirements need to be prioritized and filtered based on risk burn down and business value contribution. Story Maps within Epics are a method of implementing Organize Requirements.


Specify and Model Requirements

Purpose Agile Impact
To analyze expressed stakeholder desires and/or the current state of the organization using a combination of textual statements, matrices, diagrams and formal models. At different levels of elaboration there are different methods for specifying and modeling requirements. The approach should support progressive elaboration, is adaptable to change based on learning, and doesn’t box in the team to solutions too early.  It should also ensure that intent and intended business value is communicated consistently through the elaboration.  Agile teams tend to use Stories and Tasks at the lowest level of decomposition. These Stories and Tasks can be supported by detailed documentation and use cases. It is becoming increasingly common for acceptance tests to be produced as part of specifying and modeling the requirements.


Define Assumptions and Constraints

Purpose Agile Impact
Identify factors other than requirements that may affect which solutions are viable. On Agile projects this is handled through a risk management approach that treats risks as stories within themes. Risk mitigation activities are prioritized along with stories and burned down and re prioritized as they stories are performed. This is typically produced by the business analyst and project manager along with the team, prioritized by the product owner, and performed by the team.


Verify Requirements

Purpose Agile Impact
Requirements verification ensures that requirements specifications and models meet the necessary standard of quality to allow them to be used effectively to guide further work. Requirements are verified by the team during the project. Through retrospectives and operations reviews the team may decide to modify the level of detail to or the method of specifying and modeling requirements to improve the performance of the team.


Validate Requirements

Purpose Agile Impact
The purpose of requirements validation is to ensure that all requirements support the delivery of value to the business, fulfill its goals and objectives, and meet a stakeholder need. Requirements are verified throughout the development and delivery of the solution through continual involvement of the product owner and customer. This happens at release planning, iteration planning, during development, and at customer acceptance.

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.

Solution Verification and Validation

Posted on October 16th, 2009 by Dennis Stevens  |  No Comments »

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

Purpose Agile Impact
To assess proposed solutions in order to determine how closely they meet stakeholder and solution requirements. One of the benefits of Agile is that while some solution decisions must be made up front the Solution can be assessed over time. Agile facilitates the concept of Real Options where design decisions can be deferred until the last responsible moment. Detailed understanding of the business need is unfolding at the same time the teams understanding of how to solve the problem is developing. With effective Agile architecture and design the cost of redoing things that have already been developed is relatively low. Assessing the proposed solution doesn’t become a check-point on the project but an ongoing assessment against the business case and current status of the project.

Allocate Requirements

Purpose Agile Impact
Allocate stakeholder and solution requirements among solution components and releases in order to maximize the possible business value given the options and alternatives generated by the design team. On Agile projects, this is done by allocating requirements into feature themes and components. Allocation shapes the design of the delivery organization itself. Feature teams form around feature themes and components needed to support cross feature theme requirements.

Assess Organizational Readiness

Purpose Agile Impact
Assess whether the organization is ready to make effective use of a new solution. The organizational readiness assessment occurs on Agile projects in much the same way as it does in traditional projects. The difference is that the release cadence can be more frequent. A significant area to define in Agile projects is how often the organization can absorb releases. Organizational readiness should include not just the end-user/customer of the release, but the supporting organization as well (i.e., support, training, sales, marketing, accounting).

Define Transition Requirements

Purpose Agile Impact
Define requirements for capabilities needed to transition from an existing solution to a new solution. The determination of transition requirements occurs in an Agile project much as it does in a traditional project. The ability to deliver value incrementally opens up new possibilities for transition. Rather than monolithic release the organizational impact can smaller but more frequent.  Since the cost of development per unit is lower, temporary integration into existing systems can be developed and make the need for running parallel systems less significant.

Validate Solution

Purpose Agile Impact
Validate that a solution meets the business need and determine the most appropriate response to identified defects. Validate solution happens as an ongoing effort in an Agile project. Within each iteration the customer is provided detailed feedback on the current requirements. At the completion of each iteration cycle, the product owner facilitates alignment with the customer need and continued alignment with the business case.

Evaluate Solution Performance

Purpose Agile Impact
Evaluate functioning solutions to understand the value they deliver and identify opportunities for improvement. Upon release, the Product Owner facilitates understanding how well the solution meets the needs of the customer and identifies new opportunities for improvement and to create additional value for the business. The incremental nature of the back log allows new, higher value items discovered during this evaluation to enter into the existing backlog ahead of existing items. This is an additional way that Agile shortens time to value.

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.

Agile Business Analysis Enterprise Analysis

Posted on October 15th, 2009 by Dennis Stevens  |  No Comments »

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

Purpose Agile Impact
The definition of the business need is frequently the most critical step in any business analysis effort. The business need defines the problem that the business analyst is trying to find a solution for. The way the business need is defined determines which alternative solutions will be considered, which stakeholders will be consulted, and which solution approaches will be evaluated. In mature Agile projects, the business need is determined up front by the Product Owner. This happens on an Agile project in a similar fashion that it happens on non-Agile projects. However, during the course of the effort, the business need is continuously reviewed and updated as appropriate.

Task: Assess Capability Gaps

Purpose Agile Impact
To identify new capabilities required by the enterprise to meet the business need. On an Agile project, this occurs not just at the start of the project – but throughout the project in retrospectives and operational reviews. This is not performed by the Business Analyst, but is performed cooperatively by the team.

Task: Determine Solution Approach

Purpose Agile Impact
To determine the most viable solution approach to meet the business need in enough detail to allow for definition of solution scope and prepare the business case. Agile development provides a faster delivery of value than traditional methods. It also supports incremental delivery so the Solution Approach can be evolved over the course of the project. This approach allows a different bargain to be struck with the business regarding determining the solution.

Task: Define Solution Scope

Purpose Agile Impact
To define which new capabilities a project or iteration will deliver. The Scope of Agile projects evolves during the course of the project as the team learns more about ways to solve the problem and the customer preferences for a solution.  The scope is defined in higher level abstractions (themes, epics, etc) and is detailed as the project evolves.

Task: Define Business Case

Purpose Agile Impact
To determine if an organization can justify the investment required to deliver a proposed solution. The business case for Agile projects are typically based on achieving a specific business outcome within a specified cost and time.  The business case is revisited frequently as the team learns what it can deliver, how well it meets the real (not perceived) needs, and whether the business outcome can be achieved within the specified cost and time.

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.

Agile Business Analysis Elicitation

Posted on October 14th, 2009 by Dennis Stevens  |  1 Comment »

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

Purpose Agile Impact
Ensure all needed resources are organized and scheduled for conducting the elicitation activities. Preparing for Elicitation changes during the life of the project. Early on, it is done by the Product Owner (Business Analyst) to coordinate supporting materials and schedule resources to define the high-level requirements. This is coordinated by the Business Analyst. As the project progress, work is coordinated by prioritization of the backlog. The customer will be pulled in to work directly with the developers on a frequent (daily) basis to elaborate requirements.  This task requires the scheduling of resources and the coordination of inputs to align with the progressive elaboration of the backlog.

Task: Conduct Elicitation Activity

Purpose Agile Impact
Meet with stakeholder(s) to elicit information regarding their needs. Early on, Conduct Elicitation is performed by the Product Owner or Business Analyst to define high-level requirements. As the project progress, the customer interacts with the development team directly during iteration planning and even during development. At each step the requirements are further decomposed to smaller units of business value. Finally, the customer interacts with the developers on a frequent (daily) basis to elaborate the requirements.

Task: Document Elicitation Results

Purpose Agile Impact
Record the information provided by stakeholders for use in analysis. The amount of documentation is a key distinction between Agile and traditional efforts. Early on, the Business Analyst will document elicitation results at a high level – with enough detail to communicate intent and value. The results will be gathered into a backlog that will be developed in more detail as the project progresses. At the end, the developer may make changes during interaction with the customer that invalidates the documentation. One of the tenants of Agile is “Working software over comprehensive documentation.” The code becomes “self-documenting.” The team must decide how to reconcile the difference between historical documentation and the working product.

Task: Confirm Elicitation Results

Purpose Agile Impact
Validate that the stated requirements expressed by the stakeholder match the stakeholder’s understanding of the problem and the stakeholder’s needs. This happens by the Team during iteration planning , during the development iteration, and at Customer Acceptance. The customer may change her mind about some specific element of a story after they have seen the result.  This feedback becomes an input into the conduct elicitation activity.

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.

Agile Business Analysis Planning and Monitoring

Posted on October 13th, 2009 by Dennis Stevens  |  No Comments »

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

BABOK Purpose

Agile Impact
Describes how to select an approach to performing business analysis, which stakeholders need to be involved in the decision, who will be consulted regarding and informed of the approach, and the rationale for using it. The Business Analysis approach is agreed upon by team at the start of the project. The approach will support progressive elaboration of requirements and feedback from the customer. It will also support evolution of the business analysis approach throughout the project via learning that occurs through retrospectives.


Conduct Stakeholder Analysis

BABOK Purpose

Agile Impact
Covers the identification of stakeholders who may be affected by a proposed initiative or who share a common business need, identifying appropriate stakeholders for the project or project phase, and determining stakeholder influence and/or authority regarding the approval of project deliverables. This will be performed by the Product Owner, Project Management, or Business Analyst. Additional understanding of the Stakeholders will be needed for Agile projects. What is the impact of the Agile cadence on the stakeholder? How does progressive elaboration impact the expectations of the stakeholder? Can the stakeholder participate in updating the processes, interactions, and products specifications during the course of the project?


Plan Business Analysis Activities

BABOK Purpose

Agile Impact
Determine the activities that must be performed and the deliverables that must be produced, estimate the effort required to perform that work, and identify the management tools required to measure the progress of those activities and deliverables. This will be performed and agreed upon by the team. The business analysis activities will be consistent with the business analysis approach. There is less of a focus on formal documentation (although it still exists at a situation appropriate level) and more focus on progressive elaboration of documentation throughout the life of the project. Also, much of the elaboration is replaced by interactions and ceremony so these outcomes need to be accomplished with activities addressed in the communication plan.


Plan Business Analysis Communication

BABOK Purpose

Agile Impact
Describes the proposed structure and schedule for communications regarding business analysis activities. Record and organize the activities to provide a basis for setting expectations for business analysis work, meetings, walkthroughs, and other communications. This will be performed and agreed upon by the team.  In Agile projects, some deliverables – or elaboration of these deliverables – are replaced by specific interactions or ceremonies. By definition, these interactions and ceremonies require real-time participation by the Business Analysis. The Business Analysis Communication activities need to address these interactions and the team needs to have a shared understanding of the purpose of these interactions and ceremonies



Plan Requirements Management Process

BABOK Purpose

Agile Impact
Define the process that will be used to approve requirements for implementation and manage changes to the solution or requirements scope. This will be defined by the team and performed by the Product Owner or Business Analyst. The term “Requirements Management” raises the hackles of Agile practioners. It implies a change is an exception rather than anticipated outcome of learning. Producing documentation that is going to change before it is used and any efforts to “Control Change” are therefore considered a wasteful effort.  A Requirements Management Process must support approval and changes in a way that facilitates delivery of value – rather than tracking for the sake of tracking.


Manage Business Analysis Performance

BABOK Purpose

Agile Impact
To manage the performance of business analysis activities to ensure that they are executed as effectively as possible This will be performed by the Product Owner or the Business Analyst’s manager. This should be measured based on performance of the project rather than adherence to process. The Business Analyst is making sure just enough of the right features are being developed. The right features are those that burn down risks early and drive deliverable business value as early as possible. The business analyst also has to find the balance between formal requirements documentation and clear communication of need. Effective Business Analysis Performance will result in limited rework of the requirements documentation, effective prioritization and scoping of requirements, and clear communication of need to the development team.


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 Business Analysis

Posted on October 12th, 2009 by Dennis Stevens  |  No Comments »

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.

What Does Scaling Agile to the Enterprise Mean, part 2?

Posted on September 23rd, 2009 by Dennis Stevens  |  No Comments »

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.

Feeding the Agile Beast

Posted on September 2nd, 2009 by Dennis Stevens  |  4 Comments »

I want to share the presentation I did in the Open Jam at Agile 2009. I got good feedback from some of the thought leaders there like David Anderson, Chris Matts, Eric Willeke, Chris Shinkle, and Mike Cottmeyer.  Ok, enough name dropping. A common theme at Agile 2009 was, “Now that we are pretty good at small teams developing software, what’s next?” One of the answers is making sure the developers are working on the stuf that provides the greatest value back to the organization. A lot teams aren’t very good at this.

If your projects are anything like most of the development projects I’ve been on you are likely to run into cost and time pressure near the end. Our story might be something like, “We can’t meet your needs for the planned cost or by your expected time-frame. We have been telling you from the beginning there was uncertainty in the requirements and that development is fraught with risk. You will just have to pony up.” Customer’s don’t like this but they have come to expect teams to be late and over budget.

If you had the foresight and tools to understand how to focus on eliminating risk on the front end and then building the highest value things first, you can go to your customer with a story like this, “Even though there is a lot of uncertainty in the requirements and exactly how we would build the software, we have a working product that meets all of your most important business needs. In fact, I bet you didn’t know that over half of all the technology built is never even used in the end. We would love to continue to build out the remaining features after we get this adopted by your customer, but we bet addressing what they think is important will be more valuable than building out elaborate and potentially unused features.”

I have used this approach on about a dozen efforts and have found that it promotes far better communication between the team, product owner, and customers. It provides clarity on what needs to be build, why it needs to be built, and how we can do acceptance testing on what is built. It is also low friction to maintain if the product or project strategy changes in flight.  It is a sustainable artifact that connects Ivory Tower discussions about business value and risk to the developers context.

Feeding The Agile Beast

Typical Business Analysis techniques have high transaction costs and high coordination cost while still not getting the key points across to development. We end up with lagging risk, too much rework, missing critical requirements, lack of testability, and over engineered products. This is very expensive – both in terms of what is spent to deliver to our customers and in terms of meeting the needs of the customers. Once we change the conversation from “What can we get done this week?” to “How can we optimize business value and manage risk responsibly?” we are on the right track to Feeding this Agile Beast.

Newer Entries »