Agile Manifesto for Product Management, Part 2

July 6, 2015

In Part 1 of this two-part series on the agile manifesto for product management, I described the four phases of agile development projects: conception, definition, planning, and deployment; then covered the first four of nine principles for agile. Now, in Part 2, I’ll cover the remaining five agile principles, then conclude with a summary of some benefits of agile software development.

Principle 5: Frequent Delivery

Since the agile mindset is flexible, iterative, and dynamic, frequent delivery is an important agile principle. Empowered teams with intense user involvement can achieve frequent delivery through well-defined, time-boxed planning. In an agile approach, it is a team’s responsibility to deliver maximal business benefit through minimal business requirements.

Champion Advertisement
Continue Reading…

Delivery Using MoSCoW

Map requirements to benefits and prioritize them using MoSCoW (Must, Should, Could, Won’t Do). Keeping these priorities in mind, timebox your plans to ensure frequent delivery, starting with the must-have features. There are two aspects to frequent delivery:

  1. Products, or deliverables—We should distinguish between process products—that is, project documentation—and project products—the individual components that together form a business solution.
  2. Activities—The delivery of a product is the outcome of completing multiple, iterative activities, or tasks, that a time-boxed plan comprises. Using MoSCoW ensures that all activities and the ultimate product delivery are in line with business priorities.

The principle of frequent delivery is important to ensure that a team remains engaged and focused and gives all stakeholders the necessary confidence in a project’s outcome. When a team achieves frequent delivery, a project will have constant visibility as it progresses. Prototyping enables frequent delivery. Plus, a prototype or mockup is worth a thousand words.

Frequent delivery builds confidence, commitment, and quality. Plus, it strengthens the communication that is so important to the success of any agile project.

Frequent Delivery in Practice

Ideally, you should implement frequent delivery through proper time-box management—starting with your planning process and involving all committed resources. Planning should ensure that the output from each time box is in line with business priorities.

A project requires a well-documented requirements catalog, or backlog, that you’ve mapped to expected business benefits. The requirements catalog defines increments of the delivery stream. During the development of each increment, the team delivers prioritized requirements according to a time-boxed plan.

To keep team members on task, the project manager conducts daily debriefing sessions whose key objective is to ensure that the must-have deliverables get completed by the end of a given time box. A focus on frequent delivery is an agile mindset that should pervade the entire development process.

Principle 6: Fit for the Business Purpose

Regardless of process or methodology, it is important always to remember the purpose of a given project: the business problem that it must solve. The challenge in finding an optimal solution is bringing the ideas and¬†expectations of all key stakeholders together to ensure that everyone understands the project’s objectives and the product ultimately meets market requirements.

While the team may have discussed ideas for solutions over many hours and everyone thinks they have the same vision, when you move to the prototype stage, you may discover that the team is not aligned on a singular vision. The last thing a product manager wants to hear is: “That’s not how I thought it would look.” or “That’s not the function we asked for.” Such responses usually mean more time, more money, and mounting frustration.

Collaboration prevents such misalignments. One way to get a whole team collaborating is through sketching and prototyping. Deliverables such as prototypes, mockups, or wireframes depict a vision behind which the entire team can align—whether you’re building a Web site, a business service, or a product.

Three Reasons to Visualize a Solution

Creating design deliverables such as prototypes, mockups, or wireframes lets you achieve these goals:

  • Identify requirements up front. The project team needs to capture key stakeholders’ requirements for features and functionality early in the development process. Deliverables that visualize a solution help to set expectations.
  • Focus on usability. Creating these deliverables enables the core team to focus on user experience and usability—as well as the ultimate delivery of business benefits.
  • Save time and money. Producing such deliverables early and iterating them often demonstrates the benefits that the product will deliver and helps the team to avoid late design changes that can negatively impact timeline and budget. When you take an iterative, incremental approach, change is built into the process, as I’ve outlined in Principle 7.

Principle 7: An Iterative, Incremental Process

Traditionally, project teams have spent a significant amount of time performing analysis and considering design solutions. By the time development starts, the business requirements may have changed significantly without their realizing it.

An agile delivery process breaks down projects into iterations. This allows a team to deliver maximal business benefit in increments, without compromising quality or cutting corners. The agile process is both iterative and incremental. Iterative development, or iterative planning, enables a team to converge on an appropriate business solution through three types of iterations—investigative, refinement, and consolidation iterations.

Incremental delivery enables the business to reduce time to market, derive business benefits as quickly as possible, and reduce costs. In many instances, by the time a team is ready to start on a refinement increment, the business may already have derived 80 percent of the desired benefits, so can weigh the additional benefit of delivering the remaining 20 percent against its cost.

User involvement in iterative, incremental delivery helps a team to create an appropriate, holistic, user- or customer-focused business solution. Consider the following benefits of iterative, incremental delivery:

  • time to market—Every organization must react quickly to market changes and business challenges. Speeding time to market and quickly giving the business what it really needs adds significant value. Agile is one of the cultural changes that organizations are embracing to help them manage the pressures of today’s fast moving, global business climate.
  • reduced costs—Many organizations have developed systems that included functions their audience never required. If a development process focuses on delivering business benefits instead of on delivering functionality and features, organizations not only can accelerate time to market, but also can reduce costs.
  • effective project management—Good planning incorporates realistic resource management, which is more achievable when a project’s time horizon is six months or less. An iterative, incremental process allows you to make changes in resource allocation on the fly—thus, enabling more efficient project management.

The Iterative Process for Product Managers

By the end of the definition phase, the business visionary or product manager—together with other team members such as the UX lead and engineering lead—presents potential business solutions to stakeholders for review, discussion, and signoff. A project should proceed only once the leadership team has reached consensus on the best business solution.

Going into the planning phase, a project team should have a clear vision of the desired solution. At this stage, you should baseline requirements at a high level. The product manager or business visionary, UX design strategist, technical architect, and project manager must discuss the target solution and decide how best to break its implementation into increments.

The roles of those who are involved in making these decisions are responsible for carrying out different mandates:

  • product manager—The person in this role must ensure that the team delivers maximal benefit to the business when implementing the first increment.
  • UX design strategist—This person’s objective is to ensure that the solution delivers maximal benefit to users and achieves the goals of usefulness, usability, and emotional satisfaction.
  • technical visionary—This person must ensure that the breakdown of the implementation effort reflects the critical delivery path that technical requirements impose.
  • project manager—It is this person’s responsibility to ensure that the implementation of no increment is subject to resource constraints, while maximizing the availability, engagement, and output of the resources who are assigned to the project.

Once the team has broken the project down into increments, they must determine the delivery streams for each increment. For example, an increment could have a delivery stream that relates to software development, another to business-process change, and a third to communication and public relations.

The team then breaks down each of these streams into a time-boxed plan, with each stream comprising requirements from the prioritized requirements catalog. Time-box planning iteratively identifies the necessary investigative, refinement, and consolidation tasks. The goal of this agile process is to yield a successful implementation for all team members, including the sponsoring product manager.

Principle 8: Reversible Changes

The fast development and delivery environment of agile not only requires iterative, incremental change, but also the ability to reverse changes should they prove to result in a less than ideal solution. A project team may even face situations in which it must roll back the code to a previous version.

This is especially likely to occur when continually evolving requirements from product managers or user representatives are driving the development process. User representatives may discuss business requirements to which they had previously agreed and find that it is necessary to revise those business requirements and roll back to a previous, preferred version. The team would need to participate in ideation and prototyping sessions to satisfy the redefined requirements.

A project may consist of one or more components, with each component having its own development lifecycle and version. A configuration refers to bringing together different components into a solution. With all of this possible complexity, it is essential that, during development, all changes be reversible to guarantee speed, quality, and the confidence of the team that they will be able to continue moving forward.

Business Benefits

Enabling things to happen faster, encouraging quality, and instilling confidence is as much a part of agile as it is just common sense. The same is true of making changes reversible during development, because iterations should result in process improvements and business benefits, as follows:

  • speed—In a fast development environment in which products evolve through structured prototyping sessions, a team must have the necessary infrastructure to support quick rollbacks.
  • quality—With reversibility in place, user representatives can change business requirements, when necessary, and the team can recommend different ways of implementing them. This gives the whole team a sense of ownership and commitment.
  • confidence—Empowering user representatives by supporting reversible changes enables them to be creative and confident because they can easily recover from making less than optimal decisions. The team should perceive making mistakes as learning experiences and can roll back to an earlier version with no additional expenditure of money or time.

Implementation and Delivery

The project manager and technical architect must agree on the level of configurability a project requires. A reusability strategy may have an impact on this decision—because, while it provides speed, it can also create complexity when changes impact a project. It is essential to record their configuration management agreement in the functional requirements document, which the team should have completed by the end of the definition phase.

The document that defines the technical architecture should be completed by the end of the planning phase. In this document, the technical architect defines the following:

  • required level of configurability
  • process for configuration management
  • standards for the project team to apply
  • release management policies and procedures
  • version-control policies and procedures

Reversible changes enable the entire team to be creative and confident that they can easily recover from mistakes in a timely manner. Iterative planning identifies the necessary investigative, refinement, consolidation, and development tasks for each time box.

Principle 9: Technical and Business Testing

Are changes the team has made working in the real world? Does a solution solve the business issues that prompted its development? There is only one way to find out—by doing testing, both internally and with users.

In traditional software development, testing usually occurs after development is complete. When taking this traditional approach, the business risk is that the project would have consumed 90 percent or more of the available time and budget by the time testing starts—when it would clearly be too late to make changes and stay within the defined time and budget constraints. The purpose of agile testing is to mitigate business risk and develop better products through iteration and testing.

It is necessary to integrate testing throughout the development lifecycle, starting as early as the definition phase and continuing through the solution’s deployment. During definition, you should test models and prototypes. This can potentially save your organization huge amounts of time and money. In the deployment phase, user acceptance testing should be more than a formality and should involve testing the end-to-end solution—including documentation and training—within the deployment environment.

That a solution should be fit for its business purpose, as I described in Principle 6, is the key criterion for accepting deliverables, including the delivery of code. Quality control is an integral part of supporting this principle. An agile team should make testing part of their time-boxed plan to leverage this essential aspect of delivering business value.

Integrated Testing for Quality, Confidence, and Visibility

Agile development is highly pragmatic, and doing testing is common sense. Testing offers the following benefits:

  • quality—On-going testing is the key to delivering quality solutions. While developers and quality assurance engineers should test functionality for robustness and performance, UX professionals and user representatives should test the usability of workflows and functionality. The test results become specifications that guide design and coding and ensure quality.
  • confidence—I’ve rephrased the common business axiom “fail fast, fail often” as “test fast, test often.” Continuous testing ensures that a team is developing the right business solution, in the right way. This builds confidence and motivation in team members, making development fun for them.
  • visibility—Testing with users provides the opportunity for sponsoring customers to get to know the solution before it goes live, gives them peace of mind, and provides an effective training platform for them.

Implementing Testing for Product Managers

Here are six principles for the implementation of testing that ensure quality planning, execution, and reporting. Testing should

  • provide validation—Testing ensures the necessary validation of a solution and its implementation throughout its development.
  • be benefit oriented—Integration testing of components ensures that a team delivers a robust solution. Business benefits should map to specific requirements you’re testing.
  • occur throughout development—Testing should occur continually, throughout the development cycle, and it should be supported by the right level of documentation.
  • be independentThe people who are responsible for delivering a solution and those who test their deliverables must be different people.
  • be error centric—The perspective of quality-assurance engineers should be that a solution must pass the test. While they must conduct testing with a positive attitude, they should also remain focused on errors.
  • be repeatable—If a given component fails to pass a test, it is necessary to revise and test that component iteratively until it passes the test; then to do integration testing as well. Thus, whenever a team makes changes to a component that has previously passed a test, it is necessary to retest that component.

The technical architect is responsible for creating a well-defined testing environment and documenting the requirements for it in the functional requirements document that the team produces during the planning phase. Everyone testing a solution—whether developers, quality-assurance engineers, UX professionals, or user representatives—must prepare test scripts. The three key sections of the documentation that defines these test scripts are as follows:

  • What are we going to test and why?
  • What are the expected results, and how are we going to test that the solution meets expectations?
  • What are the actual results?

With these guidelines in mind, the team can successfully conduct testing and contribute substantially to the quality of the solutions that they deliver, ensuring that they deliver maximal customer and user value.

Summary of the Business Benefits of Following Agile Principles

As I’ve detailed in this article, there are innumerable benefits of implementing agile development—both for the sponsoring business and the development partner. Ultimately, the agile mindset leads to lean, nimble solutions that fit business needs. In this section, I’ll provide summaries of both internal and external benefits of agile development that contribute to better products and, thus, improve bottom-line business results.

Internal-Team Benefits

Agile development offers the following benefits to internal development teams:

  • ownership—When users and stakeholders are an integral part of a project throughout the development lifecycle, they have a strong sense of ownership in its outcome.
  • quality—When all team members strive to reach the same goals, they can create the best business solution and deliver maximal benefit to users, customers, and the business sponsoring the project.
  • commitment—A collaborative approach secures the necessary, high-level commitment that is a key success factor in meeting user and business needs.
  • effective project management—Realistic, dynamic resource management results in a more efficient project-management process.
  • speed—On agile projects, products evolve quickly through structured prototyping, quick rollbacks, tight configuration, and effective project management.
  • confidence—Empowering user representatives by enabling reversible changes, continual testing, and frequent delivery builds their confidence in your delivering the best business solution possible.
  • consensus—A collaborative, iterative approach that involves the business sponsor, stakeholders, and senior management helps build consensus.
  • clear direction—Having clearly defined requirements and evaluating time, cost, risk factors, constraints, and assumptions gives the team a clear sense of direction that enables them to develop the best business solution.
  • motivation—Leveraging business and technical expertise through team empowerment leads to high motivation and job satisfaction.
  • creativity—Agile team members are more involved in projects, which translates to greater creativity that can lead to ground-breaking solutions.

External and Bottom-Line Benefits

Agile development results in the following benefits to an organization, its customers, and the users of its products:

  • reduced costs—Focusing a development process on delivering business benefits instead of features and functionality reduces development costs for sponsor organizations.
  • higher visibility—Frequent delivery raises the visibility of a project, the sponsoring product manager, and other team members.
  • higher quality—User input and on-going testing positively influence the usability of workflows, the usefulness of features and functionality, and the better overall quality of a solution. Quality solutions deliver business benefits.
  • faster time to market—Agile development enables companies to react to business challenges more quickly, accelerates time to market, and creates competitive advantage.

It is evident that agile methodology provides many advantages that traditional development approaches do not. By carefully orchestrating the implementation of these nine agile principles, you can successfully leverage them to deliver better solutions, higher revenues, and increased user satisfaction. 

Product Manager at Gaming Innovation Group


Andrew MicallefWhen Andrew studied software engineering, he discovered his passion for agile development and Web applications. These passions continue to drive his desire to seek simplicity and exceptional user experiences that allow people to focus on their tasks rather than their tools.  Read More

Other Articles on Product Management

New on UXmatters