In most large- or mid-size organizations you could define at least three tiers of management. Upper- and middle management and an operational level. In an Agile context we’d rather speak of portfolio, initiative and team levels. And we also strive for transparency and synchronization between those levels, rather than information handed over between individuals performing at each level. That transparency is exemplified with the cog wheels representing each layer in the picture below. Agile Business Consortium (ABC) have frameworks and products that supports all these layers and the interaction in between.
Starting at the upper level, Agile Portfolio Management (AgilePfM) supports a value-based approach to portfolio management.
Traditional portfolio management is often set up to demonstrate how accurate estimates are in terms of time and cost, instead of demonstrating the delivery of value.
Which in its turn is based on an underlying assumption that all initiatives already within the portfolio are the right things to be doing. As a result, portfolio management is often perceived as a passive reporting tool rather than an active driver to support leadership teams in delivering the strategy and ensuring value delivery.
As you might guess, AgilePfM aims to mitigate the shortcomings of any traditional portfolio management. In fact, most of the challenges we face and the ABC aim to solve with their tools and practices, is about business change and strategy, actually business agility. Business agility at scale could be defined as coordinating a portfolio of programmes, projects and smaller change initiatives to make business strategy a reality.
Initiatives within a portfolio can be in different states of maturity. Within AgilePfM this is exemplified using an hourglass as seen in the drawing. At the top of the hourglass you’ll find initiatives that are immature. When we’re moving to the near-term horizon, initiatives become mature enough to be executed. Initiatives that are in the Ready or Current state is said to be within the “Portfolio Innovation Hub”.
The innovation hub brings together challenges and constraints, competent and empowered people, and concepts and creative thinking into an autonomous, purposeful whole focused on achieving what the business needs to achieve, by when it needs to achieve it.
At the bottom of the hourglass we find the initiatives that are completed, and value has been delivered to the organisation.
Projects and programmes
Any initiative in the innovation hub is ready to be implemented as a program and/or a project. Here the ABC provide the Agile Programme Management (AgilePgM) and Agile Project Management (AgilePM) frameworks. They’re actually quite similar in its nature. They’re both built upon Agile principles that is well aligned with the Agile Manifesto principles. Both AgilePgM and AgilePM have similar life cycle models, having feasibility study, foundation establishment and solution evolution. But AgilePgM isn’t just an “umbrella” for several projects and operational activities. Whilst AgilePM is focussed on evolution and delivery of the solution itself, AgilePgM has its primary focus on capability evolution and enablement. That said, any AgilePM solution delivery increment could of course be seen as a programme capability enablement. To be honest, business capabilities have become a kind of buzzword within the industry. The best definition in short is that a capability is an ability for an organisation to deliver benefit. A capability normally consists of a few major organisational components such as process, information, people, IT-assets and other resources.
Capabilities will be enabled in a series of increments that ensure benefits are realised as early as possible. And then using that experience of delivery to update the programme plans for the future. This guidance will refer to such an increment as a tranche, which is a new notion defined within AgilePgM. A business capability often evolves regardless of any certain project, or rather as a result of efforts in several ongoing projects. The structure of the program follows the capability evolution, rather than managing the containing projects. AgilePgM doesn’t mandate any specific Agile method for running projects and initiatives but provides a framework where any method can be incorporated at the project level.
AgilePM of course has its focus on the certain project. What differs AgilePM from any traditional project management framework? Well, it is an Agile approach that encourages detail to emerge over time. Given the likelihood that business requirements will change over time, the effort spent on detailed up-front work is avoided.
Solutions built using AgilePM approach address the current and imminent needs of the business. As a result, solutions are more likely to have a better fit with the true business need and are easier to integrate into existing and emerging business processes.
So, what differs AgilePM from most other Agile approaches? AgilePM establishes firm foundations for the project to be agreed at an early stage, which allows businesses to understand the scope and fundamental characteristics of the proposed solution. Clarifying and agreeing the foundations from the combined perspectives of business, solution and management early in the project is essential for any larger corporate organisation.
Roles and team agility
AgilePM also describes a broader set of roles than most Agile approaches giving it a better fit with most corporate environments without compromising agility. Speaking of roles, the AgilePM role model is present in the drawing. This approach defines both project level and team level roles, which in its turn describes that AgilePM covers both the initiative- and team tiers in the overall organisational big picture.
When we zoom in to the different roles in the model, we could experience roles that cover the combined perspectives of business, solution and management earlier mentioned. The business analyst role is an important role, that covers both the business and technical solution perspectives, as well as being both a project and team level role. The business analyst role is the only role within the set of frameworks that has its own course and certification, the AgileBA.
AgilePM is easily combined with other popular Agile frameworks, such as for instance Scrum. A common setup is to use the AgilePM project level roles, artefacts and products, while using the Scrum lifecycle model and team level roles and practices.