Top 4 Tips When Developing Agile Portfolio Management

Posted on by Heli Hiisilä

Has your organization adopted agile methodologies in recent years? Have your portfolio management practices undergone a review as well? If this is relevant for you, I have compiled four tips to assist you.

TIP 1. Start with Agile Principles

First of all, have you had a good discussion related to agile principles, and how they are reflected in your day to day portfolio management practices? This would be a great starting point to see, how your team, portfolio sponsor and key stakeholders consider agile principles are present in your portfolio management, and why not also align on to-be-state – where you would like to be in the future.

Here are few questions to facilitate the discussion:

  • Customer value – do you always look into value created to customers (or end-users), when you develop something new or prioritize development? Do you have good examples or cases, where customer value was well considered, or examples where this aspect was forgotten? How could you take customer value stronger into your decision making processes?
  • Embracing the change – do you enable changes in the scope of development or do you have a strongly plan driven approach? What happens in practice, if a team identifies a need for scope change after budget approvals? Can agile be systematic and highly disciplined development approach, while still embracing the change?
  • Continuous delivery – do you look into outputs and outcomes of development frequently? How do see the progress in practice, for example via demos, reviews or sharing sessions? Is your development methodology supporting continuous delivery approach or do you have gigantic development programs with big bang approach?
  • Collaboration – do you encourage collaboration across the organizational units? Is collaboration, sharing and alignment inbuilt into your portfolio management routines and processes?
  • Self organizing teams – do teams have needed end-to-end knowledge to work independently? Are teams empowered to do needed decisions based on the clear guardrails? How could you help teams with smooth portfolio level decision making?
  • Simplicity – Is your goal to maximizing the work not done? What is the guidance when you plan or projectize development work – do you try to include comprehensively all scope into the project plan, or do you focus on development first Minimum Viable Product? How do you approach prioritization in the portfolio level?

Many times agile way of working has been growing organically within the organization, and portfolio management has not been the focus area during the transition. If this is the case within your organization, it is good to see where you are today already strong, and which principles should be strengthened in the context of portfolio management. Also, as all organizations are unique, you may choose some of the principles as your guiding principles and focus areas to first develop in the context of development portfolio management.

TIP 2. Review development portfolio roles

Often when moving towards agile ways of working, also portfolio roles may be impacted significantly. If the use of agile practices has become popular within the organization, it may be a good time to review and discuss the portfolio management roles, too. Here are few roles to start review with:

  • If development is carried out more and more via agile teams, has the project and program manager roles been adapted? When developing something complex, something completely new, who looks into the big picture to ensure the smooth and timely flow of development across different teams?
  • How about the portfolio manager role – is portfolio manager looking into the traditional project portfolio, or covering also the development happening via the agile development teams? Are there new areas to learn for your portfolio management team in the context of agile?
  • Are business owners actively participating to agile development prioritisation, reviews and demos? And do you have product owner role standardized? If you initiate a new team, is it clear what is expected from a product owner in your organization? How about end-to-end process view, is it covered by certain roles?
  • Do you have new roles introduced, such as agile coaches, scrum masters, release train engineers? How do you collaborate with these different roles for development portfolio viewpoint?

Many times, when agile is not scaled across the organization, there may be a mix of different roles within different units even with the same development portfolio area. And in this case, it is important to identify the different roles, and also agree how you work together when it comes to portfolio related topics, such as planning and decision making.

TIP 3. Visualize Development Portfolio

A good approach for any development portfolio every now and then is to look into the content of the portfolio – what is actually included in there? This is especially good activity, if you have not done it lately.

  • You can just take a big whiteboard and sketch the structure with your colleagues! If you visual your portfolio, what does it look like? Do you have a strong project portfolio? Do you have large development programs? Do you have value streams? Anything else?
  • If you have a portfolio management tool – is agile development covered in the tool, portfolio plans and reporting?
  • Follow the money – where is the development budget spend? Do you have large budget lines, which are not really visible in the portfolio level?
  • Portfolio Kanban is also a great tool, especially if you want to visualize your portfolio funnel, a dedicated blog post focusing on this topic here: Do you manage a Portfolio funnel, or Portfolio tunnel?

Sometimes, development happening via the agile teams is almost invisible in the development portfolio scope – this may very well be the case, if the organisation is looking into the traditional project portfolio management. If this is the case for you too, you might find this blog post helpful: From project portfolios to hybrid portfolios – combining projects and agile work

TIP 4. Review Agile Portfolio Management Practices

If you have state of art project portfolio management practices in place, how do you take into account agile development? Here are some of my favorite practices to get you inspired:

I hope you got some inspiration for developing agile portfolio management approach in your organization. And as always, I would be happy to learn what works for you, and where you might be facing challenges – so let’s connect!

Interested to learn more? Have a look:

  1. Agile manifesto
  2. From project portfolios to hybrid portfolios – combining projects and agile work
  3. Do you manage a Portfolio funnel, or Portfolio tunnel?
  4. Time for A Quarterly Portfolio Review?
  5. Closing the gap between strategy and development portfolios using Objectives and Key Results (OKRs)
  6. Finding Your North Star – Creating a Shared Long Term Vision

Do You Hear Laughter? Tips for Creating Psychological Safety for Development Teams

Posted on by Heli Hiisilä

Project work and developing new products and solutions require a lot from the teams – there may be complex problems to be solved, challenges to get started with the new initiative, stretched timelines to meet, and different types of needs coming from many different stakeholder groups. But even though development work is often very demanding – the best teams still manage to have fun together and achieve a lot!

I am part of my workplace Grow training this autumn and got inspired by the psychological safety theme – here are some reflections on how psychological safety can help Development portfolios perform better!

Making things happen – and having fun in the team level

I am a big fun of Amy Edmondson – and her Creating a Fearless Organization. Based on Amy Edmondson, Psychological safety is not about being nice, avoiding conflicts or an excuse to complain, but creating an environment where development teams have high performance standards, but still feeling safe enough to speak up about mistakes and concerns – and being unafraid to bring up also ideas and questions.

Based on my experience, best performing teams make things happen, but also still manage to have fun. For me, it is always a good sign, when I hear laughter from the development team. When the team has fun together, is also easier to bring up difficult topics, and also find the solutions. Best teams have also fierce debates, as the aim is to find the best solutions. And not to forget wild ideas, which can be enhanced and enriched together as a team.

Inviting to participation – across the organization

When developing complex solutions impacting the work of different business units and end-to-end processes, a significant amount of communication and alignment across the organization is needed. Does the development team feel safe when introducing new ideas and concepts with the stakeholders? How is the feedback given and received?

As a lead of a strategic initiative, there may be many stakeholders groups to be alignment with – and a need to build new connections between the units, which have not been earlier collaborating actively. The way of working, terminology and tools used may differ, and there is a big risk of misunderstanding. Here it is important to keep the big picture, but also actively align with different stakeholder groups, listen and use the feedbacks actively to improve the final outcomes. Are your workshops safe environment to give feedback, bring up ideas and debate?

As a stakeholder of a strategic initiative, it is important to offer support for the development team, even though topic might be new to you, and you may feel uncomfortable to certain extend. Listening actively, and trying to connect the development vision to your own area of expertise is important – and to avoid starting with your own agenda first. Also, bringing up the potential development needs is important, as the development team may not have all the needed knowledge for end-to-end value chain. Are you giving the feedback in a constructive way, which are easy to take into consideration and invite to dive deeper into the topic together?

One of the clear trends I have seen in many companies, is to reduce the amount of steering meetings, and increase the amount of sharing via other means. Great practice widely used by agile teams is to organize demos and reviews – seeing concretely what has been developed helps everyone to understand the content, and bring up also development needs.

Psychological safety in portfolio level decision making

When I was quite fresh from the university, I was working for a large transformation program which had been ongoing for several years. The planned go-live was closing and many team members were really worried about the performance of the solution – as after go-live, the new system could risk the company continuity. When the performance issues were discussed, an experienced management consultant gave an advice: “Senior managers are like sheep, you don’t want to scare them off.”

Well, after all these years I still disagree with that – teams should feel comfortable bringing up also concerns and senior management deserves to get objective and data based understanding. In the end for that specific project, company internal controls worked as they should, and the performance challenges were addressed before the go-live. Oh, what a learning it was for all the stakeholders involved, and big emotions also involved!

Another big ERP implementation project, where I worked, faced a big challenge with technical environments one month prior to go-live. As a program lead, this was not an easy news to bring up, but as a team, we got the full support from the management and all the vendors involved, and the year end schedule was kept thanks to good team work. I think here psychological safety played a key role in that case – discussing openly about the challenge enabled also finding the solutions with all parties.

Here are few tips for portfolio managers and senior management to help the teams:

  • Encourage teams to share, organize demos and reviews with the rest of the organization – this helps to create alignment and get feedbacks early. Seeing is believing! Participate, sponsor and create a positive and encouraging atmosphere to these events!
  • No news is not always good news – encourage teams to share openly about their progress and seek for alignment – not only within gate approvals, then it might be too late.
  • Build flexibility into the decision making – can teams bring up key topics to decision making forum to inform senior management or when guidance is needed?
  • Don’t kill the messenger – when something goes wrong, don’t find who to blame, but think ways to support to solve the challenge!
  • Hearing laughter during team meetings is usually a good sign – the best teams have fun and also achieve a lot together!

More blog posts related to portfolio governance available here: Development Portfolio Governance.

References

Amy Edmondson – Creating a Fearless Organization – Youtube video

Team of Teams – tackling complex challenges

Posted on by Heli Hiisilä

Today, the complexity of solutions, processes and IT tools has grown, and development teams are working with complex challenges.

Based on the great discussions on the previous blog posts related to agile teams and business agility, here is another post related agile teams. The concept of a “team of teams” was popularized by General Stanley McChrystal in his book “Team of Teams: New Rules of Engagement for a Complex World.” Here are some key ideas related to the concept, to give inspiration:

Dealing with complexity and rapidly changing environment by distributing decision-making authority

Traditional hierarchical structures and command-and-control systems are often inadequate in dealing with complex and rapidly changing environments. In today’s interconnected world, challenges are typically complex and require flexible and adaptive approaches. To effectively tackle complex challenges, organizations need to move away from centralized decision-making and embrace a more decentralized approach. Decision-making authority should be distributed to the teams on the ground who have the most relevant information and expertise.

Each team within the organization should be empowered to make decisions and take action based on their understanding of the mission and the information available to them. This requires trust, clear communication, and a shared understanding of the organization’s priorities and values. In the portfolio level, clear guiderails may help to achieve this – what decisions can be made in the team level, and where portfolio level decision making is needed?

Transparency and shared consciousness

Another key idea from the book, is that establishing a shared consciousness across the organization is important. This means that all teams should have access to real-time information and a common understanding of the larger mission and goals. Open communication and transparency are essential for creating this shared consciousness.

Rather than operating in isolated silos, teams should form collaborative networks that allow for effective coordination and information sharing. Inter-team collaboration and cross-functional communication are vital for breaking down organizational barriers and enabling collective problem-solving.

Is the current way of getting organized around development support collaboration?

Experimentation and continuous learning

The team of teams approach emphasizes the importance of continuous learning and adaptation. Teams should be encouraged to experiment, learn from failures, and iterate on their approaches. A culture of learning and innovation is necessary for staying agile in a rapidly changing environment.

Traditionally waterfall based state-gate models have not supported the experimentation and iterative learning – how is it today in your organization?

The new role of the leader

Traditional leadership roles also need to adapt to the team of teams model. Leaders should focus on providing guidance, fostering collaboration, and creating an environment where teams can thrive. The role of leaders is to empower and enable teams rather than micromanage or control them.

Overall, the team of teams concept promotes a more agile, decentralized, and collaborative approach to tackling complex challenges. By leveraging the collective intelligence and capabilities of teams, organizations can become more responsive, adaptable, and effective in today’s dynamic world. If interested to learn more, I would recommend checking out this book!

References

McChrystal S., Collins T., Silverman D. & Fussel C. 2015. Team of teams. New rules of engagement for a complex world. Portfolio Penguin.

What Do You Call Your Agile Teams?

Posted on by Heli Hiisilä

Today more and more development is carried out via agile teams. When discussing with colleagues from different companies, the terminology and the ways of working seem to vary a lot across companies and even within one organization. This is not surprising, as there is no one and only way for agile – agile mindset, values and principles may be implemented using a large variety of practices and methodologies.

Agile manifesto was published 2001, defining 4 core values and 12 principles. These values and principles should be share across agile teams, but there is a huge amount of practices and also many agile methods used among the practitioners. Some companies have implemented enterprise agile, based on SAFe or LeSS frameworks, but in many organizations agile has grown organically, and each team has optimized the ways of working and applied agile practices to best fit their unique needs.

When discussing with peers, I have come up with at least the following terminology related to agile teams: agile team, continuous development or continuous improvement team, Scrum team, Kanban team, DevOps team, product team, and task force. Then there may be value streams, ARTs, teams of teams, or tribes. A beloved child has many names – what do you call your agile teams?

I will try to consolidate some of my favorite content and links here related to agile teams, as this is an area, I want to learn more, too! If you have great content related tips, please ping me!

How is team defined in Agile?

So how is team defined in Agile? Let’s have a look!

A “team” in the Agile sense is a small group of people, assigned to the same project or effort, nearly all of them on a full-time basis. … The notion of team entails shared accountability: good or bad, the outcomes should be attributed to the entire team rather than to any individual. The team is expected to possess all of the necessary competencies, whether technical or business.

Agile Alliance glossary, https://www.agilealliance.org/glossary/team/

The definition provided is quite wide, and there are many great ways to work with agile methods. Even though methodologies and approaches from team to team seem to differ a lot, there are certain common characteristics across different teams. Here are a few which I have noticed are quite common:

  • Developing something new – as all teams are unique, it may be new beautiful product features, a use case in a sales tool enabling a new business model, enhancement of ERP system for better efficiency, or a change in the business process
  • Regular releases or delivery of new content – the release cycles differ a lot from team to team from daily releases to quarterly releases
  • The team works together, learns together, and achieves together – there may have company internal and external team members, and there is continuity in the team. If one member of the team leaves, the team has the competences to bring in a new team member quickly.
  • There is regular prioritization of the content together with the key stakeholders. Prioritization may happen bi-weekly, monthly, or quarterly, this seems to depend a lot on the team and content the team is developing. Sometimes there is clear product ownership presenting also the voice of different stakeholders and customers, sometimes there are multiple stakeholders.
  • The team is managing the work via a backlog or for example Kanban board. For the portfolio level, the higher-level roadmap is a great tool to communicate the team plans with a wider group of people. Sometimes there is a detailed roadmap for the next quarter and high level epics or themes for the 1-3 years.

Many teams utilize a mix of Agile methods, such as using Scrum or Kanban. So let’s have a look at these, too!

Agile methods – Scrum, Kanban, XP, Lean…

Agile methodologies are a set of principles and practices that enable teams to deliver high-quality products or services in a flexible, iterative or incremental manner. These methodologies share common values such as adaptability, collaboration, and customer focus. They enable teams to respond to changing requirements, deliver value incrementally, and continuously learn and improve.

Here’s a short summary of some commonly used agile methodologies:

Scrum is one of the most popular agile frameworks. It involves dividing the work into small iterations called sprints, typically lasting 1-4 weeks. The team works collaboratively to deliver a potentially deliverable product increment at the end of each sprint. Daily stand-up meetings, backlog refinement, and sprint reviews are key components of Scrum. There are great resources to learn more, for example https://scrumguides.org/index.html.

Scrum is a great methodology for example for professional software development teams, but I have seen also successful applications in hybrid project context.

My favorite methodology for business development teams is Kanban.

Kanban emphasizes visualizing the workflow and managing work in progress (WIP) to optimize efficiency. Work items are represented as cards on a Kanban board, moving through different stages from “To Do” to “Done.” Teams pull new work items as they complete existing ones, ensuring a smooth flow of tasks. Kanban provides transparency and flexibility in managing priorities. A great resource to learn more about Kanban here: The official Kanban Guide. – Kanban Guides,

Lean is a great methodology for example for process or operations improvement initiatives, but also lean product management has become popular.

Lean methodology focuses on maximizing value while minimizing waste. It originated from the manufacturing industry and has been adapted widely for software development, too. Lean principles include eliminating unnecessary processes, reducing defects, empowering teams, and continuously improving the workflow. The goal is to create a streamlined and efficient process.

There are also several other popular methods, such as XP. Extreme Programming (XP) emphasizes close collaboration between developers, stakeholders, and customers. It emphasizes practices like continuous integration, test-driven development (TDD), pair programming, and frequent releases.

Ok, so these are commonly used agile methods, but how about continuous development, DevOps and other approaches linking to agile teams?

Different approaches for agile teams: Continuous development, DevOps & Agile project or program teams

In addition to methodology used, there is also the approach team has taken, such as Continuous development or Continuous improvement, DevOps, or other approaches linking to the ways of working.

A continuous development team is a group of individuals working together to deliver software or other outcomes in an iterative and continuous manner. This approach promotes fast and continuous delivery, enabling teams to respond quickly to changing requirements and market demands. Continuous development teams often utilize agile methodologies, automated testing, continuous integration and delivery pipelines, and collaborative tools to streamline the development process and ensure high-quality software releases.

Also business development may follow continuous development approach – developing, experimentation, collecting feedback, and further improving.

DevOps is a software development methodology that combines development (Dev) and operations (Ops) teams to streamline the software development and deployment process. It emphasizes collaboration, communication, and automation to achieve faster and more reliable software delivery. Learn more: “What Is DevOps? The Ultimate Guide”

From the development portfolio view point, DevOps team may be a bit challenging, as development and operations are combined seamlessly – how much are we investing into developing new and how much of the team work load is about keeping the business running?

In addition to continuous development teams or DevOps teams, also project or program teams may apply agile methodologies and ways of working. Based on a recent case study with 477 cross-industry projects, 52% of projects used a hybrid approach, including agile ways of working (Gemino et al, 2021).

So what is different in agile or hybrid projects?

In the traditional Waterfall project, the project triangle has fixed scope/features, time, and cost – and what would be variable – quality? The idea with agile or hybrid projects is to deliver a working solution within the given time, cost and with good enough quality. The number of features would be variable – and typically a recommended approach is to start with a delivery minimum viable project – a working solution with just the very basic functionalities.

But our team is unique – team topologies may help?

When discussing with different teams, there are many different types of teams. Of course, content is different, which is also reflecting to the way of working. One of my colleagues recommended to have a look at the Team topologies, I think this is useful to understand the nature of different types of teams:

  • Stream aligned team – developing a product and services, applications
  • Enabling teams – experts in certain area enabling work of other teams
  • Complicated sub-systems team – deep skills and expertise for example for a niche technology
  • Platform team – running platform as product and creating a great developer experience for other teams

If you are interested in team topologies, have a look at the short video: What are the core team types in Team Topologies? or navigate to the web pages https://teamtopologies.com/.

Scaling Agile in Enterprise Level – Frameworks

In many organizations, adoption of agile methodologies has grown organically – resulting in a rich variety of ways of working and also sometimes difficulties to collaborate across different teams. I will cover briefly two popular enterprise agile frameworks: Large Scale Scrum (LeSS) and Scaled Agile Framework (SAFe):

Large Scale Scrum (LeSS)

When having multiple scrum teams, organizations may need to consider how to get organized. Large Scale Scrum (LeSS) has been developed to help with this. For really big organizations, LeSS Huge offers support to scale up. Tons of great material available via the LeSS pages: https://less.works/.

In the LeSS teams have certain key characteristics: teams are self managing and cross-functional, team members are 100% dedicated for work, and teams are co-located in the same room, and optimally teams would stay together forever (= long-lived teams). Teams are also managing external dependencies and make their own decisions. Team members are also multi-skilled, learning and adapting to changing needs. Read more about LeSS definition of team from here: link, also excellent recommended reading section provided.

Scaled Agile Framework – organizing around Value streams

Another popular framework to scale agile in enterprise is Scaled Agile Framework (SAFe). Scaled Agile Framework contains masses of good practices for different domains, and the trick would be to select the best ones fitting your organizations needs!

Within SAFe, there are also agile teams, and teams are organized as teams of agile teams, ARTs focusing on developing a value stream. What I especially like about SAFe, that also Lean portfolio management is included in the framework scope with many good practices. A SAFe portfolio is a collection of Value streams for specific business domain.

Conclusion & impact on development portfolios

Thank you for reaching to the end of such a long blog posting! Just final remarks: agile is not only about the methodologies, ways of working, frameworks and tools, even though these are also important, but about the mindset:

  • Delivering value to customers fast and continuously
  • Ability to respond to the change
  • Focusing on continuous improvement

In the context of development portfolios, it is important to understand how different teams in the organization work, and create transparency on portfolio level. More about Hybrid development portfolios combining projects and agile via separate blog post!

If every agile team has its own ways of working, it may be difficult to create portfolio-level transparency on all the great achievements throughout the organization. Also, increasingly large budgets are spent on agile development, and having clear guardrails and lean governance is important.

References

http://agilemanifesto.org/

https://www.agilealliance.org/glossary/team/

https://scrumguides.org/index.html

The official Kanban Guide. – Kanban Guides

Courtemanche, Meredith; Mell, Emily; Gills, Alexander S. “What Is DevOps? The Ultimate Guide”. TechTarget. 

A. Gemino, B. H. Reich and P. M. Serrador, “Agile, Traditional, and Hybrid Approaches to Project Success: Is Hybrid a Poor Second Choice?,” Project Management Journal, vol. 52, no. 2, pp. 161-175, 2021.

https://teamtopologies.com/

https://less.works/.

Scaled Agile Framework

Check out also the latest blog posts!

View all news →

Do you want to get the latest blog updates to email?

By clicking submit, you agree to share your email address with the site owner to receive latest updates from the blog. Use the unsubscribe link in those emails to opt out at any time.

Processing…
Success! You're on the list.
https://www.scaledagileframework.com/

10 Ways How Business Agility Transforms Strategic Development Portfolios

Posted on by Heli Hiisilä

Business agility refers to an organization’s ability to quickly and effectively respond to changes in the business environment – by being agile, organizations can adapt to change more effectively, capitalize on opportunities, and stay resilient in the face of disruptions.

Technology organizations have been working with agile methodologies for quite some time, but what does business agility mean in the context of strategic development portfolios?

1. Adapting to change

Adaptability to changes is an important benefit of business agility for development portfolios. Organization needs the capacity to anticipate and respond to market changes, customer needs, as well as emerging trends. An agile business is proactive in identifying opportunities and is willing to adjust its products, services, or operations accordingly.

Development portfolios can respond to changing priorities, market demands, and customer needs by adjusting the project portfolio content, timelines, and resourcing. If portfolio plans are fixed during the long range planning or yearly budgeting, it may be difficult to adapt to the change. One of the good practices I would recommend is portfolio reviews, see more via previous blog post: Time for a quarterly review?

2. Faster time to market

Agile approaches emphasize iterative development and frequent releases. By breaking projects and other initiatives into smaller, manageable chunks and delivering incremental value, agile enables faster time to market, allowing organization to seize market opportunities and gain a competitive edge.

So how to speed up development and go-to-market from the development portfolio view point?

  • Developing minimum viable product – being brave with prioritization of the content
  • Breaking down big initiatives into smaller, faster to implement work packages
  • Ensure smooth decision making – lean but powerful governance is blessing for the whole organization
  • Make go-to-market process fast and smooth – and Don’t forget the deployment!

3. Customer co-creation

Agile methodologies prioritize customer collaboration and feedback. By involving customers early and continuously throughout the development process, development portfolios can ensure that the delivered products or features align with customer expectations, resulting in higher customer satisfaction and loyalty.

Hearing the needs and feedback from the customers (or internal customers) is super important driver – and also reduces the risks of developing something, which is not actually valued by the customers and end-users. We may think we know what customers want and need, but do we really know if we don’t ask or validate the idea?

Customer engagement should be built into the development portfolio processes:

  • Do you co-create development concepts with customers? Do you validate the concepts with customers?
  • Do you have pilot customers to receive early feedback? Do you also have time to develop the solution based on the feedbacks?
  • Do you continuously collect feedback from the customers related to your products and services? Do you have a systematical process to analyze the feedbacks and take action?

Service design and growth hacking methods provide great support in this area!

4. Transparency

Agile methodologies promote transparency and visibility through practices like sprint reviews and demos. This enables stakeholders to have a clear view of project or team progress, impediments, and upcoming deliverables.

In the portfolio level creating transparency on agile team outcomes is also important – this may sometimes be a bit tricky, if the development portfolio has been mainly focusing on project portfolio view only. More ideas related to how to combine projects and agile available via the previous blog post: From project portfolios to hybrid portfolios – combining projects and agile work.

In the portfolio level, here are few topics to consider, when working with agile teams:

  • How much are we funding different agile teams?
  • Would there be a need to scale team capacity up or down in the future?
  • What does the high level roadmap look like for the agile team?
  • What are the key priorities and outcomes from each team for the next quarter?
  • How are different teams creating transparency across the organization for the great content delivered and also receiving the feedback (e.g. demos)?

5. Incremental benefit realization

One of the great benefits of agile approaches is delivery of smaller working products and solutions, which already enable benefit realization.

When compared to traditional waterfall development approaches with big-bang go-live, agile approaches may enable benefit realization for key parts of the delivery even years earlier. Over the time, this really adds up! If you have a massive transformation program with waterfall delivery, could you break down large entities to smaller incremental deliveries? This may not be always easy, but also reduces the risks of big-bang go-lives!

6. Reducing risk by learning fast

Agile embraces an iterative and incremental approach, allowing for early identification and mitigation of risks. By experimentation and feedback loop, it is possible to learn faster, and reduce the risks.

By regularly assessing and adapting development plans and priorities, development portfolios can address potential issues proactively, minimizing risks and maximizing project success.

  • Do you regularly discuss about the risks and also plan how to mitigate the risks?
  • Is it ok to kill a initiative in your organization, if you see, it is not commercially or technically fit for purpose?
  • Do you have experimentation culture to learn fast?

7. Collaboration – cross functional teams empowered with decision making

Promoting a culture of collaboration and cross-functional teamwork is crucial for business agility. This involves breaking down silos, fostering effective communication, and encouraging employees to share ideas and work together towards common goals.

By empowering teams to make decisions, collaborate closely, and take ownership of their work, development portfolios can foster a culture of innovation, creativity, and high performance. Here are few topics to consider:

  • Do you have truly cross functional teams?
  • Do you have clear guardrails for the team decision making?
  • What can be decided in the team level and which topics are decided in the portfolio level?

8. Continuous improvement

Embracing a mindset of continuous learning and improvement is fundamental to business agility. Agile organizations encourage experimentation, embrace failure as a learning opportunity, and constantly seek ways to enhance their processes, products, and services.

Agile promotes a culture of continuous learning and improvement. Development portfolios can regularly reflect on their processes, gather feedback, and implement changes to enhance efficiency, quality, and overall project outcomes.

  • Do you have feedback loops inbuilt for different development activities to collect the feedback, learn and improve?
  • Do you systematically collect and analyze development ideas and have capacity also for continuous improvement activities?

9. Resource utilization & prioritization

Agile methodologies emphasize prioritization, allowing development portfolios to focus on high-value initiatives and allocate resources accordingly. By optimizing resource utilization and reducing unnecessary work, Agile helps maximize productivity and ROI.

In practice, this also requires clear prioritization work in the portfolio level – which helps to create clarity and focus. More about the different prioritization methods for portfolios in a previous post: The Biggest Challenge For Development Portfolios is … Prioritization.

10. Employee engagement

Improved Employee Engagement and Satisfaction – agile methodologies empower team members, promote collaboration, and value individuals and interactions. This leads to increased employee engagement, job satisfaction, and retention within development portfolios.

This topic would require an own blog post in the future…

Check out also the latest blog posts!

View all news →

Do you want to get the latest blog updates to email?

By clicking submit, you agree to share your email address with the site owner to receive latest updates from the blog. Use the unsubscribe link in those emails to opt out at any time.

Processing…
Success! You're on the list.

Finding Your North Star – Creating a Shared Long Term Vision

Posted on by Heli Hiisilä

In the context of agile product management, the term “North Star” refers to a guiding principle or overarching goal that helps align the team’s efforts and provides a clear direction for product development. It is often used to define the ultimate vision or desired outcome of the product.

The concept of the North Star is derived from the metaphor of using the North Star as a navigational reference point. The North Star represents the long-term vision that the team strives to achieve. It serves as a constant reference point that guides decision-making and prioritization throughout the development process.

The North Star is typically a high-level objective that encapsulates the value proposition and core purpose of the product. It should be ambitious, and inspiring – allowing the team to track progress toward the desired outcome. While the North Star provides a clear direction, it also allows flexibility in how the team achieves the goal, as agile methodologies emphasize adaptability and iterative development.

Having a North Star helps the team stay focused, aligned, and motivated, especially in complex and fast-paced environments. It provides a common understanding of the product’s purpose and allows for better decision-making by aligning all stakeholders around a shared vision. Additionally, it serves as a reference point for evaluating the impact of product decisions and prioritizing work to ensure that efforts are aligned with the ultimate goal.

Even though the North Star concept has originated from product management, the same concept and thinking work well for strategic development portfolios and strategic initiatives – the long-term vision and guiding principle providing direction, alignment, and motivation for the team and stakeholders is super important!

Let’s have a look at the steps to identify your North Star!

Steps to Identify Your North Star

1. Understand the purpose

Begin by gaining a deep understanding of your product / development scope, its intended users, and the problem it solves. Clarify the purpose and value proposition. What is the core benefit it provides to users? How does it address their needs or pain points?

This understanding forms the foundation for defining the North Star!

2. Identify long-term goals

Think about the long-term goals or outcomes you want to achieve with your product. These goals should be ambitious, meaningful, and aligned with your product’s purpose. Consider the impact you want your product to have on users, the market, or the industry. Examples of long-term goals could include increasing user engagement, driving revenue growth, or becoming a market leader.

3. How to measure?

To ensure that the North Star is meaningful and trackable, it’s important to make it measurable. Define key metrics or indicators that can be used to gauge progress towards the North Star. For instance, if your goal is to increase user engagement, you could measure metrics like user retention, time spent in the product, or the number of active users.

Tip! Objectives and Key Results could be a great way to include also measurable key results with your North Star.

4. Align with stakeholders

Engage with relevant stakeholders, such as your product team, executives, customers, and any other key individuals or groups. Share your proposed North Star and seek their input and feedback. Ensure that the North Star resonates with their expectations, aligns with the overall business objectives, and reflects the needs and desires of your target users.

5. Iterate and refine

Defining the North Star is an iterative process. Gather feedback from stakeholders, evaluate its relevance and feasibility, and refine your definition accordingly. Iterate on the North Star until you reach a clear, compelling, and measurable goal that aligns with your product’s purpose and stakeholders’ expectations.

6. Communicate and share the North Star

Once you have defined the North Star, it’s crucial to communicate it effectively to your team and stakeholders. Ensure that everyone understands and embraces the North Star’s importance and how it guides decision-making. Regularly reinforce its relevance and progress to maintain alignment and motivation throughout the product development journey.

Remember, the North Star should be an aspirational goal that provides guidance and focus but allows for adaptability and iteration. It should inspire and motivate the team, align stakeholders, and ultimately drive the product’s success.

North Star – examples from leading companies for inspiration

The North Star may vary in wording and specificity across different sources and may evolve over time as companies adapt to new challenges and opportunities. Here are some examples of North Stars from leading companies:

  • Google: “Organize the world’s information and make it universally accessible and useful.”
  • Tesla: “Accelerate the world’s transition to sustainable energy.”
  • Airbnb: “Create a world where anyone can belong anywhere.”
  • Spotify: “Unlock the potential of human creativity.”
  • Amazon: “To be Earth’s most customer-centric company, where customers can find and discover anything they might want to buy online.”
  • Netflix: “Delight our customers with great content anytime, anywhere.”
  • Apple: “Design innovative products that enrich people’s lives.”

Conclusion

Defining an inspiring North star is not easy, and it may require also many discussions and alignment. Having a clear guiding principle and long term vision, the North Star, creates clarity for prioritization and ensures, we navigate to the correct direction, even though daily work may keep us busy with the details.

Finding Your North Star – Creating a Shared Long Term Vision

Posted on by Heli Hiisilä

In the context of agile product management, the term “North Star” refers to a guiding principle or overarching goal that helps align the team’s efforts and provides a clear direction for product development. It is often used to define the ultimate vision or desired outcome of the product.

The concept of the North Star is derived from the metaphor of using the North Star as a navigational reference point. The North Star represents the long-term vision that the team strives to achieve. It serves as a constant reference point that guides decision-making and prioritization throughout the development process.

The North Star is typically a high-level objective that encapsulates the value proposition and core purpose of the product. It should be ambitious, and inspiring – allowing the team to track progress toward the desired outcome. While the North Star provides a clear direction, it also allows flexibility in how the team achieves the goal, as agile methodologies emphasize adaptability and iterative development.

Having a North Star helps the team stay focused, aligned, and motivated, especially in complex and fast-paced environments. It provides a common understanding of the product’s purpose and allows for better decision-making by aligning all stakeholders around a shared vision. Additionally, it serves as a reference point for evaluating the impact of product decisions and prioritizing work to ensure that efforts are aligned with the ultimate goal.

Even though the North Star concept has originated from product management, the same concept and thinking work well for strategic development portfolios and strategic initiatives – the long-term vision and guiding principle providing direction, alignment, and motivation for the team and stakeholders is super important!

Let’s have a look at the steps to identify your North Star!

Steps to Identify Your North Star

1. Understand the purpose

Begin by gaining a deep understanding of your product / development scope, its intended users, and the problem it solves. Clarify the purpose and value proposition. What is the core benefit it provides to users? How does it address their needs or pain points?

This understanding forms the foundation for defining the North Star!

2. Identify long-term goals

Think about the long-term goals or outcomes you want to achieve with your product. These goals should be ambitious, meaningful, and aligned with your product’s purpose. Consider the impact you want your product to have on users, the market, or the industry. Examples of long-term goals could include increasing user engagement, driving revenue growth, or becoming a market leader.

3. How to measure?

To ensure that the North Star is meaningful and trackable, it’s important to make it measurable. Define key metrics or indicators that can be used to gauge progress towards the North Star. For instance, if your goal is to increase user engagement, you could measure metrics like user retention, time spent in the product, or the number of active users.

Tip! Objectives and Key Results could be a great way to include also measurable key results with your North Star.

4. Align with stakeholders

Engage with relevant stakeholders, such as your product team, executives, customers, and any other key individuals or groups. Share your proposed North Star and seek their input and feedback. Ensure that the North Star resonates with their expectations, aligns with the overall business objectives, and reflects the needs and desires of your target users.

5. Iterate and refine

Defining the North Star is an iterative process. Gather feedback from stakeholders, evaluate its relevance and feasibility, and refine your definition accordingly. Iterate on the North Star until you reach a clear, compelling, and measurable goal that aligns with your product’s purpose and stakeholders’ expectations.

6. Communicate and share the North Star

Once you have defined the North Star, it’s crucial to communicate it effectively to your team and stakeholders. Ensure that everyone understands and embraces the North Star’s importance and how it guides decision-making. Regularly reinforce its relevance and progress to maintain alignment and motivation throughout the product development journey.

Remember, the North Star should be an aspirational goal that provides guidance and focus but allows for adaptability and iteration. It should inspire and motivate the team, align stakeholders, and ultimately drive the product’s success.

North Star – examples from leading companies for inspiration

The North Star may vary in wording and specificity across different sources and may evolve over time as companies adapt to new challenges and opportunities. Here are some examples of North Stars from leading companies:

  • Google: “Organize the world’s information and make it universally accessible and useful.”
  • Tesla: “Accelerate the world’s transition to sustainable energy.”
  • Airbnb: “Create a world where anyone can belong anywhere.”
  • Spotify: “Unlock the potential of human creativity.”
  • Amazon: “To be Earth’s most customer-centric company, where customers can find and discover anything they might want to buy online.”
  • Netflix: “Delight our customers with great content anytime, anywhere.”
  • Apple: “Design innovative products that enrich people’s lives.”

Conclusion

Defining an inspiring North star is not easy, and it may require also many discussions and alignment. Having a clear guiding principle and long term vision, the North Star, creates clarity for prioritization and ensures, we navigate to the correct direction, even though daily work may keep us busy with the details.

Do you manage a Portfolio funnel, or Portfolio tunnel?

Posted on by Heli Hiisilä

Smart people with a development mindset contribute to a large amount of development ideas. There may be innovative ideas related to new products and services ideated with customers, new business models to be experimented or process improvements. Also new IT solutions supporting business processes and improvements to existing solutions are typical content of large development portfolios. Strategy driven initiatives may also have significant impact on many different elements, also on operating model and ways of working. In addition to large development initiatives, there are also different types of development ideas to enhance current ways of working via processes or IT systems.

Systematical way to manage Portfolio Funnel

Systematical way of working to track and manage new development ideas is important – not only for budgeting purposes, but not to miss excellent ideas! Agile teams maintain also their own development backlogs, including new requirements, features, or use cases for developing for example an IT solution. Items in the portfolio level should be of a size of a project, or portfolio epic – an item with specific business objectives and typically significant work required from multiple teams.

Portfolio funnel – smart people contribute to a large amount of development ideas

Managing portfolio funnel, not a tunnel

One of the key deliverables of portfolio management process is the support for prioritization of the development ideas in the portfolio level. For all ideas, it is good to do a brief analysis – is this idea viable, and where would this belong to – to be implemented as project or as a part of agile development teams. Also, is the idea something we would like to proceed in a near future, or should we park it?

Prioritization of the development ideas is also needed. Prioritization could happen within regular governance meetings, e.g. monthly or quarterly or during the planning processes such as long range or mid-term planning or yearly budgeting. Saying no to development ideas which are not part of the portfolio scope or priorities is important, to create clarity and focus. Also parking ideas, which are not viable right now, but could be worked in in the future is also beneficial.

Managing portfolio funnel – also saying no or parking ideas is important

What is in your portfolio funnel?

One of the key challenges many organizations struggle with is the pipeline gridlock – there are too many development initiatives ongoing at the same time and nothing gets completed as planned as capacity is too thinly spread across initiatives. Also, if there are many small items consuming time of the development teams, there may not be enough focus on big important items. Key topics to look into

  • How many initiatives and how big initiatives do you have in the pipeline? If there are too many small initiatives in the funnel, difficult to get large important initiatives completed!
  • How many big initiatives can manage simultaneously?
  • What is the available capacity?
  • What are the key constraints? Experts? Money? Would you need to have extra help for for the critical areas, where experts would be needed?
What is in your portfolio funnel – understand the constraints and make space for big important items

The first step to solve this challenge is to create transparency across the portfolio pipeline – this is a great tool for the senior management also to start to work on prioritization.

Portfolio Kanban for visual management

One of the great tools for visual portfolio management is Portfolio Kanban. The idea is, that within portfolio Kanban, you may include different types portfolio level ideas, epics or other initiatives, such as projects, and systematically evaluate the prioritize the different ideas – and see different portfolio items visually via the Kanban board. It is good to keep the Kanban as simple as possible; also Kanban can be used for portfolio idea funnel only, if execution is happening via portfolio roadmaps as a part of different programs, projects and agile development work.

For project stage gate models, the idea is other way around – project has own phases, which are driving the portfolio process. However, also a systematical process is needed for other development ideas, which are not projectized and not following project model.

Tip! Scaled Agile Framework (SAFe) Lean portfolio management includes also Portfolio backlog – have a look, if interested to learn more about how development organized there!

Check out also the latest blog posts!

View all news →

Do you want to get the latest blog updates to email?

By clicking submit, you agree to share your email address with the site owner to receive latest updates from the blog. Use the unsubscribe link in those emails to opt out at any time.

Processing…
Success! You're on the list.

Is Your Development Portfolio Balanced Across Different Time Horizons?

Posted on by Heli Hiisilä

Development is the way to transform company from the current state to the future to-be state. One of the challenges in many portfolios is to focus too much on initiatives developing short term solutions: current products and offerings, existing processes and ways of working. Continuous improvement is super important, but if there is lack of development initiatives building future competitiveness, it is a good time to look if portfolio would need rebalancing.

I will review here some models for mapping your portfolio content based on the different horizons:

McKinsey Three Horizons model

McKinseys Three Horizons model introduced in The Alchemy of Growth (Bahai & Coley, 2000) divides investments into three horizons:

  • Horizon 1 – focus on growing and defending a company’s core businesses to ensure near-term success. Investments are typically well known and there is a low uncertainty. This is a kind of comfort zone for many portfolios – examples of investments could be enhancing existing products and offerings and improving current operating model, and IT systems.
  • Horizon 2 – investments are focusing on scaling new revenue streams, perhaps a bit outside of core offerings with higher investments and longer investment horizons than in horizon 1. New capabilities needs to be built to support horizon 2 investments.
  • Horizon 3 – investments in horizon 3 have high level of uncertainty, high level risk, and often high level of research and development required. These development initiatives could lead to creation of completely new markets for company – and potentially there could be a very high profits available in the future.

Investments into horizon one feel safe – this the comfort zone for many of us – we know this staff well and there is not so much risk. However, if all investment money is spent in Horizon 1, your portfolio may be already late with your Horizon 2 or Horizon 3 investments – too much investment into short term may damage future competitiveness. Some companies have a practice to create own portfolios for Horizon 2 or Horizon 3 investments – to give an own investment bucket for forward looking initiatives.

SAFe Investment Horizon Model – Guiding Investments by Horizons

Scaled Agile Framework has also adapted three horizons model with some enhancements. In addition to horizons 1-3, also Horizon 0 for retiring products and solutions was added – this is good, as it is important to also decommission old solutions. Horizon 1 is also split into two categories: Investing and Extracting solutions. Horizon 2 solutions are emerging next generation horizon 1 products, where as horizon 3 is focusing on new opportunities with longer return of investment time.

Categorizing investments into different horizons is a great tool – as a one time effort or even by adding horizon into your portfolio data.

https://www.scaledagileframework.com/lean-budgets/
Scaled Agile Framework (SAFe) – Guiding investments by Horizon

Exploit and Explore Portfolio by Strategyzer

The idea within Exploit and Explore Portfolios by Strategyzer’s The Invincible Company is to divide portfolio into products, offerings or solutions belonging to either Explore or Exploit portfolios.

Within Explore portfolio, there are new initiatives, perhaps belonging to Horizons 2 and 3. Items are mapped based on the Expected return and Innovation risk – a visual tool to map the different products and services.

Within Exploit portfolio, there are existing products and solutions – perhaps Horizons 1 and 0 might belong here. Items are mapped here based on Return and Death & Disruption risk.

For product portfolios, also product life cycle stages are commonly used tool to balance product portfolio across Development, Growth, Maturity and Decline stages.

Key takeaways – is your portfolio balanced across time horizons?

A good practice for any development portfolio is to check when doing long range planning or yearly budgeting work, how much money you are spending on each time horizon. This is a good agenda item to be also discussed during the quarterly review (See my previous post – Time for a quarterly portfolio review?) If you do not have this information gathered in your portfolio data, this can be done as one-time analysis for example yearly.

Also in enterprise level, this is a good exercise to look into as part of the strategy implementation – how much are our development portfolios spending on developing Exploit portfolio or Horizon 1 and 0, and how much are we investing into future competitiveness?

The balance between different time horizons depends on each portfolio vision, as well as company strategy and risk tolerance.

References

Baghai, Mehrdad, and Steve Coley. The Alchemy of Growth: Practical Insights for Building the Enduring Enterprise. Basic Books, 2000.

Scaled Agile Framework (SAFe) – Lean budgets / Guiding investments by Horizon

Strategyzer – The Invincible Company

Time for A Quarterly Portfolio Review?

Posted on by Heli Hiisilä

Autumn is a busy time in many organizations due to yearly planning. However, development plans tend to change, and typically already in January some parts of the yearly plan require updates. One of the good practices I would recommend for any development portfolio is quarterly reviews.

Quarterly cycles work well in many organizations, as typically financial processes are quarterly based. A quarter is already a long enough time period to see progress happening within portfolio, but it is still possible to also take action, if progress is too slow in some areas or key results are not met. Furthermore, if operational portfolio governance is monthly based, quarterly cycle works well for tactical or strategic portfolio reviews.

In addition to portfolio level governance, quarterly cycles work well for hybrid portfolios including projects and agile work. Agile teams have often quarterly planning practices, and there may be needs to support planning with portfolio level decisions and prioritization.

Quarterly portfolio review – WHY?

Here is a list of why quarterly portfolio reviews may be helpful – but also a checklist for you to think for your own context:

Transparency and visibility

  • Reviewing roadmaps & progress – how are we doing?
  • Reviewing portfolio funnel of new ideas – what is new in the pipeline?
  • Managing dependencies and alignment across initiatives
  • Communication towards larger stakeholder group – creating transparency among the stakeholders
  • How are we doing with portfolio finances?

Optimizing portfolio

  • Optimizing and balancing portfolio content – is current portfolio reflecting strategy, and support future competitiviness?
  • Feedback loops to business case updates & following up on benefit realization
  • Killing projects or putting projects on hold if needed

Adapting to changes

  • Adapting to changes in market environment
  • Prioritization of new initiatives
  • Allocation and reallocation of frames
  • People side of the change – identifying focus areas and portfolio level impacts

Planning capacity

  • Sequencing & prioritization of large initiatives to enable good resourcing
  • Scaling capacity as needed based on future demand
  • Ensuring resourcing for cross unit/function development initiatives
  • Leaders supporting teams removing obstacles and ensuring resourcing

Continuous improvement

  • Sharing key learnings from the portfolio – key takeaways from projects or programs
  • Sharing good practices & ways of working
  • Feedback loop to improve portfolio practices – where to focus on, what to end, what to keep doing

Quarterly portfolio review + quarterly planning for teams

Quarterly cycles are great also for development teams to look into roadmaps, aligning on priorities and balancing demand and capacity. Many agile teams also have quarterly planning practices to prioritize back log and to plan for the next quarter development work.

If teams have quarterly planning practices, good steps may include 1) Preplanning, 2) Planning with teams, 3) Quarterly portfolio review. Sometimes the order or portfolio review may be before the teams planning – what would be the best order for you?

Focus areas & agenda for quarterly review?

Quarterly review agenda may be planned based on the yearly portfolio clock. For many organizations, Q2 review could be focusing on long range planning, whereas Q4 review could be celebrating current year successes and next year plans. It is also important to keep benefit realization in the agenda, so that could be a focus area for Q3 and Q1 reviews.

All portfolios are unique – for a large and complex portfolio quarterly process may include many meetings to clarify plans and align with the stakeholders, as well as own meeting focusing on decision making. For smaller portfolio, review may be also much lighter checkup – are we reaching our key results, how are with benefit realization, and do we need to change priorities. Here is an idea, what your agenda could look like for portfolio review:

I would love to hear also what works for you – let’s get in touch!

Additional reading

Scaled Agile Lean Portfolio Management – Strategic portfolio review practice as a reference!