Too often the whole system is not considered when measuring success.
Wikipedia has the following definition for "business value": "Business value expands concept of value of the firm beyond economic value (also known as economic profit, economic value added, and shareholder value) to include other forms of value such as employee value, customer value, supplier value, channel partner value, alliance partner value, managerial value, and societal value. Many of these forms of value are not directly measured in monetary terms." Is 'Business value' something your Agile process has to take account of, or is that something only the 'customer value’ needs to worry about?
Wikipedia has the following definition for "business value": "Business value expands concept of value of the firm beyond economic value (also known as economic profit, economic value added, and shareholder value) to include other forms of value such as employee value, customer value, supplier value, channel partner value, alliance partner value, managerial value, and societal value. Many of these forms of value are not directly measured in monetary terms." Is 'Business value' something your Agile process has to take account of, or is that something only the 'customer value’ needs to worry about?
In the above definition, "customer value" is just one part of the total business value.The Agile Manifesto states: "Our highest priority is to satisfy the customer through the early and continuous delivery of valuable software." Agile gives you a set of very loose values and rules that you should embrace. If “Customer collaboration over contract negotiation” (Agile Manifesto), does not tell you that the team needs to collaborate with the customer to find the value, then you need to read this again and think about it. However, that "customer value" and "business value" can sometimes be in conflict. One should also distinguish between the organization's own business ("what is best for the company I am working for?") compared to what is best for your organization's clients ("what is best for the end user getting the software we are making?"). The two are not always the same. Notice that the same distinction is still valid even if the "customer" is an internal one. And there is certainly a need to understand the business, and value comes along with that understanding. The process does have to account for the health of the Agile team, as well as the business, at least in some measure. Considering that ask this: a business with no value has what level of health?
Agile is not the place you live in, but the place you go back to. That is really thinking outside the box and if that thinking takes you too far, you have where to go back. That is why Agile is not really something that gives the answers, it is more something that continues to shape the right questions and make incremental improvement. Self-organization without alignment can lead to chaos, and without an understanding of those value-driven outcomes, alignment is pretty hard to come by. Also, those strategic intents cannot be detailed and fixed. As feedback is gathered, values will shift. Creating an organization that measures the right things and continually adjusts to shifting context will create optimal value-delivery.
Too often the whole system is not considered when measuring success. Ask your teams to define business value in terms of outcomes they're helping the organization & customer to achieve and you will often get very tactical responses. To preserve "business value," you need to have a very clear idea of the "product" - its life cycle, the overall "value proposition," where it fits into the overall "product portfolio", the wider competitive landscape and your price/business model. User stories that don't align well with these wider strategies need to be considered very carefully before being put into the backlog. A good example of a business value study is offered by an enterprise artifact called a Value Stream Map. A Value Stream Map is a bigger picture requirements analysis. Everyone's doing their best so focusing on completion of technical implementation details can make it hard for you to see that some of the work being done are not necessary. One of the benefits of mapping things is making visible the work being done and it's impact on the whole system. Since what you produce (software) is invisible, it's easy to ignore the very real and significant carrying costs of excess unused or unneeded code.
Not all business value is directly related to ROI, at least not in the near term. Some features may deliver little to no ROI, directly, but are wonderful marketing tools. Identify stories on the basis of their "strategic" or "tactical" value, as opposed to the "business" or "customer" value components. "Strategic" value items will drive value for current users, however, they also aim to generate a unique value that sets the product apart from the competition. These stories are more proactive, targeting where the market *will be* by the time the feature is completed. They are also more aggressive, as the goal tends to be to grow or capture market share, potentially through product switching. However, business value is mostly gained by the processes and capabilities that are enabled through the glue of several products working together, rather than in user stories for a certain product. You need transparency and alignment between the strategic level of the business and the operational level of the agile teams to be able to achieve an agile enterprise at scale.
In PM level, Agile methodologies are dealing primarily with "delivery" of (user-identified) value in incremental stages within a single product. Incremental improvements are just as vulnerable to "scope creep" and "feature creep" as any other project; while conventionally this impacts on the cost and time frame for project delivery, it can compromise the business value and lead to a more strategic failure. Typically "tactical" value items impact primarily on existing users and serve to drive business value by protecting on-going revenues/ relationships - these are mostly classic agile "customer value." These stories tend to be highly reactive and serve mainly to defend existing business value that has already been created. In the absence of technology or workflow-driven roadmap identifying and ranking the core organizational benefits that the client/users are after is one approach to simplifying prioritization and how to communicate it within the organization as a whole.
Agile needs to be the philosophy to perceive multidimensional business values. Making the effort at the leadership and portfolio level to quantify value in terms of both strategic value and tactical value; direct revenue and indirect (mission/vision/values) terms is the first step to crafting high-level strategic intents. And at the tactical level, follow Agile principles to deliver customer value is the core of Agile management and methodology.
2 comments:
Great blog. All posts have something to learn. Your work is very good and I appreciate you and hopping for some more informative posts. UCAT Abstract Reasoning Questions
Poker dapat dikatakan selaku salah satu permainan online yang sangat populer serta sangat banyak digemari. Poker online sendiri ialah game yang memakai kartu remi, yang terdiri dari 52 kartu. https://www.calibetandroid.com/ Bila mau menang dalam game ini, kalian wajib dapat memperoleh 5 campuran kartu paling tinggi ataupun terbaik.
Kunci dari game poker merupakan kalian wajib memiliki mental, naluri ataupun insting yang tajam dalam membaca game. Seperti itu keseruan dari game poker, yang membuat game ini banyak disukai.
Post a Comment