Product ownership is a team sport
A number of agile brands downplay the need for business analysis and requirements management on agile projects, putting large store in the role of the product owner. This paper tackles some of the problems this misconception can result in and shows how effective product ownership almost always requires a team with a variety of skills and backgrounds to be effective.
Product ownership requires clarity of vision, alignment with organizational strategy, understanding of the development process, and the ability to communicate with a wide variety of stakeholders across all levels both inside and outside the organization. The complexity of the role is most often more than a single person can (or should) cope with—effective product ownership requires a teamwork approach covering a variety of skills and knowledge.
The Product Owner Role
The product owner is one of the three roles defined in Scrum, and is referenced in many of the agile brands. The term product owner has become almost ubiquitous, yet there is a lot of confusion and a lot of misinformation about what the role is and what it actually entails.
The Scrum guide defines the product owner role as follows:
The Product Owner is responsible for maximizing the value of the product and the work of the Development Team. How this is done may vary widely across organizations, Scrum Teams, and individuals.
The Product Owner is the sole person responsible for managing the Product Backlog. Product Backlog management includes:
- Clearly expressing Product Backlog items;
- Ordering the items in the Product Backlog to best achieve goals and missions;
- Optimizing the value of the work the Development Team performs;
- Ensuring that the Product Backlog is visible, transparent, and clear to all, and shows what the Scrum Team will work on next; and,
- Ensuring the Development Team understands items in the Product Backlog to the level needed. (Schwaber & Sutherland, 2013)
Extreme Programming talks about needing the customer onsite all the time:
One of the few requirements of extreme programming (XP) is to have the customer available. Not only to help the development team, but to be a part of it as well. All phases of an XP project require communication with the customer, preferably face to face, on site. It's best to simply assign one or more customers to the development team. (Wells, 2009)
This puts a huge demand on the individual taking the product owner or onsite customer role, one which for the vast majority of real-world projects is beyond the skills and capabilities of any one individual.
The nature of knowledge work is that it is inherently unpredictable, especially in complex environments such as software development projects. The typical software development project today requires interfacing with a number of existing systems both internal to and outside of the control of the organization building the product, solving problems for a variety of stakeholders from different business units or divisions spread across multiple locations in different time zones.
Add to this complexity the nature of product development projects—often the problem to be solved is unclear and unknowable until the solution surfaces.
The Cinderella Project
In September 2005, Jennitta Andrea described what she called the Cinderella Project, one for which the agile shoe fits perfectly. She described the characteristics of the Cinderella Project as:
- A team is small enough to fit within a collocated space—ideally less than ten people but no more than twenty.
- SMEs are a permanent part of the team.
- SMEs have a clear vision for the system requirements and can effectively communicate this to developers.
- SMEs can express the requirements in the form of functional tests.
- Either the problem domain has a short learning curve or the developers have deep experience in a more complex domain. (Andrea, 2005)
In that environment, the product owner would be the subebject matter expert (SME) able to provide the team with absolute clarity of direction and define clearly what success looks like for every aspect of the project.
Unfortunately this project doesn't happen often today, and almost never in the large corporate environment where agile practices are gaining greater and greater adoption.
The reality of the project environment today is much more complex and uncertain.
Projects are defined with vague goals, where the problem itself is not clearly understood; the business domain is in a state of flux; the technology environment is rapidly evolving (think mobile devices and platforms); the stakeholders have competing needs; and the team is distributed across many time zones.
In many organizations today team members are expected to work on multiple projects at the same time, architectures and interfaces are constrained and options restricted; timelines are unrealistic and inflexible; and the product being worked on may have 20 years of accumulated technical debt.
This is the modern reality of product development and project management. It helps to have a framework to at least begin to understand what the elements of complexity are.
The octopus model
Philippe Kruchten (2011) describes the eight aspects of context as follows:
- Size: how big is the system to develop (in SLOC, function points, or person-months)
- Criticality: how many people die if the system fails, or how many billions of euros are lost
- Age of the system: greenfield development, brownfield, evolution of legacy system, maintenance
- Business model: how is the project remunerated for its effort; in-house development, commercial product, software embedded in another product or system, open source development, research, etc.
- Team distribution: collocated, geographical distributed (outsourcing, etc.)
- Volatility of the environment: how stable are the requirements and the surrounding business environment
- Stable architecture: how much of a stable architecture exists at the start of the project
- Governance: what are the external rules imposed to the project to control its trajectory and how formal are they
He says that these elements’ impact on the approach that is needed for product delivery in roughly descending order of importance, and that they are in addition to the overriding factors of business domain and organizational culture.
Given the very real complexity of the product development environments we work in today, the product owner simply can't be the single voice defining value in what is to be built, it needs product ownership.
Product ownership encompasses a variety of areas of the organization and requires bringing together many voicesm, including:
- Product management
- Business advocacy
- Customer advocacy
- End-user advocacy
- Domain subject matter knowledge
- Business and technical analysis
- User experience and graphic design
- Legal and compliance
No one individual can represent all these aspects, nor can one individual hold all these considerations in mind—there is simply too much happening for one individual to provide the clarity of understanding and direction needed. It truly requires a team.
The Product Ownership Team
This image shows the likely knowledge and skills needed on the product ownership team:
- Value Facilitator: Someone who leads the team, engages with others to reach consensus and provides overall direction, and stands up for value and the product vision
- Project Management: Focused on time and money, understands the tradeoffs that need to be made to achieve the project's goals within the constraints imposed
- Governance: Focused on ensuring the right processes are followed and compliance needs are communicated to the team
- Business Analysis and Subject Matter Expertise: Brings domain knowledge and an understanding of who knows what, able to reach out to the wider stakeholder community to elicit needs and validate solutions, acts as the voice of the customer in specific areas
- User Experience/Graphics: Where there is a high degree of interaction in the required product, these skills are necessary to help make the product useful and useable for the target audience, and to ensure the right aesthetic values (such as corporate branding) are incorporated in the product
- User Acceptance Test/I V&V: Able to check the delivered product against user needs and (if required) validate it against legal or other external criteria and show compliance
- Delivery Team Facilitator: Brings the voice of the delivery team to the product conversations, ensuring the feasibility and sustainability of the delivered product, advocating for sustainable pace and technical qualities
These are roles not job titles—in some environments there may be just one or two people playing these roles, in others there may be many divergent jobs represented on the team.
The key is that the team has everything they need to identify and prioritize business value increments, to scope the smallest solution that might possibly deliver on the business value increment, and to prepare the runway for the delivery teams by gathering all the details needed by the delivery team to deliver a feature/story.
The Delivery Team
As with the product ownership team, these are roles not job titles—it is feasible that one person will play multiple roles on the team. The delivery team has everything and everyone they need to deliver a working increment of tested, documented, deployable software.
The typical roles in a delivery team encompass:
- Team Facilitation: The process conscience of the team, looking out for team health, process workability, and usefulness and removing obstacles to the product delivery
- Analysis: Bringing domain knowledge and an understanding of who knows what, able to reach out to the wider stakeholder community to elicit needs and validate solutions, and acting as the voice of the customer in specific areas
- Testing: Helping to define and measure quality in the product, assessing and advocating for quality in the delivered product, examining and communicating the state of the various quality aspects in the product
- Architecture: Providing advocacy, guidance, and clarity of direction from a technical viewpoint, ensuring the product fits into the broader technical ecosystem of the organization
- Development: The team members with the skills needed to deliver the product backlog items to fully production-ready state
The whole team is composed of generalizing specialists, people who (according to Scott Ambler):
- Have one or more technical specialties (e.g. Java programming, Project Management, Database Administration, etc.)
- Have at least a general knowledge of software development
- Have at least a general knowledge of the business domain in which they work
- Actively seek to gain new skills in both their existing specialties as well as in other areas, including both technical and domain areas
Putting Value Front and Centre
Product ownership requires that decisions are made with a value-based focus —what is the smallest piece of work we can do that will validate the assumptions being made, and deliver real useful value to our organization and delight our customers.
Value is not related to velocity—velocity is a measure of the cost of producing the product, not the value to the organization of having the backlog item built.
For the first few iterations, the team will pull work from the backlog based on confirming or disproving some assumptions, addressing some of the important areas of uncertainty and risk, and occasionally doing small experiments and spike solutions to reduce uncertainty risk through the rapid feedback cycle that agile projects allow—the early delivery will enable the value manager to validate the concepts and confirm or deny the early assumptions made about the customer needs. There will be a lot of learning about the capability of the team, the uncertainty in the project, the way people work together, and many other aspects which need to be exposed early in a product life cycle. There will definitely be velocity, but the delivered velocity will not be directly proportional to the value derived from the stories.
The likelihood is that these first few iterations will not produce enough of the product for it to be truly valuable in the marketplace until enough of the stories have been delivered to cross the minimum viable product (MVP) threshold—the minimum viable product that can be utilized beyond a select and limited group of early-adopter or test customers, something that actually does start generating at least a subset of the planned benefits.
Once the MVP has been delivered there is often a sharp upturn in value delivered—as new stories are added to the product they make it more attractive to the customers. For a while this sharp increase in value continues as the most useful stories are delivered. The iterative feedback nature allows the team to learn what the customers really want, and that is likely to be quite different from what was originally planned. As new stories are identified they need to be added to the backlog in value-based prioritized order.
At some point the rate of value delivery tapers off—the team has built the features and capabilities which are of the most interest to the customers, and adding new capabilities does not significantly increase the usefulness of the product to the customers. This is the point where the value facilitator needs to be ruthless about cutting the remaining work—yes there are plenty of epics and stories left in the backlog; yes there is more budget money in the pot; yes some people want those stories too; but is adding additional capabilities to this product actually the best thing to do with the remaining funding?
Evidence from studies of products seems to indicate that stopping work early is a very good thing. Depending on which study you look at, somewhere between 50% and 70% of the features in a typical software product are never used. Now, a portion of those features are built in the hope that they will never be needed—these are often the disaster recovery and security protection features which hopefully won't be exercised. However these do NOT account for half of the work in a typical product. Surely it will be better to stop work rather than build features which no one will ever use in the wild.
The Shape of a Healthy Backlog
A backlog should not just be a list of hundreds of user stories waiting to be delivered—that approach simply results in lengthy wait times for individual stories to be delivered, a large queue of work which becomes a bottleneck and source of waste.
Once an item has been added to a backlog there is tendency for it to take on a life of its own (no matter how small or large it is); someone who matters wants it to be included in the delivered product and is prepared to argue for it whenever it gets looked at in a grooming or forward planning session. The “someone who matters” could be a value manager, product owner, a technical member of the team, a subject matter expert, or any other interested party.
We know that one of the benefits of using an agile approach is the ability to move items in and out of the backlog easily, which is a great capability enabling us to ensure that the product we build meets the customers’ needs effectively through always focusing on the next most important piece of business value.
The normal, and generally correct, approach is for the value manager to work with the team to produce a prioritized backlog with clarity on the high priority items and accepted uncertainty in the items which are further away
The stories which come out of the bottom of the grinder are small enough for the team to deliver using their agile development practices, ideally they should be fully implementable (as per the agreed definition of done) in half an iteration or less—the smaller our stories when they are being implemented the better our ability to predict and plan work.
For more on the definition of done, see: http://blog.softed.com/2011/08/26/defining-done-in-an-agile-project/
Of Babies and Bathwater
Another misconception that plagues agile projects is the idea that everything is new—we no longer use the analysis techniques and tools that have been used in the past because in some way they are “not agile.” This is often a result of misunderstanding the second value statement from the agile manifesto:
- We value working software over comprehensive documentation
The language of the manifesto was very carefully crafted, and the word in the middle of that phrase is “over,” not “instead of.”
We can and should still make use of those analysis tools which will add clarity and value to uncovering the real business needs without adding waste to the process. Not everything old is bad.
Some Tools and Techniques
Value Stream Mapping
Value stream mapping (VSM) is a technique to help identify the steps in a process and to focus on solving the right problem. It looks at elements in a process to identify waste—anything that causes delay, requires double handling, or results in rework, could result in mistakes being made or in any other way detracts from delivering value to the customer of the process.
VSM uses a fairly extreme definition of the word “waste” and you might be surprised or shocked to learn how much of your daily work tasks are considered waste when looking at them through a VSM lens. Another way of looking at it is to ask the question “would the customer for this value stream be happy to pay for the work I'm currently doing?” If you think the answer is yes (i.e. the customer can see how the work being done is valuable to them), then the work is probably a value add to the customer: otherwise, it's waste.
The whiteboard snapshot of the value stream map shown here is a great example of how simple and quick this process should be.
- Identify extra steps, duplicates, delays, or waste
- Revise the process to achieve the outcome with less delay or dependencies
- Focus on outcome value not specific artifacts
- Does this simplify the feature?
- Above all, think lo-tech and quick!
Purpose Alignment Model
This model provides a way to decide what approach to take in addressing a business need based around the level of importance to the business that the outcomes will have.
Kent McDonald (2012) presents a detailed discussion of when and how to use this model on his website: http://www.beyondrequirements.com/purpose-based-alignment-model/
What it is
The purpose based alignment model, created by Niel Nickolaisen, is a method for aligning business decisions and process and feature designs around purpose. The purpose of some decisions and designs is to differentiate the organization in the market; the purpose of most other decisions is to achieve and maintain parity with the market. Those activities that do not require operational excellence either necessitate finding a partner to achieve differentiation or do not deserve much attention.
In practice, purpose alignment generates immediately usable, pragmatic decision filters that you can cascade through the organization to improve decisions and designs.
The quadrants explained:
The purpose of the differentiating activities is to excel. Because you use these activities to gain market share and to create and maintain a sustainable competitive advantage in the marketplace, you want to perform these activities better than anyone else. For your organization, these activities are or should be its claim to fame. These activities link directly to your strategy. You should be careful to not under-invest in these activities, as that would weaken your market position. In fact, you should focus your creativity on these processes. What are the differentiating activities for your organization? It depends. It depends on the specific things you do to create sustainable competitive advantage.
The purpose of the parity activities is to achieve and maintain parity with the marketplace. Stated differently, your organization does not generate any competitive advantage if it performs these activities better than its competitors. However, because these activities are mission critical, you must ensure that you do not under-invest in or perform these activities poorly. These activities are ideal candidates for simplification and streamlining, because complexity implies that you are likely over-investing. While there might be value in performing the differentiating activities in a unique way, performing the parity activities in a unique way will not generate value and could actually decrease the organization's value if your over-investment in parity processes limits the resources you can apply to differentiating processes.
Some activities are not mission critical (for your organization) but can nevertheless differentiate the organization in the marketplace. The way to exploit these activities—and generate increased market share—is to find a partner for whom those activities are differentiating and combine efforts to create this differentiation.
Finally, some business activities are neither mission critical nor market differentiating. The goal for these activities is to perform them as little as possible. We refer to these activities as the “who cares” processes. Because these activities are neither market differentiating nor mission critical, you should spend as little time and attention as possible on them. Who really cares?
Expressing Project Scope and Goals
The Focusing Question or Elevator Statement
A one or two sentence statement that conveys the goals and objectives of the project.
The “elevator statement” is something that will enable any team member to explain the purpose of the project in the time it takes to ride between floors in an elevator (imagine you get into the elevator with the CEO of your company and are asked to explain what the project is you are working on before the elevator gets to their floor).
During the workshop this is one of the first things that should be produced, and written up for all to read—it provides focus for the rest of the workshop activities.
The Vision Box
A vision box presents the features and benefits of the project as a box of cereal—the front has a name and branding, along with a list of the key benefits the product will convey to its buyers (the customers who will eventually use the product, be they internal to the organization or real paying customers). The back of the box contains operating instructions (high level design decisions) and a list of the key features the product will have.
Building a vision box is a creative activity that helps team members articulate what they are thinking about. It can be useful to break into smaller groups and have the groups each build a vision box that they then “sell” to the remainder of the team. After the separate presentations a shared vision box should be produced that conveys the ideas of the whole team.
Business Benefits Matrix
A business benefits matrix is a simple matrix that articulates the strategic value that the product is intended to provide. The matrix looks like the following table:
|Increase Revenue||(25% revenue increase within 12 months of launch)|
|Improve Service||(Increase customer satisfaction rating by 20% based on quarterly satisfaction survey results)|
|(Other)||(Reduce staff turnover in call center because of customer satisfaction)|
The goals of the project are expressed against the strategic drivers; there should only be one primary driver and there might be a number of secondary or tertiary goals. Where there is more than one goal in a column, they need to be ranked to avoid the “everything's critical” conflict.
Preparing this as a group activity helps the team to understand the clear and explicit focus for the project.
A slider is a tool for showing the priorities for the team across multiple dimensions.
The sliders range from fully on to fully off—if an element is on, then it will be the strongest factor that drives the decision making as the project continues. No two sliders can be set at the same level, and the more sliders there are on the “on” side of the grid, the higher the risk of catastrophic failure this project accepts. Where there is little leeway in the project sliders then the choice becomes deliver everything or deliver nothing, whereas more leeway allows for partial delivery that contributes to the organization's goals.
Rob Thomsett describes the slider tool in his book Radical Project Management.
Mike Cohn (2014) provides an online tool for setting sliders on his website: www.mountaingoatsoftware.com/tools/project-success
The “in/out list” is a simple tool that conveys clearly what will be done as part of this project, what will not be done, and where there is uncertainty about deliverables.
Where a topic is “in,” the project team is responsible for delivery of this component.
Where something is explicitly out of scope, the team will not spend any time or effort on this component. If an “out” topic is something that the broader program of work is dependent on, then it is important that the responsibility for undertaking this work is clearly defined, the project stream and person taking responsibility for ensuring this is delivered.
Where there is uncertainty about a topic being in scope or not then it goes into the “undecided” area. The team will not work on this piece and the product owner or project manager needs to investigate further to identify if the piece of work is in or out of scope.
This tool is also explained in Radical Project Management (2001), by Rob Thomsett.
This should convey the level of uncertainty surrounding the estimates of both cost and benefit the organization will get from the project. Early in the project, the costs will have a large cone of uncertainty and as the project progresses, this will get narrower and narrower. It is likely that the benefits also have a wide range of uncertainty. Uncertainty in both costs and benefits is not necessarily a problem on a project provided the range is correct. Both costs and benefits should be shown at three levels—optimistic, likely and pessimistic. For example:
The figure in each cell is the net of benefit minus the cost.
This project should be considered high risk, as there is a distinct possibility that the organization will lose money on it. That there might be other drivers which warrant the investment and the reward profile if things go well is significant.
Undertaking cost/benefit analysis on a project is primarily a management level responsibility, but the financial goals and drivers should be shared with the team.
Articulate the Vision
These tools can help teams gain a clear understanding of the goals and objectives that have driven the selection of this project to be worked on.
Preparing the product vision is a very important starting point for the project. This provides the focus for the work the team will undertake as the project continues. The wallware1 artifacts produced during the workshop(s) should form part of the team environment so anyone working on the project can see at a glance the project drivers and goals. It may also be valuable to produce a formal document that summarizes the product vision. Remember that the value lies only partly in the document but in the shared understanding that the team has achieved in producing the vision.
If the team who will work on the product is distributed, it should be brought together for the production of the product vision—this will help to create a “one team” culture and help with the ongoing communication when they are dispersed.
Team members who join after the vision has been created need to be walked through the project charter by someone who was present at the workshop(s) to help them understand the drivers behind the work being undertaken.
If during the execution of the project the environment changes and the vision is no longer achievable or the organization goals/drivers change such that the project no longer delivers on them then the project should be stopped and reassessed. Changes in the product vision are often evidence of massive change in the organization ecosystem.
The Kano model offers some insight into the product attributes that are perceived to be important to customers. The purpose of the tool is to support product specification and discussion through better development of team understanding. Kano's model focuses on differentiating product features, as opposed to focusing initially on customer needs.
According to the Kano model (developed by Dr. Noriaki Kano in the 1980s), a product or service can have three types of attributes (or properties):
- Basic Needs: Which customers expect to be present in a product
- Performance Attributes: Which are not absolutely necessary, but which are known about and increase the customer's enjoyment of the product
- Delighters: Which customers don't even know they want, but are delighted when they find them
Basic needs affect customers’ satisfaction with the product or service by their absence: If they're not present, customers are dissatisfied. And even if they're present, if no other attributes are present, customers aren't particularly happy (you can see this as the bottom curve on the graph above).
To use Kano model analysis, follow these steps:
- Brainstorm all of the possible features and attributes of your product or service, and everything you can do to please your customers.
- Classify these as “Basic,” “Performance,” “Delighters,” and “Not Relevant.”
- Make sure your product or service has all appropriate basic attributes. If necessary, cut out performance attributes so that you can get these—you're going nowhere fast if these aren't present.
- Where possible, cut out attributes that are Not Relevant.
- Look at the Delighters, and think how you can build some of these into your product or service. Again if necessary, cut some performance attributes, so that you can afford your Delighters.
- Select appropriate performance attributes so that you can deliver a product or service at a price the customer is prepared to pay, while still maintaining a good profit margin.
This paper has examined the role of the product owner and shown that while product ownership is a crucial and critical aspect of product delivery, the “single wringable neck” individual product owner who has all the skill and knowledge needed to make all the important decisions about priority and business value is not attainable except in a very small subset of project types.
The majority of projects undertaken today are complicated or complex, falling into areas where innovation is needed, where the problem and the solution are both uncertain, and in which a single individual cannot know everything, nor should they be expected to.
Product ownership truly is a team sport—it requires a multi-skilled group that collaborate and work together to identify what constitutes value in each aspect of the initiative, and then constantly refines and adapts the product backlog based on the emergent learning and discovery that happens as work continues. There is no “one-size-fits-all” approach; each initiative has a different context in which it is being undertaken—the business drivers, customer needs, local environment, and team makeup are unique and need a unique approach to the delivery process.
Selecting the right initiative to fund, and identifying and refining the product backlog is a skill that draws on techniques which have been around for a long time in the creative industries, and requires some new ways of thinking. Knowing when to stop is one of the hardest and most important aspects of truly maximizing value delivery.
Adolph, S. (2014). Agile BA in Practice: Using Cadence to Leave Things to the Last Responsible Moment. Accessed from http://www.developmentknowledge.com/index.php/blog/141-agile-ba-in-practice-using-cadence-to-leave-things-to-the-last-responsible-moment 21 July 2014
Ambler, S. (2014). Generalizing specialists: Improving your IT career skills. Retrieved on July 21, 2014 from http://www.agilemodeling.com/essays/generalizingSpecialists.htm
Andrea, J. (2005, September). If the shoe doesn't fit—Agile requirements for stepsister projects. Better Software Magazine. Retrieved on July 21, 2014 http://www.cmcrossroads.com/sites/default/files/magazine/file/2012/XDD9690filelistfilename1_0.pdf
Beck, K., Beedle, M., van Bennekem, A., Cockburn, A., Cunningham, W., Fowler, M., … Thomas, D. (2001). Manifesto for agile software development. Retrieved on July 21, 2014 from http://agilemanifesto.org
Cockburn, Alistair. (1999). A Methodology per project. Accessed from http://alistair.cockburn.us/Methodology+per+project/v/slim 21 July 2014
Cohn, M. (2014). Project success sliders. Mountain Goat Software. Retrieved from http://www.mountaingoatsoftware.com/tools/project-success
Hastie, S. (2014, June). Knowing when to stop—Trim that tail ruthlessly. Software Education. Retrieved on July 21, 2014 from http://blog.softed.com/2014/07/07/knowing-when-to-stop-%E2%80%93-trim-that-tail-ruthlessly/
Kruchten, P. (2011, September 30). The Frog and the octopus—A conceptual model of software development. Retrieved on July 21, 2014 from http://pkruchten.files.wordpress.com/2012/07/kruchten-2011-frogoctopus.pdf
McDonald, K. (2012, February 18). Purpose based alignment model. Beyond Requirements. Retrieved from http://www.beyondrequirements.com/purpose-based-alignment-model/
Schwaber, K., & Sutherland, J. (2013). The Scrum guide. Retrieved on July 21, 2014 from http://www.scrumguides.org/
Software Education. (2014). Agile Product Ownership course, Wellington, New Zealand. Self Published
Thomsett, R. (2001). Radical project management. Upper Saddle River, NJ: Prentice Hall.
Dynamic Systems Development Methodology. http://www.dsdm.org/ - accessed 21 July 2014
Wells, D. (2009). Extreme programming: A gentle introduction. Retrieved on July 21, 2014 from http://www.extremeprogramming.org/
Construx. http://www.construx.com/Page.aspx?hid=1648 accessed 21 July 2014
1 Wallware refers to flipcharts, graphs, story cards, and other artifacts that are prominently displayed in and around the team space; they provide a visual record of the project, serving as reminders of key decisions and visible to anyone who has an interest in the project. Other commonly used terms are information radiators and big visible charts.
© 2014, Shane Hastie, Software Education
Originally published as a part of the 2014 PMI Global Congress Proceedings – Phoenix, Arizona, USA