AGILE IN ACTION

At Agile 2008, Luke Hohmann from Enthiosys talked about converting business value into actual money. Luke said prioritizing the backlog by ROI doesn't work and suggested developing attributes for backlog prioritization that drive profitable growth. In terms of what we've been doing at one of our clients using throughput accounting this means increasing revenue without significantly increasing investment and decreasing costs without impacting throughput (or the capacity to deliver).

If you're an business analyst and you're performing the role of Product Owner on an agile team, focus on:

The Product Owner needs a blend of the skills usually separated by traditional roles, should have empathy with the customers and and should have some knowledge of how software is developed and deployed. Product Owner Skills Originally uploaded by sjb140470 Product Management Synthesises the needs of the customers and the various stakeholders. Performs competitive research and analysis. Assists with product marketing strategy and devises pricing model. Conducts acceptance tests. Demonstrates the product to customers. Collects customer feedback and transforms it into new features or enhancements. Project Management Responsible for the business value delivered by the team. Helps the team plan the content of each iteration given costs (estimates) and risks. Provides feedback and makes decisions that steer the team based on what's delivered every iteration. Communicates progress to the Product Sponsor and stakeholders. Programme Management Why not put the Product Owner in charge of the budget? After all, he is responsible for maximising return on investment in every iteration. Business Analyst Articulates the product vision and business strategy to the team and defines goals that realise the product vision. Writes and evolves user stories to a suitable level of detail given their position in the Product Backlog. Communicates the details of the user stories so they can be captured as acceptance tests. Prioritises user stories in the Product Backlog by business value. Manages the Product Backlog in response to changes. Business Intelligence Collect information about the product to help make better decisions relating to future functionality and business value.

On the first day of the Agile Business Conference , Roman Pichler talked about the Role of the Agile Product Owner. It was a succinct presentation of the basic responsibilities of Scrum's Product Owner role. Roman conveyed the likelihood that the Product Owner would not be available all of the time (he mentioned hot-desking) nor be colocated with the team. He showed a hypothetical calendar day for a Product Owner that had an hour blocked out in the morning dedicated to collaboration with the team. This set-up is a reality for many companies, indeed it's probably the accepted norm. That's bad! The Product Owner should be a full-time member of the team and be colocated with the team. If he's not then, in my opinion, the team's agility is compromised . The team cannot possibly achieve all that they are capable of achieving on the project. Time-boxing interaction between the team and the Product Owner constrains collaboration with the business. In my mind, collaboration is not something that you turn on and off depending on the time of day. It's a hive of conversation and activity that permeates the environment generating hustle . If you want to achieve hyper-productivity, one of the things you need to be able to do is talk with the Product Owner, as and when you need to, and to demonstrate vertical slices of a user story many times a day to get feedback. If the project is vital to the business, then the company can always find a way to provide a full-time and colocated Product Owner. If they say they can't, it really means they won't. Quite simply, they're not prepared to do what is necessary to achieve it, and frankly, if they're not going to take the project seriously why should you? Usually, the obstacle relates to a silo'ed organisation where departments are arranged by role rather than product stream. Hardly an insurmountable obstacle ... really.

I've talked about being customer-driven : See everything from the customer point of view first, understand value from the customers' perspective, ask what they want next and deliver it to them quickly. In the charter , express the product vision in customer terms. Start to create a product backlog by first capturing the product sponsor's strategy as goals expressed in customer terms. Organise the goals as a tree with the vision at the root. Break goals down into smaller goals (and be careful not to go too far so that strategy becomes tactics). The goal tree is a strategic planning tool but, just as importantly, you should use it as an execution tool with the goals encapsulating the voice of the customer. The product owner uses the goal tree as a roadmap to achieve the vision (periodically reviewing it with the product sponsor to ensure it continues to steer a true course). Making tactical decisions and creating tactical goals for the release and iteration planning games the product owner steers the development effort to deliver the highest value functionality to customers and realise maximum return on investment for the business.

Being an effective Product Owner is a full-time job and managing the Product Backlog is a constant activity. It's not as trivial as it might sound. The Product Owner is responsible for the features that are delivered. The team is responsible for the quality delivered. It's the Product Owner's responsibility to maximise the return on investment in every release and every iteration. The Product Owner needs to look after the Product Backlog because their decisions and actions govern the flow of value to the customers by effectively steering the efforts of the team. And to compete on the basis of speed a continuous flow of valuable features to the customers must be sustained. Managing the Product Backlog, which is a dynamic list of evolving user stories , is often dismissed as simply routine with insufficient time and attention dedicated to the activity. Consequently focus is lost resulting in a divergence from the project vision, the coherence of the backlog dissipates, prioritisation becomes based on fancy rather than on feedback, return on investment diminishes, the team stalls and is unable to sustain creation of value at a steady velocity, and ultimately the customers become dissatisfied because they're not receiving the features they deem to be valuable. Managing the Product Backlog requires constant care and attention. It requires diligence, discipline, awareness and business acumen , and decisiveness. It takes business marksmanship to realise the vision for the product by hitting each goal in turn and generating the biggest bang for the buck. Before shooting, a sniper will first assess a number of criteria - distance and elevation, weather conditions, etc - while constantly surveying his surroundings. In a similar fashion, the Product Owner has to be aware of a number of factors making up the goal - value, cost, risk, priority, etc - while keeping an eye on the big picture. The difference is the Product Owner has many opportunities to assess and re-aim en route. It's fire and aim, aim again, and keep re-aiming until you hit the target. First fire in the general direction of the vision. Then repeatedly re-aim at goals that move you towards that vision, iteration by iteration, all the while keeping an eye on the big picture just in case the vision changes in response to the market, competitors, or modified business objectives. The Product Owner must be continuously engaged with the team, collaborating and providing feedback as user stories are being developed, and he must be prepared to accept or reject the features delivered at the iteration review. The Product Owner must always be looking ahead to coming iterations and beyond, and planning adaptively to evolve goals and evolve the user stories that satisfy them. To be able to look ahead with sufficient clarity, the Product Owner needs to engage, on a regular basis, with the sponsor, key stakeholders, and other executives to preserve strategic direction and maintain visibility. This involves a demonstration of the goals achieved together with an appraisal of the quantified value delivered per investment period (iteration or release), and discussing coming goals, while obtaining feedback, to ensure alignment with the vision and business objectives. In effect, the Product Owner is empowered to pursue the strategic vision by defining and then steering by tactical iteration goals.

Agile projects demand real customer involvement. To be an effective on-site customer or Product Owner, you must either be a real customer, or be in a position to accurately represent the real customer. You must acknowledge the elevated status you hold and accept the responsibilities that accompany it (accepted responsibility). You must be a stakeholder and a fully integrated member of the team. You must be accessible and you must participate in the project proactively and continuously. You must recognize that through your actions - writing user stories and acceptance tests, prioritizing user stories by business value, deciding which user stories are developed next, providing rapid feedback, etc - you are effectively steering the project and are ultimately responsible for the business value that is delivered. As the driving force behind the project your presence must be visible, vocal and objective.