Skip to main content

Posts

Showing posts from November, 2015

Product Backlog + Process Backlog = Success!

Flexibility and agility are key to success and business performance.  Many Service providers have adopted Agile methods to ensure that they can meet demand for increasing changes in business requirements.  Product Backlogs are common and are generally understood; but what about Process Backlogs? Product Backlog – In the “Scrum Guide” Ken Schwaber and Jeff Sutherland describe the Product Backlog as an ordered list of everything that might be needed in the product.  It is the single source of requirements for changes to be made to the product. The Product Owner is responsible for the Product Backlog, including its content, availability, and ordering.  A Product Backlog is never complete. The earliest development of it only lays out the initially known and best-understood requirements. The Product Backlog evolves as the product and the environment in which it will be used evolves. The Product Backlog is dynamic; it constantly changes to identify what the product needs to be app

Agile – My Product Backlog is Out of Control!

If a product backlog is growing faster than you deploy, if it cannot be prioritized properly, and business outcomes suffer, are your “Agile” efforts really working?   Agile software development is a group of software development methods in which requirements and solutions evolve through collaboration between self-organizing, cross-functional teams . It promotes adaptive planning, evolutionary development, early delivery, continuous improvement, and encourages rapid and flexible response to change. A broken product backlog is only one of many symptoms that something is broken. If there are bottlenecks in change, delivery and deployment than what real value can evolutionary and faster development bring to the business?  It is time to consider “Agile Service Management”. Agile Service Management ensures that agile principles and methods go beyond software development t o ensure the product backlog is in control and that we, as service providers, can meet the s

Change Proposals

When an organization is planning on a major change that will incur significant cost, risk, time and engagement of resources along with organizational impact, it is best practice to initiate this activity through the Service Portfolio process.  Before this new or significantly changed service is chartered, it is important that it be reviewed for how it may impact the short, medium and long term support of other services currently being delivered, the pool of limited resources that will be utilized for this undertaking and on the change schedule itself. The Change Proposal is used to communicate a high level description of the change and is normally submitted to Change Management for authorization.  Authorization, however, is not an approval for implementation, but is a measure to allow the service to be chartered so design activity on the service can begin. In some cases the proposal may be created by someone other than Portfolio Management, such as the PMO or SMO. This high le