Agile на 11 000 сотрудников
Сбербанк существует на рынке уже 176 лет. В нём обслуживаются 140 млн физических лиц и 2 млн корпоративных клиентов. Компания представлена в 22 странах, в ней трудятся более 300 000 специалистов.
В банке продолжается масштабная реформа, одной из ключевых частей которой было переосмысление и изменение подхода к развитию продуктов.
Изучив опыт иностранных финансовых институтов и успешных компаний Кремниевой долины, банк построил собственную модель работы, учитывающую основные принципы гибкой разработки Agile — в банке её называют Sbergile.
«В отличие от технологических гигантов и финтех-компаний, Сбербанк не был компанией, функционирующей по принципам Agile, с самого начала. Однако мы продемонстрировали, что эту философию управления 21 века можно успешно внедрить. И пользоваться её преимуществами для компании и клиентов — независимо от количества работающих сотрудников.
Благодаря этому подходу мы значительно повысили скорость работы: например, путем сокращения времени вывода продукта на рынок до нескольких недель по сравнению с несколькими месяцами ранее. И смогли помочь нашим клиентам сохранить самый драгоценный ресурс — время» — Герман Греф, глава Сбербанка, на Давосском форуме 2018.
С тех пор топ-менеджмент лидирует Agile-трансформацию, а Сбербанк стремится стать ИТ-компанией с банковской лицензией. Продуктовая линейка должна быстро адаптироваться под запросы рынка.
Важно понимать, что Agile — не самоцель для банка, а всего лишь актуальный для сегодняшнего времени способ достижения целей и сохранения конкурентоспособности перед резко растущим числом финтех-стартапов.
Коллектив поделили на племена
Наблюдательный совет Сбербанка утвердил стратегию до 2020 года, в которой указаны ключевые приоритеты развития. Среди них — лучший клиентский опыт и экосистема, технологическое лидерство и люди нового качества в эффективных командах.
«Agile-трансформация в Сбербанке сконцентрирована в трех основных областях: удовлетворенность клиентов, продуктивность сотрудников и улучшение ключевых показателей: таких как время, необходимое для принятия решений, вывода продукта на рынок и поставки продукта клиентам» — Герман Греф.
Более 11 000 сотрудников, работающих в Sbergile, поделены на трайбы (от английского tribe — племя).
Каждый трайб — это агломерация команд, объединенных вокруг какой-то общей бизнес-цели, например, развития карточных продуктов.
И «карточные» в данном случае — условное обозначение, потому что в зону ответственности этого направления входят любые способы оплаты, включая эквайринг, смартфоны, NFC-кольца и другие.
Цели каждого трайба вытекают из стратегии развития банка и формируются лидерами трайбов при участии топ-менеджмента банка.
Каждый квартал кураторы трайбов вместе с лидерами трайбов обсуждают цели на ближайшие три месяца.
На этой же встрече лидеры трайбов синхронизируются между собой, обсуждают результаты предыдущего квартала и планы на следующий.
После этого команды декомпозируют эти цели на конкретные задачи в бэклоге и делят на спринты (такт работы команды, в ходе которого создаётся новая версия продукта).
Примеры трайбов, в каждом из которых работает от сотни до нескольких сотен человек (сейчас более 20 трайбов): «Эквайринг и банковские карты», «Платежи и переводы», «Занять и сберегать» — названия говорят сами за себя, Digital business Platform — «Сбербанк Онлайн», веб- и мобильное приложение для различных устройств.
Это одновременно и самостоятельные продукты, и канал для других продуктов.
Внедрение гибкой разработки — это непрекращающийся эксперимент.
Разные трайбы находятся в разной стадии зрелости с точки зрения использования Agile-практик.
Кто-то в стадии формирования и перехода, а кто-то уже полностью работает в логике Agile.
Племена состоят из команд
А команды, в свою очередь, из специалистов. В каждой команде работает от 9 до 12 человек, которые в разных пропорциях делятся на категории — бизнес и ИТ.
Прямая коммуникация между ними сама по себе ускоряет работу.
Но объединение разработчиков и бизнеса — недостаточное условие для повышения скорости и качества разработки.
Все сотрудники, переходящие на систему гибкой разработки, проходят обязательное обучение по специальной программе «Основы Sbergile», которую проводят Agile-коучи.
После этого коучи запускают команды и сопровождают их в дальнейшем. На данный момент в Сбербанке на постоянной основе работают более 60 коучей.
«Agile-коуч относительно новая профессия на рынке. В России не так много людей, которые имеют опыт работы в этой роли. Поэтому в банке работают коучи с разным бэкграундом. Кто-то в прошлом скрам-мастер, кто-то имеет большой опыт фасилитации и разработки.
Есть специалисты, которые работали тренерами в Кремниевой долине, спецы с продуктовой экспертизой. Часть коучей — это сотрудники банка, которые прошли специальный отбор и переквалифицировались на этапе перехода в Agile.
Коучи помогают командам настраивать церемонии, поддерживать эффективность, двигаясь к своей цели, решать конфликты, обращать внимание на сильные и слабые стороны, замедляющие обстоятельства, определять, где болит и как это вылечить и так далее».
Все встречаются на церемониях
Команды могут отличаться друг от друга в зависимости от целей и продукта, но в целом все играют по одинаковым правилам.
Эти правила — в том числе обязательные для всех команд церемонии — дисциплинируют и помогают командам двигаться быстрее:
Планирование спринта. Команда вместе с владельцем продукта расставляет приоритеты, формирует бэклог, чтобы через две недели показать результат.
Ежедневный стендап. Команда обсуждает планы на день. Каждый участник отвечает на три вопроса:
1. Что я делал вчера для достижения цели спринта?
2. Что я буду делать сегодня?
3. С какими проблемами и препятствиями я столкнулся?
Демонстрация. Презентация результатов двухнедельного спринта, на которой команда собирает независимую обратную связь по своему MVP (Minimum Viable Product — минимальный жизнеспособный продукт).
На встрече присутствует лидер чаптера — человек, который контролирует работу специалистов одной области знаний в разных командах.
Продуктовая синхронизация. Синхронизация бэклогов команд (в том числе из разных трайбов), работающих над одним продуктом.
Проходит не реже, чем один раз в спринт. Помогает обеспечить целостность продуктов и сроков.
Ретроспектива. Команда с помощью коуча анализирует действия и решает, что нужно поменять в работе, чтобы быть эффективнее и двигаться быстрее.
Portfolio marketplace. Синхронизация команд и выявление взаимозависимостей на уровне трайба. Присутствуют владельцы продуктов, лидер трайба, лидеры чаптеров, коучи.
Квартальный обзор результатов трайбов. Синхронизация между трайбами, расставление приоритетов. Встречаются лидеры трайбов, руководители ИТ- и бизнес-подразделений.
Культура непрерывно подпитывается
Поделить людей на трайбы, поставить цели и организовать встречи для проверки результата — это только первая часть работы.
Сложнее и важнее — создать среду, в которой все участники процесса обогащают друг друга знаниями и проявляют инициативу.
Общая коммуникация строится через привычные каналы — новости, мероприятия, рассылки, видеоблог.
Внутри каждого трайба для общения выбирается та среда, которую выбирает коллектив.
«У каждого трайба свои особенности — они как отдельные субкультуры. Организовывают свои мероприятия, ездят вместе в горы, путешествуют.
Некоторые трайбы ежемесячно проводят тематические завтраки, например, «Кем я хотел быть в детстве». Это лишний повод пообщаться друг с другом и сблизиться.
Коммуникация строится не только линейно, то есть на уровне трайбов, но и между ними — люди объединяются в сообщества на почве личных и профессиональных интересов.
Такие сообщества называются «гильдиями», где люди, помимо общего досуга, делятся знаниями и обсуждают общие задачи.
Ежедневно в офисе проходят митапы на разные темы: от дизайна до блокчейна. Их инициируют и проводят сами сотрудники».
Пространство офиса подчинено культуре
Всё устроено так, чтобы люди как можно больше общались лично, обменивались знаниями, договаривались и быстрее принимали решения, а не тратили время на длинные совещания.
В офисе организовано множество мест под разные задачи: переговорки для быстрых разговоров стоя, места для концентрированной работы, коворкинги, многофункциональные зоны для церемоний.
У лидеров трайба нет собственных кабинетов — все они сидят вместе с командами.
Agile-словарь «Сбербанка»
Sbergile — это фреймворк для разработки и поддержки продуктов в Сбербанке, основанный на ценностях гибких подходов к разработке продукта.
Трайб — группа взаимосвязанных команд, сформированная вокруг определенного продукта или бизнес-цели, и отвечающая за бизнес-результат.
Команда — кроссфункциональная, совместно работающая группа специалистов, обладающая всеми навыками, инструментами и полномочиями для самостоятельной разработки продукта.
Чаптер — группа специалистов одной области компетенций.
Владелец продукта — участник команды, отвечающий за выпуск продукта, соответствующего потребностям клиента, для достижения целей банка, возложенных на трайб.
Определяет и приоритизирует требования в бэклоге команды, а также принимает требования (истории) как выполненные.
Участник команды — специалист, непосредственно участвующий в создании продукта команды в пределах своих компетенций.
Лидер трайба — сотрудник, отвечающий за управление продуктом или группой продуктов и достижение бизнес-целей этого трайба.
Отвечает за ключевые показатели эффективности трайба в зависимости от его задач (например, P&L, NPS, доля рынка, надежность систем (uptime, количество инцидентов) и так далее).
Agile-коуч — сотрудник, отвечающий за развитие Agile-подхода в организации.
Помогает командам проводить церемонии, устранять возникающие препятствия и решать межличностные и методологические конфликты.
Бэклог команды — приоритизированный владельцем продукта перечень всех требований к стриму трайба или программы, переданных в команду либо созданных внутри нее.
Спринт — такт работы команды, в ходе которого создаётся новая версия продукта. Жёстко фиксирован по времени в одну либо в две недели.
Релиз — выпуск готовой версии продуктов трайба.
Minimum Viable Product — минимальная первая версия продукта либо новой крупной функциональности в нём, внедряемая для ранней обратной связи от клиентов.
Agile Portfolio Management
How to bring agility at a global level with the help of Agile portfolio management.
- Back
- Back
- Back
- Back
- Back
- Back
- Back
- Back
- Back
Try the Best Project
Management Tool
for Remote Teams
There are so many posts and scientific materials about Agile portfolio management; however, the fundamental problems have yet to be resolved.
With the majority adopting Agile and an increasing desire to get Agile at scale , current project portfolio management (PPM) practices are becoming more challenging than ever.
In this article, we define what Agile portfolio management is, share its common rules and practices, and offer reliable Agile portfolio management tools that will help you to succeed.
What Is Agile Portfolio Management?
If you try to find an Agile portfolio management definition, you will probably find numerous results and variations. Google it and you’ll see.
Let’s say, Agile portfolio management is about how a particular company identifies, organizes, manages, and prioritizes different products. it helps you to optimize the value development in a manner that’s sustainable in the long run.
Agile portfolio management guarantees that the organization provides its customers with the best value for their investment. An effective portfolio manager understands and follows all Agile principles. He/she considers different factors needed to efficiently manage various projects and teams. In fact, Agile portfolio management helps businesses to respond more quickly to rapidly changing market conditions.
Agile means that you are continuously delivering value. On an enterprise-wide scale, working in accordance with the Agile methodology allows companies to anticipate and adapt to changes in real-time.
Can any company go full Agile all at once? Not really. However, agility can be introduced as part of the organizational journey. This transformative process allows businesses to adapt at their own pace. For example, it can start with static annual planning exercises and end up with a dynamic continuous planning process.
What Are the Goals of Agile Portfolio Management?
According to PMI (the Project Management Institute), there are some essential goals that project, program, and portfolio management should achieve:
- predictable delivery capacity
- the reduction of possible risks
- the ease to change direction
- fast feedback
However, team-level agility cannot be enough to reach end-to-end business agility.
The path to Agile working can be risky, as changing ways of working can affect the whole organization. It may confuse the PMO when too many approaches are applied, from the traditional approach to Kanban or Scrum. The role of a portfolio manager is to adapt to the changing business needs and support new ways of working.
Thanks to Agile teams working on more targeted and small releases, the risk associated with product delivery diminishes. And iterative feedback loops guarantee that the product is what clients really want.
With Agile portfolio management, you can introduce new ideas and changes and create customer-centric products.
PPM and Agile PPM
Some managers think being Agile means giving up control of project portfolio management (PPM). This is a misperception that is typically based on experience.
To analyze potential ROI in a project, the PMO has a highly structured process for consolidating and centralizing relevant data. You deal with allocated resources and assigned teams.
PPM demands rigor and many consider it as the opposite of Agile. Agile project portfolio management uses the same real-time data to prioritize work according to the business value.
Agile teams form around high-value products. They deliver in increments. Agile PPM arrives at similar goals as traditional project portfolio management but in an iterative way.
The List of Activities Associated with Disciplined Agile Portfolio Management
Here are the critical process factors to consider:
1. Defining potential value
A portfolio management team works in cooperation with a product management team to identify new ideas and products to develop. It is achieved through monitoring the business environment and competitors, obtaining feedback from the existing clients, and envisioning the future needs of your audience through brainstorming sessions and Agile modeling.
2. Considering potential endeavors
Your portfolio management team will need to invest time in understanding a potential endeavor. The business case can be considered as an endeavor when you make high-level guesses at the market potential or ROI. Additionally, the team can run a focus group or small experiment to better understand this.
3. Prioritizing the endeavors
Not many companies have enough budget to work. Therefore, you will need to prioritize potential endeavors and invest in those that look most important. While prioritizing, pay attention to business value, possible risks, due dates, and dependencies.
4. Managing portfolio budget
Agile portfolio managers need to work with finance to manage portfolio budgets.
Many companies often follow an annual budgeting process that leads to significant overhead and risk in their efforts. It is better to move away from project-based financing to funding stable teams.
5. Initiating endeavors
New product development may require the participation of a product team or a project team. If a product is radically new to your business, you may choose an exploratory approach where you first validate the market potential of the product via a range of learning experiments.
6. Financing endeavors
Financing endeavors include the initial funding for the new project and product teams and ongoing funding for construction, transition, and operation of solutions once they’ve been deployed. The funding process should be monitored regularly to be sure the money is spent wisely.
7. Planning capability
The team must have enough resources (people and finance) to fulfill its responsibilities. The right people with the right skills should be capable of doing the work and this will require coordination with your people management team.
8. Managing vendors
Another essential aspect of portfolio management is coordination with vendor management, especially when it comes to service vendors providing contractors, consultants, or outsourced development services.
Vendor management contains the awarding of contracts, monitoring in-progress contracts, identifying potential vendors, as well as ending contracts.
9. Managing portfolio
Portfolio governance is a path of the overall strategy, so someone should govern it, including in-progress development endeavors and all operational solutions.
What Are the Key Pillars of Agile Portfolio Management?
Agile companies should maintain transparency, continuously experiment to define whether a project is valuable, and align strategy with execution. These are the core pillars of Agile portfolio management.
1. Scaled transparency
The rapidly changing business environment today requires creating transparency in the portfolio and overall project management processes.
Detailed status reports provided by portfolio managers or project managers are traditionally important. However, this requires valuable time, and often the reports are reliant on flawed estimations.
Agile is focused on reaching a shared purpose for everyone to follow. Handy visual boards help portfolio managers easily capture ideas for many projects and create a shared understanding of what’s happening inside the portfolio. Agile also emphasizes high-level forecasting of project plans. It is about taking actual data into account and retaining the flexibility to update the plans based on new info.
2. Portfolio prioritization
Sometimes teams have numerous brilliant ideas but starting work on all of them can overload people and result in high inefficiencies. That’s why it is very important to learn how to prioritize accordingly and choose only the most valuable ones.
The concept of rapid experimentation is what helps in Agile. You can run small experiments to define whether a given project is worth pursuing. You will quickly gather data before rushing to make any big commitments.
3. Aligning strategy and execution
Achieving alignment between strategy and execution is another crucial pillar of Agile portfolio management. As you already know, the portfolio is the connecting part between those two. So, successful portfolio management requires that you have a way to align the highest business objectives with the project execution.
To do this, Agile preaches frequent feedback loops that can be applied globally and locally. It is about creating a network of short planning and learning cycles on various organizational levels so that you can review strategy, risks, and delivery capabilities.
5 Rules of Agile Portfolio Management
A portfolio contains groups of work under consideration that may be related or not and that aligns with investment strategies.
The active part of the portfolio is funded. And the work that is funded may have different names — product release, program, epic, initiative, etc.
There are 5 simple rules that can be used to collectively right-size a portfolio. Here they are:
- All work is strongly ranked. Artificially ranked work tells us about too many dependencies. Companies that give everything the highest priority cannot articulate real priorities.
- Operating on good enough data. At the stage of decision-making, you’ll probably have no detailed data for all portfolio items. Uncoordinated planning will point to external demand for artificial precision. Remember that certain levels of detail in one area do not necessitate expensive-to-obtain detail in other areas.
- Short-term capacity is fixed. It is quite difficult to hire and empower knowledge workers to influence the outcomes of portfolio management in 3-6 months. Of course, there are exclusions but they are far rarer than funding managers want to acknowledge.
- Every value-based delivery capability has a portfolio. An isolated component team can’t deliver realizable value without other contributions. When you subdivide a portfolio, you reduce transparency. This undermines the purpose of connecting work to strategy.
- There is an “intake system” in each portfolio. All strategic decisions in your portfolio should have full visibility into the entire scope of work required to create, release, support, evolve, and end technology. By over-dividing the portfolio, you create a huge churn and long tails where a piece of work is postponed.
What Are the Best Practices of Agile Portfolio Management?
Continuous planning
A roadmap and a strategic plan are living documents in any Agile enterprise, and they must be updated at least monthly or quarterly. Make strategic planning a continuous process. Track whether all things go according to plan and, if not, change what needs to be changed.
Strategic alignment
Agile portfolio management requires aligning products and programs with strategic objectives. Only those projects get funds that are tightly aligned with strategic objectives.
If the project’s course is not adjusted and strategic objectives shift, things can quickly fall out of alignment. So try to constantly revisit what is important and what is no longer that significant.
Program management
Planning related work in a coordinated way provides unique benefits. In the process, you get a chance to translate strategic objectives into business values. The metrics for measuring progress are different. Another distinguishing characteristic is fast feedback. It validates the program direction before too much is invested.
Resource management
When a portfolio of work is under consideration for funding, every single project, initiative, or product release is prioritized in accordance with business strategy and customer value. Optimizing resources and matching capacity to demand become easier when you have clear business drivers.
Enough governance
Agile portfolio management weakens the reigns on project teams (in comparison with the control that may have been exerted in the past). Agile governance is enough to reach value-based delivery while providing the flexibility to learn from successes and failures.
Iterative releases
The power of iterative funding that is tied to iterative releases is used in Agile portfolio management. Therefore, the feedback from clients constantly shapes the work in progress. It maximizes the value delivered with each release.
Agile Portfolio in Practice: How to Manage It
All the moments discussed above give you the direction of creating Agile portfolio management. For practice, you will need a complete management system to visualize, align, and prioritize your projects from the portfolio. This is where Kanban comes to help you bring theory to reality.
The power of Kanban
The main focus of the Kanban methodology is on visualization, managing flow, limiting work in progress, and continuous improvement.
At the Portfolio level, it is achieved through the concept of portfolio Kanban. It allows tracking and optimizing the flow of various business initiatives, projects, or entire products.
Interconnected Kanban boards are used to visualize initiatives, tasks, multiple projects, or project deliverables.
If you need to progress down to lower levels, interconnected Kanban board examples can be applied to visualize different parts of the department or even the whole company.
Conclusion
Everyone who has an Agile mind should be sure that their portfolio management practices do not undermine the value of Agile. The rules and practices described above will help you to make portfolio management more effective in today’s constantly changing environment.
Agile Portfolio Planning: Chapter 16
Most organizations want or need to produce more than one product at a time. These multiproduct organizations need to make economically sound choices regarding how to manage the tradeoffs between their products. The best way I’ve found to make economically sensible choices is to use an agile portfolio planning process that aligns well with core agile principles.
Agile portfolio planning (or portfolio management) is an activity for determining which products or projects to work on, in which order, and for how long.
Timing of Agile Portfolio Planning
The reality is that agile portfolio planning is a never-ending activity. As long as a company has products to develop or maintain, that company has a portfolio to manage.
You might recall from “Multilevel Planning in Scrum: Chapter 15” that portfolio planning is at a higher hierarchical level than individual product-level planning, or envisioning. That does not, however, mean that portfolio planning happens before product-level planning, chronologically speaking. On the contrary, the data gathered during envisioning is used in portfolio planning to determine whether or not to fund the product and how to sequence it into the portfolio backlog.
Portfolio planning isn’t just for new products, though. It occurs at regularly scheduled intervals to review in-process products, those currently in development, live, or being sold.
Participants in Agile Portfolio Planning
Agile portfolio planning should include an appropriate set of internal stakeholders, who have the perspective to properly prioritize new products and make decisions regarding in-process products. It should also include the product owners of individual products, who act as champions for their products and advocates for resources. Many organizations choose to invite senior architects and technical leads to ensure that any important technical constraints are factored into decisions.
Agile Portfolio Planning Process
The image below illustrates the agile portfolio planning process.
Portfolio Planning: Inputs & Outputs
The two inputs to portfolio planning are new-product data and data about in-process products. For new products, this data includes cost, duration, value, risk, and so on—this data should be gathered as part of the product envisioning process. For in-process products, data might include intermediate customer feedback, updated cost, schedule, and scope estimates, technical debt levels, and market-related data. The in-process product data will help determine the path forward for these products.
Portfolio planning has two outputs: a portfolio backlog and a set of active products. A portfolio backlog is similar to a product backlog; however, while a product backlog contains items relevant to only one product, a portfolio backlog describes multiple products, programs, or projects for which development has been approved but not yet begun. Each portfolio backlog item in the portfolio backlog might be a product, a product increment (one release of a product), or a project. This chapter uses the word product to refer to all three of these types of portfolio backlog items.
The set of active products includes new products that have been approved and are slated for immediate development, as well as products that are currently in process and have been approved to continue.
Portfolio Planning Includes 4 Activities
Participants in portfolio planning manage the portfolio backlog and set of active products through four categories of activities:
- Scheduling
- Inflows
- Outflows
- In-Process Products
The agile portfolio planning activities, and their associated strategies, are shown in the image below. All of these activities and strategies are essential and designed to work together to make portfolio planning successful. See “Agile Portfolio Management: This Ain’t No Cafeteria.”
Agile Portfolio Planning: Scheduling Strategies
The primary goal of portfolio planning is to allocate an organization’s limited resources to the various products in an economically sensible way. I recommend three strategies for determine the sequence of products:
- Optimize for Lifecycle Profits
- Calculate Cost of Delay
- Estimate for Accuracy, Not Precision
Portfolio Planning Scheduling Strategy 1: Optimize Lifecycle Profits
Lifecycle profits are the total profit potential for a product over its lifetime. Portfolio planning, however, is concerned with optimizing the lifecycle profits of the entire portfolio of products , which can sometimes come at the expense of an individual product’s profits.
Two variables that help determine lifecycle profits are cost of delay and duration, which are both covered in more detail in the next two strategies.
Portfolio Planning Scheduling Strategy 2: Calculate Cost of Delay
Before an organization can optimize for lifecycle products, it must first calculate the cost of delay. Cost of delay is the financial cost associated with delaying work on and, as such, the delivery of a product. Many organizations struggle to calculate the cost of delay, but this struggle is easily rectified.
One way to calculate cost of delay for a particular product is to run two different spreadsheet models to calculate lifecycle profitability—one without delay and one with a delay. Subtract the two bottom-line lifecycle profit numbers (one from each spreadsheet) and you will know the cost of delay for that particular product. The goal is to minimize the overall aggregate portfolio cost of delay. In other words, prioritize the portfolio backlog in a way that the total cost of delay across the items in the portfolio is minimized.
Portfolio Planning Scheduling Strategy 3: Estimate for Accuracy, Not Precision
A product’s duration (level of effort) affects lifecycle profits, and thus how an organization schedules its products. When estimating the size of portfolio backlog items, organizations should look for accuracy, not precision, because they will have a very limited amount of data when these initial estimates are made.
An effective and quick way to accurately predict product size is to use the T-Shirt Size estimates discussed in “Estimation and Velocity in Scrum: Chapter 7.” Each size acts as a metaphorical bin for all products that fit into the rough cost range associated with the size. For example, Extra-small products might range from $10K-$25K; Large from $125K-$350K. These measurements are accurate enough for decision making but not so precise as to be wasteful and most likely wrong.
Estimation is a complex subject and is not without controversy in the agile community (See “To Estimate or Not to Estimate: That Is the Controversy.”) For more on the benefits of grouping similar products by relative size, read “Relative Size Estimating: It's Just an Exercise in Binning.”
Agile Portfolio Planning: Inflow Strategies
Four inflow strategies for agile portfolio planning help guide participants in deciding when to insert items into the portfolio backlog:
- Apply the Economic Filter
- Balance the Arrival Rate with the Departure Rate
- Quickly Embrace Emergent Opportunities
- Plan for Smaller, More Frequent Releases
Portfolio Planning Inflow Strategy 1: Economic Filter
The economic filter is a blanket term for all of the decision criteria used by an organization to evaluate the economics of a proposed product in order to decide whether or not to fund it. This typically includes the output data from product-level planning: the product vision and data gathered during the envisioning process—cost, duration, value, risk, and so on. (Contrast this with the strategic filter.)
A good economic filter should make it obvious when an opportunity delivers overwhelming value relative to its cost. Those that meet this threshold should be approved; most everything else should be rejected.
Portfolio Planning Inflow Strategy 2: Balance Arrival & Departure Rates
Ideally, organizations want to achieve a steady stream of products moving into the portfolio backlog against a steady stream of products being pulled from the portfolio backlog. Too many organizations try to stick every desired product that might one day be developed into the portfolio at once. This only results in backups and waste.
A better strategy is to introduce relatively small products to the portfolio at more frequent intervals. This reduces the batch size and makes sequencing much easier.
If the portfolio backlog gets out of balance, limit the flow into the backlog by tweaking the economic filter. In other words, raise the product approval criteria so that only higher-value products are allowed to pass through.
Portfolio Planning Inflow Strategy 3: Embrace Emergent Opportunities
Agile portfolio planning should embrace emergent opportunities. An emergent opportunity is one that was previously unknown, or was deemed sufficiently unlikely to occur and therefore not something worth spending money on today. The economic value of many emergent opportunities decays rapidly, which means that companies need to be able to act swiftly to realize any economic value. Organizations that employ the other strategies discussed here will never have to wait long to consider an emergent opportunity, and can thereby take advantage of more of them.
Portfolio Planning Inflow Strategy 4: Plan for Smaller, More Frequent Releases
”Scrum Planning Principles: Chapter 14” discussed the favorable economics of smaller, more frequent releases. In essence, the lifecycle profits of a product almost always increase if the product is split into multiple, incremental releases. But there is another compelling reason to release smaller products more often: to avoid having one large product hog all of the resources, delaying the smaller products and reducing the lifecycle profits of the entire portfolio.
Agile Portfolio Planning: Outflow Strategies
Outflow strategies help an organization decide when to pull a product out of the portfolio backlog. These strategies are:
- Focus on Idle Work, Not Idle Workers
- Establish a WIP Limit
- Wait for a Complete Team
Portfolio Planning Outflow Strategy 1: Focus on Idle Work
“Agile Principles: Chapter 3” mentions the key principle to focus on idle work, not idle workers. This principle states that idle work is far more wasteful and economically damaging than idle workers. Yet, many organizations fail to apply this principle to their agile portfolio planning. They pull products from the portfolio until all of their people are working at 100% capacity and then stop.
This approach will keep everyone busy. But it will also slow the work on every product. A better strategy is to only begin work on new products when there is a good flow of work and when it won’t disrupt the flow on existing in-process products.
Portfolio Planning Outflow Strategy 2: Establish a WIP Limit
Organizations should never pull more products from the portfolio backlog than they have the capacity to complete. Doing so will cause reduced capacity on all products (resulting in each being delayed) and will cause the quality to suffer. For more on the benefits of limiting WIP, read “The Counter-Intuitive Argument for Limiting Project WIP.”
Portfolio Planning Outflow Strategy 3: Wait for a Complete Team
Because the unit of capacity in Scrum is a team, organizations shouldn’t start working on a product without a complete Scrum team. An incomplete Scrum team is insufficient for getting features to a done state. Once a team is available, work can begin on a product, even one that will eventually require multiple Scrum teams, as long as it makes sense in other respects to begin development.
Agile Portfolio Planning: In-Process Strategy
During agile portfolio planning, the participants should spend some time looking at existing, in-process products to determine what currently is most appropriate: To persevere, deliver, pivot, or terminate each product. It makes sense to make these decisions at regular intervals (such as the end of each sprint) or when events occur that require a reassessment of current products.
While each governance organization will have its own criteria for making these decisions, the overarching strategy to guide all decision making is marginal economics.
Portfolio Planning In-Process Strategy: Use Marginal Economics
Marginal economics is a lens to help organizations determine if spending the next chunk of money is justified by the return that investment would generate. All of the work that has been performed on the product up to the decision point is considered a “sunk cost.” As counterintuitive as it might feel, sunk costs are not relevant to the determination as to whether or not the company should spend the next chunk of money on a product.
Focusing solely on the economic justification for the next investment in the product, companies can decide whether to persevere with the product, deliver it as is, pivot (try another path), or terminate it.
Marginal economics is a powerful tool for doing the right thing and for exposing foolish and wasteful behavior associated with putting too much weight into the sunk costs of a product. It should be the principal strategy when considering what to do with in-process development.
Agile Portfolio Planning: Summary
All 11 strategies introduced in this chapter reinforce one another. Companies will derive the maximum benefit by doing all of them. If for some reason, an organization needs to start with only one strategy from each category, focus on cost of delay, smaller and more frequent releases, WIP limit, and marginal economics. The next chapter will focus on envisioning (product-level planning).
Управление портфелем по методологии agile
Когда у нужных специалистов в нужных командах имеется нужная информация, они неизбежно занимаются правильными вещами.
Автор: Dan Radigan
Просмотр тем
Описание. Управление проектами по методике Agile — это гибкий подход к управлению портфелем проектов. Он подразумевает непрерывное проведение экспериментов, децентрализованный контроль и прозрачность.
Можно ли применить методики Agile к крупному портфелю проектов, в работе над которыми задействовано большое количество команд и разработчиков? Да, это можно сделать с помощью гибкого подхода к управлению портфелем. В компании Netflix говорят о «строгой согласованности и слабой взаимозависимости», когда описывают отлаженный процесс управления портфелем по методике Agile в рамках крупной организации. Давайте посмотрим, какую роль играют связность и независимость, а также что объединяет успешные портфели проектов, которыми управляют по принципам Agile.
Помещение в правильный контекст
Методика agile уделяет так много внимания команде, что руководители крупной agile-организации часто не понимают, в чем заключается их роль. Но они определяют стратегию, они прокладывают курс, а значит, они могут стать главными проводниками культуры agile в рамках целой организации. Когда мы применяем принципы agile-разработки к портфелю проектов, стратегия и курс выражаются в виде «тем» — больших объемов целенаправленной работы, продолжающейся в течение некого промежутка времени. Благодаря темам разные команды, работающие над одной бизнес-инициативой, взаимодействуют более эффективно и достигают целей организации.
В прозрачной культуре о проблемах говорят открыто, без страха возмездия; сглаживаются недостатки отстаивания интересов в компании. Как следствие, проще найти правильное решение, чтобы работа в командах не останавливалась.
Применение методик agile в масштабе всей организации
В наиболее успешных компаниях, применяющих методики Agile на всех уровнях деятельности, можно наблюдать три общих принципа. Во-первых, вся программа носит итеративный характер. В традиционной модели управления портфелем проектов во главе угла лежит нисходящее планирование, и под работу выделяются продолжительные отрезки времени. При внедрении Agile за основу берется концепция циклов «создать — оценить — узнать», которую используют отдельные agile-команды и которая затем распространяется в более широком масштабе. Долгосрочное agile-планирование осуществляется командами, которые работают сообща, опираясь на модульный подход, и регулярно обмениваются результатами работы. В ходе реализации проекта они вправе подбирать баланс между объемом работы, сроками ее выполнения и выделяемыми ресурсами, т. е. основными составляющими тройственной ограниченности планирования. Благодаря этому достигается невероятная гибкость, и команда, вместо того чтобы продолжать выполнять жесткий план, сосредотачивается на поставке ценности и достижении ощутимого прогресса в соответствии с бизнес-стратегией и целями.
Во-вторых, в успешных организациях налажен стабильный обмен информацией о портфеле проектов. Происходит обмен знаниями, преодолевается разрозненность внутри организации. В рамках организации должен постоянно происходить обмен контекстами, такой же, как на agile-собраниях на уровне команд, чтобы все были в курсе целей, хода работы и препятствий. Благодаря этому растет уважение между коллегами всех уровней, независимо от их роли в организации, и укрепляется взаимодействие, основанное на эмпатии и взаимопонимании.
В-третьих, для большинства agile-организаций характерны частые релизы в разных проектах портфеля, даже если релиз подразумевает работу сразу нескольких команд. Согласованность циклов спринта, работа над созданием надежных API и технической изоляцией, эффективная автоматизированная цепочка тестирования и развертывания в совокупности позволяют видеть, кто поставляет что и к какому сроку.
Единая точка зрения при поддержке разнообразия
Как в случае с традиционной agile-разработкой, работа по agile-разработке портфеля проектов поручается командам, а не отдельным сотрудникам. Каждая команда понимает главные цели организации, и в каждой команде складывается динамично развивающаяся культура, в которой оптимизируются подходы к работе и поставке.
Например, команды обычно оценивают сложность работы в очках за истории, используя шкалу, напоминающую последовательность Фибоначчи (0,5, 1, 2, 3, 5, 8, 13, 20, 40, 100). Одна команда, скорее всего, будет понимать оценку в 8 очков иначе, чем другая команда. По этой причине высшее руководство не должно оценивать скорость команд только в числовом выражении (скорость команды в числовом выражении — это количество очков за истории, которое команда может выполнить за спринт). Оно должно понимать, что скорость каждой команды уникальна, потому что каждая команда по-разному понимает реальный эквивалент очков за истории.
Кроме того, agile-команды по-разному подходят к релизам. Scrum-команды, как правило, выпускают программное обеспечение в конце каждого спринта, а kanban-команды делают это либо постоянно, либо когда владелец продукта запрашивает сборку, которую необходимо запустить в работу. Одна из самых больших проблем agile-разработок — релизы с большим количеством изменений, точнее — попытка их избежать. В конце концов, никому не нужны релизы, для выпуска которых необходимо задействовать весь технический персонал. Переход от монолитного дизайна к модульному, который обеспечивается путем разделения кода на отдельные потоки релизов, способствует повышению гибкости и независимости бизнес-подразделений. Модульный дизайн также снижает риски при релизах, т. к. каждый релиз содержит небольшое количество изменений, что значительно упрощает диагностику и устранение проблем.
Изоляцию можно распространить и на рабочие процессы в организациях, управляющих портфелями проектов. Команды, занимающиеся разными направлениями деятельности, могут использовать совершенно разные рабочие процессы. Разумеется, рабочий процесс команды разработчиков ПО будет отличаться от процесса маркетинговой команды, даже если оба отдела верны таким принципам agile, как итеративная модель разработки и регулярный анализ прошлой работы в ходе ретроспектив. Аналогичным образом две команды разработчиков могут делить свой рабочий процесс на разные этапы. И это абсолютно нормально! Такое разнообразие подходов формирует серьезное преимущество для крупных agile-проектов: оно способствует обмену знаниями. Чем больше подходов вы пробуете, тем больше вы узнаете, а этими знаниями можно делиться с другими командами в организации.
Расширяйте масштаб применения agile-принципов по мере развития
Чтобы применить методы гибкого управления к крупному портфелю проектов, нужно распространить принципы Agile, которым следуют отдельные команды, по всей организации. Культура Agile несет ощутимую пользу: ее охват естественным образом расширяется и углубляется по мере того, как все больше людей встраивает в работу основные принципы Agile. Но успешность портфеля проектов определяется успешностью самого слабого звена в организации. Чтобы создать работоспособную культуру Agile и достичь успеха, нужно наладить взаимодействие между руководством организации и всеми командами.
Готовы применить методы Agile ко всему портфелю проектов? Узнайте, как с помощью корпоративной платформы для agile-планирования Jira Align можно обеспечить наглядность, согласовать стратегии и обеспечить адаптивность на уровне всей компании для ускорения цифрового преобразования.