Tag: agile requirements

Posted on by

Satisfying Stakeholders with Agile Requirements

People in stakeholder meeting about agile requirements

Traditional approaches to detailed requirements documents are being modified to accommodate faster, more lightweight communication methods. Business analysts must adjust their work styles and deliverables to fit into project development life cycles and methods.

As part of the process, it is important to understand if agile requirements differ from plan-driven requirements.  It’s also good to know if a mind shift is required to develop successful requirements.

Agile Requirements

  1. How Do Agile and Traditional Requirements Differ?
  2. Shift in Mindset for Agile Requirements
  3. Tips for Creating Successful Agile Requirements

How Do Agile and Traditional Requirements Differ?

Agile requirements are not as different as you would expect. In a traditional environment, BA’s create detailed requirements.  In an agile environment, the documentation becomes a lot less important.  Most of the tools and analysis techniques that BAs have in their tool kit are still valuable and applicable in agile.  In fact, having an assortment of different tools to analyze is powerful.

As analysts, it is important to be aware of how a product or service will be used. You must also know the environment the product is expected to function in. This understanding comes from doing the analysis. You can still use techniques like swim lanes, workflow documents and process models to define the value.  The difference with agile is those insights can be documented at a high level using general sketches or holding a workshop to define information on a whiteboard. The requirements documentation must be sufficient to create a shared understanding for team.

Shift in Mindset for Agile Requirements

In agile you still document your requirements, but you may document them differently using post it notes on a wall, or on a flip chart with a picture of the flip chart to share with others not in the room. In other words, think about the way you document requirements in more creative ways.  You want to retain the analytical and thinking processes, including elicitation, and collaboration.   Importantly, it is not about NO documentation, it’s about AVOIDING overly detailed documentation.

If you get push back on the level of documentation within your organization, consider asking questions as to why documentation is needed to ensure what you are producing serves the needs of the company and the project. This will help organizations let go of old habits and intentionally reduce the rigor in the requirements to bring value to the organization.

Tips for Creating Successful Agile Requirements

Here are some helpful tips to try as you document agile requirements.

  1. Agile requirements don’t need to be perfect

The key to success is agile requirements and documentation should be barely sufficient.   Your requirements do not need to be perfect.  Do just enough to meet the need and create a shared understanding.  Force yourself to let go of perfectionism when it doesn’t add sufficient value. Remind yourself as you work, is this the best use of your time.  It will help you step back and evaluate key tasks and outputs to deliver value.

  1. Understand the timing

In an agile environment, how do you deal with completed requirements at the last responsible moment?  This doesn’t mean procrastinate. What it really means is, if you define some things too early in the process, the requirements will have to change, requiring unnecessary rework.

For example, if you create detailed models of what the product will look like before you know exactly where each feature is going to fall in the release plan, you may have designed something that isn’t needed until the last release if ever. In that time, some elements will have likely changed. The idea of letting things fall into place at the last responsible moment is a great time saver.  In the meantime, you can still be creating smaller increments of value that the team can consume. Knowing what can benefit from waiting allows you to learn along the way and gain more information and perspective.

  1. Define a process to document ideas

Have an organization system for future ideas.  It’s an excellent way to capture a thought that might not be ready to explore and develop.  If you have documented the idea or an important finding at the time, you can come back to it when it may be more appropriate or beneficial.  The other benefit is that you won’t have to start from scratch. One way to keep track of these ideas is to write them down on a future date in your calendar to keep the idea of top of mind.

  1. Balancing the high level and the details

Knowing when to focus on the high level and when to get into the details is a constant challenge of a business analyst.  When working on an agile project, in the early stages when you are doing product visioning, you need to focus on a high level.

However, there are times when a topic will come up and you must let the team talk at a detailed level to make sure everyone is understanding the vision and goals in the same way.  An idea may surface, and the team needs to go deeper into the details to determine it if the idea should be a part of the vision.

Over the course of a project, you will cycle through guiding the team through the details and then back to the high level to align with the larger project vision and objectives.  Don’t be afraid to go deep when the team needs to so that everyone feels comfortable there is a plan that will work and a shared understanding of the product or service features.

  1. Be nimble

In agile projects, analysis requires you to define work slightly ahead of the development team.  You need to be able to continuously get more detail about the business needs and desired requirements.  At the same time as you are working ahead, you need to be able to respond to a change in the current iteration to help the development team adjust and prioritize.

Developing agile requirements means you have to be open and nimble to keep the present iteration moving while planning for the next set of work.

Still Interested in Developing Effective Requirements?

To help you adjust your analysis practices to a more agile style, RMC offers a case study-based course teaching professionals working on agile teams to develop effective agile requirements.

Contact us about this two-day, virtual session to learn how you can become nimbler while continuing to satisfy stakeholder needs on your next project.

You can also listen to my podcast with Dave Saboe.

Sources:https://www.batimes.com/articles/agile-requirements-documentation-what-s-really-needed

Posted on by

Contract Issues in Agile Development

Two business people review signing a contract

There has been a significant amount of discussion regarding the tension between development and agile contracts. Many see this conflict as irreconcilable, citing provisions in the Agile Manifesto favoring “working software over comprehensive documentation” and “customer collaboration over contract negotiation.”

Those who see the conflict this way claim that lawyers are operating in an outmoded mindset and need to be educated about the agile method of doing business. These same people claim that lawyers perceive many agile practitioners as unrealistic and naive.

In my view, this so-called tension is the result of a misconception of the lawyer’s role and of his or her duty to the client.

Contracts and Agile Development

  1. The Role of the Lawyer
  2. Implementing the Parties’ Intentions through Form Contracts
  3. Similarities in Agile and Other Development Contracts
  4. Agile-Dependent Provisions
  5. Similarities between Agile and R&D Contracts
  6. What Would an Agile Contract Look Like?

The Role of the Lawyer

The lawyer’s duty is to protect the interests of his or her client. What does that mean, exactly? To those in the “lawyer as dinosaur” camp, it means that a negotiation is perceived as a zero-sum game, with success being defined as winning the maximum number of business points and shifting as much business risk as possible onto the other party. In fairness, I have seen negotiations go that way and, at times, lawyers take a leading role in those types of adversarial negotiations.

In my experience such types of negotiations are ultimately unsuccessful because the relationship and the business objective underlying the agreement usually fail. That doesn’t do anyone any good, and it can’t be viewed as truly protecting the interest of the client.

A lawyer’s job is to assist their client in reaching their business objective. Part of that responsibility includes reducing risk to the client. The definition of risk, however, cannot be compartmentalized into individual business points or contract provisions, and must include the overall goal of the contract.

In the end, the object of the contract is to document the intentions of the parties and to create a mechanism to implement those intentions.

Implementing the Parties’ Intentions through Form Contracts

Much has been written about the need for new and specialized modalities surrounding contracts intended to implement agile methodologies. For example, in 2008 the Norwegian University of Science and Technology conducted a detailed study of problems associated with contracts in agile development projects. This ultimately led the Norwegian Computer Society to adopt a standard form contract to be used for agile software development, maintenance, and service operations.  There are many other form contracts purporting to be agile friendly. For example, see the Draft/Contract for use in DSDM Projects (DSDM refers to dynamic systems development method, an agile methodology).

Although these form contracts can be useful, there are already existing procurement methodologies that can accommodate the iterative approach used in agile software development.

Similarities in Agile and Other Development Contracts

One reason existing form contracts can be used for agile is because agile development shares many of the same needs of other types of development. For starters, you need to identify the parties to the contract. You need to have an effective date and a start date. You need to state when and how the vendor will be paid.

In addition, as with other software contracts, there must be warranties from the vendor, such as one warranting that it owns the rights to the code it will be developing and selling to the purchaser. There should also be some software escrow provision allowing the purchaser to gain access to the code should the vendor file for bankruptcy or go out of business. These are just a couple of examples. There are many others.

Agile-Dependent Provisions

The tricky issue with contracts and agile development stems from the iterative process and the intentional lack of documentation regarding the scope of work or the performance characteristics of the product being purchased.

In a traditional procurement, there is normally a detailed specification or statement of work that sets the standard against which vendor performance will be measured and allows for a firm price. This approach won’t generally work in agile development. But there are other contract methodologies, such as those used in research and development (R&D), designed to deal with situations where detailed specifications are impossible. Such contracts may be adapted to fit into the iterative approach called for by agile.

Similarities between Agile and R&D Contracts

In many agile agreements the requirements, by design, are not well documented. The same can be said for R&D contracts. Parties often enter into R&D contracts without knowing whether the object of the agreement is even doable. One area where these contracts may differ is in the iterative methodology used in agile; however, this is not critical, and the iterative methodology can be documented.

What Would an Agile Contract Look Like?

As far as scope is concerned, both an agile and R&D contract would probably have a simple statement, not necessarily of work, but of goals. There would be provisions allowing for a re-scoping after every iteration, a process for identifying what was done and what was not done. With respect to those items that were not done, the contract would also document a decision process governing whether those pieces of work would be put into the next iteration, mothballed, or discarded. There would probably also be provisions for the re-scoping of work for the next iteration.

Payment would most likely be either on a cost-plus basis (with a fee or profit component) or for time and materials. Given the uncertainties of the project, a firm fixed price would most likely be impossible, but there could be a budget target or cost estimate that might go in at the front end, against which the project progress could be measured.

In this respect, an agile project would differ from R&D in that the end of the project would be defined as when the purchaser runs out of money, not when the goals of the project have been reached. Honestly, this would most likely be extremely dissatisfying to a purchaser, especially one that did not have a business history with the vendor.

There would also need to be provisions governing testing and acceptance, at the end of each iteration and at project completion. One issue is the criteria governing acceptance. If requirements are not defined up front, how do you determine what success looks like at the end? It could be defined by requirements set forth at the beginning of each iteration; the contract would require each successive set of requirements to be met for the project to be deemed successful. With this approach, one concern is the situation where all the pieces work, but the final product is unsatisfactory. In my view this is the largest problem with agile contracts, but in many respects it’s no different than an R&D contract where the parties have goals but no real knowledge of whether those goals can be achieved.

As long as the parties’ expectations regarding the final product are understood and documented up front, with the understanding that if the purchaser’s expectations are not achieved, the purchaser would only have limited recourse, then an agile-based contract would work.

Boilerplate provisions would be similar to those found in other contracts. IP warranties and indemnifications would be the same, as would severability, governing law, notifications, modification, confidentiality, and competition.

RMC is Here to Get You Started

In looking at agile contracts, the documentation requirements are not all that unique and can be fit into other more traditional procurement methodologies. There is no need to completely reinvent the wheel. Rather, the lawyer and practitioner need to keep in mind that they are creating an agreement in an environment of uncertainty, not unlike that found in an R&D contract.

In response to the growing relevance of Agile methodology for all Project Managers, the Project Management Institute (PMI®) has begun offering the Agile Certified Practitioner (PMI-ACP®) certification exam. RMC Project Management offers comprehensive exam preparation products, eLearning and classroom training options to help you earn PMI-ACP certification

[/et_pb_text][/et_pb_column][/et_pb_row][/et_pb_section]