Agile Manifesto for Product Management, Part 1

Project Phases

Agile projects comprise four main phases, each of which addresses the key points I’ve outlined in the following sections.

Phase 1: Conception

The Conception phase comprises the following:

• asking the following questions:
  
  • Are we dealing with a business problem, an opportunity, or both?
  • Is it critical for the business to do something about this?
• taking a structured approach to providing a complete, detailed description of the business issues to be addressed
• identifying the stakeholders who will move the project forward
• determining whether there is a need to involve specialists
• devising and agreeing on a plan to move to the Definition phase

Phase 2: Definition

The Definition phase comprises the following:

• investigating and examining in detail the challenge at hand
• quantifying the value of the solution in monetary terms
• discussing, defining, and agreeing on SMART (Specific, Measurable, Achievable, Relevant, Time Bound) business objectives for addressing the challenge
• discussing, identifying, and agreeing on the project’s business benefits, which must be
  
  • quantifiable—Specify the percentage contribution of each benefit.
  • measurable—Define the mechanism by which to measure benefits.
• defining at least two solutions, including the
  
  • amount of business value it will deliver
  • timeline for creating it
  • estimated cost (± 40–60%)

Phase 3: Planning

The Planning phase comprises the following:

• discussing the business requirements that are within the scope of the project to better understand the details
• prioritizing the requirements to ensure that the project will deliver maximal business value at the end of the first development cycle
• identifying the project increments and map business requirements to the appropriate increment
• outlining a plan for the increment on which work is about to commence, including an implementation schedule, requirements estimates, and resource availability
• defining and documenting a technical architecture that supports the vision and the necessary technical features of the solution

Phase 4: Deployment

The Deployment phase comprises the following:

• conducting user acceptance testing and signing off on the solution by authorizing deployment in a live environment—The test solution document that the team produced during the build iteration evolves into an accepted solution document.
• planning and delivering the necessary training to ensure that the new business solution works and is supported well once it is live, including providing
  
  • user-community training
  • support-staff training
  • administration-staff training
• installing automated processes according with the functional and non-functional requirements
• implementing business processes that complement those automated processes to deliver a business solution, including
  
  • software installation
  • communication and network setup
  • enforced and audited business processes
• reviewing what the new business solution has achieved to date and establishing whether to proceed with further investment, asking:
  
  • Is there any budget left?
  • Do we need to deliver more benefit?
  • Would it be worthwhile?
  • Has the business moved on with changed requirements and priorities?

Principle 1: Use a Collaborative, Team Approach

Setting up a framework for a well-run team process and positive outcomes requires a collaborative, cooperative approach among the business and technical people who are involved in a project. The success of an agile project depends on effective communication and the manner in which a team brings in stakeholders and keeps them on board.

Distinguish between two types of stakeholders: recipients and actors. Recipients are those stakeholders that the result of the development project will impact. Actors are those stakeholders who must effect the desired business change. The involvement of both groups is critical for this important agile development principle to work.

As early as the Conception phase, the project sponsor, business visionary, and project manager must identify the stakeholders—for example, product managers for facilitation and leadership, potential customers for user involvement, and technical staff for execution. Involving the right people from the start is an important internal-selling exercise whose goal is to secure senior management buy-in and is a critical success factor.

Making Team On-Boarding and Cooperation a Success

The facilitator should consider organizational politics, hidden agendas, and history when organizing workshops and bringing people with varied backgrounds together. If he does not give this the appropriate attention, it could negatively impact the process.

From the Planning phase onward, stakeholders must remain involved in the project through good communication. This tends to develop by involving stakeholders in major prototype review sessions. Formulating a plan for communication by the end of the Definition phase is key to making the collaborative, team approach facilitate project success.

Principle 2: Ensure On-Going User Involvement

Successful products serve customer needs. Just as market research and focus groups are key to the success of new consumer products, it is necessary to involve users in less tangible products such as software, technology, and Web solutions.

Even if a project delivers on time and on budget, if it does not meet customer requirements, it cannot be considered a success. Involving users early during development ensures that a solution addresses real business and user needs and includes the requirements that are essential to deliver the expected benefits.

Involving users during early development and beta testing ensures their taking ownership, delivering quality input, and feeling a commitment to the product’s market success.

• ownership—The involvement of users ensures that they understand the
  
  opportunities and help to define the business requirements. Prototyping sessions allow users to influence product design, which gives them a sense of ownership.
• quality—Involved users share their personal experiences and real-life examples with the development team. This user input can positively influence the implementation of workflows, functionality, non-functional requirements, and the quality of the final product.
• commitment—When users have been involved in a project from the beginning and have had input to the solution’s design and functionality, they are committed not only to the success of the solution, but also to using the product.

Team members need to obtain user feedback early and often, or they’ll miss requirements, leading to delays and added cost. When a team manages such risks well, user involvement delivers benefits that are essential to building a successful solution.

Principle 3: Empower the Development Team

Senior management should understand the balance between fostering empowerment and following process. To get a team to make quick decisions, product managers and technical leaders must avoid assigning blame—for example, for an unworkable iteration. They must empower team members to act fast and give their best, which makes them feel valued for their contributions.

Of course, organizations exist in which agile-team empowerment does not fit the company culture and is, therefore, hard to achieve. In this case, the business visionary must be available to ensure that decisions get made promptly.

A business project could potentially consist of diverse delivery streams—such as information technology, communication and marketing, and business process. It is vital that leaders empower the teams delivering these to make wise decisions and communicate them effectively, while always considering user input, according to Principle 2.

On-time delivery is one of the most sought-after goals for decision makers working on a project with fixed timelines and budgets. This is best achieved by allowing team members to trust their experience and make critical decisions. Not only is this highly motivating, it also leads to team learning and better outcomes.

Why You Should Empower Team Members

Explicitly giving team members license to make critical decisions, question assumptions, think out of the box, and make bold moves brings tangible process and business benefits.

• speed—An empowered team is able to discuss issues and challenges relating to their deliverables, make decisions, and resolve challenges quickly. In the absence of such empowerment, slower resolutions will have a negative impact on the timeline.
• motivation—Empowerment is about recognizing people’s ability to think and leveraging their business and technical expertise. This builds trust and inspires accountability and commitment.
• creativity—Empowered people are more committed, as well as more
  
  involved, which translates into increased quality and creativity, which can lead to ground-breaking solutions.

Stronger, Better, Faster Solutions Teams

The project sponsor, business visionary, and project manager must identify the different user groups who must embrace the new solution. Once on board, the visionary collaborates with the project manager to establish a user-involvement strategy on which senior management must sign off.

For example, if an identified user group consists of a population of ten users, request senior management to accept that the team will appoint two of them as user representatives. They will become an integral part of the development team for the duration of the project or increment, ensuring that they bring the necessary business experience and skills to the team.

Generally accepted team management skills such as facilitation—with ground rules—whiteboarding, time-keeping, clear task assignments, and effective communication go a long way toward empowering team members to contribute their best to the project and feel part of a powerful agile process.

Principle 4: Baseline Business Requirements to Avoid Scope Creep

Setting a clearly defined baseline for business requirements is key to preventing scope creep, one of the main reasons projects fail. This agile principle can significantly reduce the serious risk of unwittingly expanding project scope. So, what does it mean to baseline, or create an agreed-upon description of product attributes during the definition stage—early in a project?

The development team prepares more than one option during definition. This enables senior management to select the solution that best addresses the business opportunity at hand, which marks the end of the Planning phase. The ensuing Definition phase starts the baselining process, during which the team prioritizes requirements using the MoSCoW (Must, Should, Could, Won’t Do) approach, and defines the timeline, resources, and budget for the project.

Business Benefits for Product Managers

In addition to process benefits that save time and money, the baselining process translates into the following business benefits:

• consensus—The business visionary or product manager presents the proposed business solution to the business sponsor, stakeholders, and senior management. The workshop agenda focuses entirely on ensuring that the team derives the best business option through a collaborative approach.
• direction—The key stakeholders discuss the business options and evaluate factors such as time, cost, risks, constraints, and assumptions. This leads to consensus and selecting the best option.
• commitment—The key stakeholders all confirm their commitment. They have worked together to select the highest priority business option. A collaborative approach secures the necessary commitment at this high level, which is a key success factor.

How to Implement Baselining

It is possible to implement the agile principle of baselining only once a feasibility report is ready at the end of the Definition phase. Throughout this phase, the development team focuses on the business problem and opportunities. The team creates options and presents them to senior management, who select the option with which to move forward.

During the Planning phase, the team prioritizes the business requirements for the selected option, breaking them down into as many levels as necessary to ensure that the must-have requirements do not exceed 40% of the total estimated time allotment according to MoSCoW.

The development time is now fixed. The requirements and pertinent estimates give the development team a clear idea of the necessary effort. Using the two parameters elapsed time and effort, the development team can establish the staffing resources and skills that are necessary to ensure on-time, on-budget delivery. Through baselining, the development team gets a clear idea of what they must deliver, in what timeframe, and with how many people. At this point, baselining is complete. This helps guarantee project success. 

References

Agile Alliance. Home Page. Agile Alliance, 2015. Retrieved July 15, 2015.

Babineaux, Ryan, PhD, and John Krumboltz, PhD, “Fail Fast, Fail Often: How Losing Can Help You Win.” The Daily Beast, June 1, 2014. Retrieved July 15, 2015.

Beck, Kent, Mike Beedle, Arie van Bennekum, Alistair Cockburn, Ward Cunningham, Martin Fowler, James Grenning, Jim Highsmith, Andrew Hunt, Ron Jeffries, Jon Kern, Brian Marick, Robert C. Martin, Steve Mellor, Ken Schwaber, Jeff Sutherland, and Dave Thomas. “Manifesto for Agile Software Development.” AgileManifesto.org, 2001. Retrieved July 15, 2015.

Boag, Paul. “Never Wireframe Alone.” Boagworks Ltd., May 21, 2013. Retrieved July 15, 2015.

Denning, Steve. “The Best-Kept Management Secret on the Planet: Agile.” Forbes, September 9, 2012. Retrieved July 15, 2015.

DSDM CONSORTiUM. Home Page. DSDM.org, 2015. Retrieved July 15, 2015.

International Consortium for Agile, The. Home Page. icagile.com, 2015. Retrieved July 15, 2015.

Larson, Richard, and Elizabeth Larson. “Top Five Causes of Scope Creep—and What to Do About Them.” Project Management Institute, 2013. Retrieved July 15, 2015.

Olson, Dan. “Lean Product Management.” Google Ventures, December 3, 2013. Retrieved July 15, 2015.

Rising, Linda. “The Power of an Agile Mindset.” YouTube, November 4, 2011. Retrieved July 15, 2015.

Wells, Don. “Agile Software Development: A Gentle Introduction.” Agile Process, 2009. Retrieved July 15, 2015.

Wikipedia Contributors. “MoSCoW Method.” Wikipedia, 2015. Retrieved July 15, 2015.

Wikipedia Contributors. “Agile Software Development.” Wikipedia, 2015. Retrieved July 15, 2015.