-
The most popular blog posts from 2023, event recordings and online courses available

It is time to wrap up the year 2023 – and thank all the readers of the blog and experts joining the online courses and events during the year!
Dadaa, here is the top three from the blog with most views globally:
3rd place: Developing Strategic Portfolio Management Practices step by step

This is one of the articles, where I receive most contacts from the experts around the world. How to develop Strategic Portfolio Management Practices step by step?
Developing strategic portfolio management practices step by step
During the Spring, I had an opportunity to participate to Itonics Innovation Brunch – Check out the key note Improving Strategic Portfolio Management Maturity Step by Step.
2nd place: 4 Goals of Portfolio Management

No wonder this post has become popular – portfolio management is challenging by nature, as it is dealing with future events and opportunities – check out the 4 key goals of portfolio management from the blog:
4 Goals of Portfolio Management
1st place: Do you manage a portfolio funnel, or Portfolio tunnel?

This is also one of my favorite ones – and one of the most trickiest parts when managing a complex development portfolio – have a look:
Do you manage a Portfolio funnel, or Portfolio tunnel?
Webinar – Ready, Steady, Go!
One of the fun events during the autumn was the webinar we co-hosted with wonderful Caroline Bondier. If you missed it, have a look: Leading Strategic Initiatives Webinar with Caroline Bondier from Articana
Time to wrap up 2023, but let’s catch up during 2024!
-
Building a modular offering portfolio – just a dream?

Is your offering portfolio well organized or do you have a big number of individual offerings? What I am hearing a lot, not all companies have well structured offering portfolios, due to large range of product families and a big number of solutions and services.

I love the idea of modular offering portfolio, where products and services may be bundled into offering packages based on the customer needs and preferences. Modular design is an important principle in product design and IT architectures, but the same idea applies well also for offering design. Let’s review different approaches to build modularity into offering portfolio!
Offering bundling of product based solutions and services
Today, many products and solutions have become more and more complex, including physical hardware products or components, as well as software and sometimes even digital services. The terminology varies from company to company, but often solution layer is often used to combine products and services as solution, which is helping to solve a customer problem and creates customer value.
In addition to a solution itself, there may be additional services, such as delivery, installation and commissioning as well as training and technical support completing the solution itself. The solution and complementing service are often delivered as one-time transactional offering package.
There are many types of services, such as core services (basic maintenance and repair services) or advanced services (e.g. complex digital services), and different service elements may be bundled into the same offering package. Sometimes also services are referred as products or service products.

To summarize, offering can be a combination of products/components/solutions and services, with the common value propositions offered as a package towards customers. Do you have a common definitions in your organization for what is meant by offering, products, solutions and services? Without to go to too academic discussions, it is good to have
Bundling offering packages based on modular products, and services to support different customer needs
When thinking about modular offering, offering is composed of different independent modules, such as products and services. The same product or service may be included in many different offering packages, which may be designed to meet different needs of the customers. Modularity of offering may for example enable different types of service levels for different customers or tailored offering packages for different customer segments with differentiated value propositions.

Same services may be bundled based on the business model customers preferences
Customer may prefer different business models during the different life cycle phases, and some customers may prefer transactional purchasing, where as other prefer more predictable agreement based models. With the modular offering portfolio, same service elements may be packaged in a different ways based on the customer preferences.

Further reading:
Check out also previous post, which might be interesting: Ideas To Build Offering Portfolio – Which Offering Portfolio Dimensions Are Relevant For Your Organization? – Strategic Portfolio Management (strategic-portfolio-management.com)
-
Developing new products and services – are there differences?

How does the development of physical products differ from development of services – or does it differ? In the context of New Product Development (NPD), portfolio management has been studied a lot during the past decades in order to optimize the product portfolio. However, I was interested in learning more about New Service Development (NSD), and noticed, that this area has been studied less.
I found an amazing article by Aas, Breunig and Hydle: Exploring new service portfolio management (International Journal of Innovation Management,2017) and wanted to reflect on the key insights via the blog! Based on the literature summarized by Aas et al., there are indeed some clear differences:
- New Service Development processes are often more incremental, informal and ad-hoc than New Product Development processes
- A higher number of stakeholders are involved from different units and functions during the new service development, than in NPD processes
- The effects of NSD on business performance have more intangible, strategic, long term and qualitative nature than the effects of NPD
Let’s have a look in more detail, what were the key lessons learned from the case study:
Many sources of ideas for new service concepts

Typically for new services, ideas come from a big number of different sources, such as customers, own employees from different units and functions, suppliers, competitors, and sometimes also from government. The ideas may be of different sizes, and of different nature ranging from development of new digital services to improvement of operational service process steps or compliancy to regulation or improvement of existing service offering. In the portfolio level, prioritizing such a wide range of different types of ideas from different sources is not always easy – how to compare ideas with can range from operational improvement to completely new service concepts?
Lessons learned 1: The recommendation from the article by Aas et al. (2017) was to exploit different sources of ideas and base New Service Development portfolio decisions on both strategic alignment and value criteria. This helps to create a balanced portfolio, and not to focus too much on just one type of ideas, e.g. ideas improving internal efficiency.
New Service Development is often hidden and based on small changes – creating transparency via NSD portfolio

New product development (NPD) has been traditionally executed via stage-gate projects ensuring all the needed steps to develop high quality products. Based on the study by Nijssen et el. (2006) New Service Development (NSD) is often ad-hoc and hidden – not clearly visible in the development portfolios. Continuous improvement is extremely valuable – however when developing a completely new type of service concepts or radical innovations, development work requires typically a lot of work across the organization and extensive resourcing.
Lesson learned: Accelerating new service development by transforming ideas into formal New Service Development projects, in the early phases of the development. Based on my own experience, a projectized approach often helps to create awareness in the organization, supports with the resourcing and systematic decision making. If development is happening via agile teams without projects, for a new service development, I have learned, that it is a good practice to have certain check points, to ensure end-to-end quality and readiness before Launch decisions. Creating overall transparency on ongoing NSD initiatives and their progress is also important in large organizations.
Flexibility in development process and decision making needed

In the study, one finding was, that NSD projects were often incremental by nature, and smaller than typical new product development projects. Larger NSD projects required also typically several decision gates, before Launch readiness, and project model was close to Cooper’s ‘state-gate-lite’. Also the NSD projects had a high level of heterogeneity, as the development ideas varied a lot, and one process did not fit all the different cases.
When developing new services, there may be changes in parallel in service concepts, technology, organization and processes. For example, when working with new digital services development projects, there has been a need to introduce new roles and processes to support the service management of the new services.
Lesson learned: The NSD portfolio process requires flexibility to successfully support the high heterogeneity in the new service development projects – one way does not fit all types of projects.
Involving many stakeholders

When developing new service concepts, support and participation from many different units and departments are needed. New service development often impacts long end-to-end value and process chains, and the alignment between different teams is important to create a successful concept. Based on the study, also in the decision making, representatives from different functions and units were involved in the NSD portfolio steerings.
Lesson learned from the study: NSD portfolio decisions need to be taken in collaboration by a group of managers representing different functional areas. I would also add, that involving stakeholders from different units during the project, creating alignment and awareness across different teams is super important, not only in the managerial level.
Developing a combination of products and services?
I have also worked with combination of products and services, for example solutions where a physical hardware is supporting a digital service. In these product-service-software solutions, complexity of both worlds are combined: there needs to be systematical way of working to support developing a high quality product, but the development process should also support iterative learning required in service development processes! These interesting product-software-service solutions would deserve an own blog!
References
Aas, Breunig, and Hydle: Exploring New Service Portfolio Management. International Journal of Innovation Management, 2017.
Nijssen, EJ, B Hillebrand, P Vermeulen and RGM Kemp (2006). Exploring product and service innovation similarities and differences. Research in Marketing, 23, 241–251.
Fuglsang, L and F Sørensen (2011). The balance between bricolage and innovation: Management dilemmas in sustainable public innovation. The Service Industries Journal, 31(4), 581–595.
-
8 Key Reasons for Moving Towards Service Oriented Business Models and 5 steps to get there!

This autumn, the blog theme has been service offering development and this week’s blog is focusing on transition from product orientation to service orientation. From the strategic portfolio management viewpoint, building a solid service offering portfolio truly makes sense – let’s review key reasons why (especially) manufacturing companies are shifting more and more towards services and also the most important steps how to get there:
8 Key Reasons for Moving Towards Service Oriented Business models
Revenue generation – from one time product sales to continuous revenue streams

Service business is typically good business – instead of relying on one-time transactional product sales, services may provide steady and growing revenue streams through service contracts, subscriptions and additional transactional service offerings. The recurring revenue models provide also more stability and predictability when compared to the traditional product-based models.
Building competitive advantage – and avoiding commodity trap

Today, markets are highly competitive, and manufacturing companies are looking ways to differentiate. New types of value adding services are often helping to differentiate from competitors competing with lower prices. Services built into the operating model of the company are not as easy to imitate or copy, as the the traditional production of hardware based components.
Value adding services for unique customer experiences

Offering value-added services alongside their products allows them to stand out and provide unique customer experiences. Additional value may be created in many different ways, for example:
- Via highly reliable delivery and installation
- Integrations between the company core systems
- Easy to deal with service concepts
- Providing new type of data based services with insights
- Digital services with new unique features built on top of physical products
Value adding services help to build stronger relationships with customers and creates a competitive advantage that is not solely based on the physical product.
Increasing customer satisfaction and retention

By offering services complementing the products, manufacturing companies can enhance customer satisfaction. Services such as installation, maintenance, repair, and training can improve the overall customer experience and ensure that the products perform optimally throughout their lifecycle.
This, in turn, leads to higher customer loyalty, repeat business, and also to positive word-of-mouth recommendations.
Adapting to changing Market Demands

Many customers today prefer outcomes and solutions rather than simply buying products. By offering services that address specific customer needs and challenges, manufacturing companies can align themselves with market demands and provide comprehensive solutions that go beyond the product itself.
Supporting customer sustainability targets

Service-oriented approaches often contribute to a more sustainable business model for manufacturing companies. For example extending the lifecycle of products through life-cycle services such as repair and refurbishment or product upgrades, may reduce significantly environmental impact. Also for example selling as service business model may help to offset the financial costs of implementing more sustainable solutions
Leveraging opportunities enabled by technology

Today, technology enables new solutions including for example predictive maintenance, remote monitoring and other proactive services, which can help to optimize product performance and efficiency and also minimize downtown. Key enablers for such services may be the Internet of Things (IoT), sensors based solutions increasing the availability of data, connectivity solutions, and different types of integrations and interfaces. Also Artificial Intelligence enable more automation and value adding insights.
Value via Ecosystems and Networks

Ecosystems and value networks play a crucial role in the service orientation of manufacturing companies. By participating in ecosystems and building value networks or even leading one, manufacturing companies can leverage the expertise and capabilities of other entities within the network creating value add to customers.
5 steps when moving from product orientation to service orientation
When transition from product orientation to service orientation, there are significant impacts also in the strategic development portfolio, operations, way of working and even in organizational setup. I would recommend to get familiar with a super good article written by Daniel Kindström: Towards a service-based business model – Key aspects for future competitive advantage. Here are some key takeaways I picked up from the article to support moving from product based to service oriented approach:

- First of all, strategic direction for service offering is required – are you complement the product based offering, creating completely new type of digital services, or what type of services and customer value do want to focus on?
- The mindset shift from product centric to customer centric approach is required when working with new service offering concepts solving customer problems. This may be a long journey for many organizations with long traditions of building world class hardware products.
- The service development process differs from product development process – what is your process to develop services? Do you need to develop both product based offering and services together?
- Introducing service based business models – what is it for customers, what are the value propositions and how is the revenue created? Is the model transactional, agreement based, selling as a service / subscription based, or is the value created via the partner ecosystem…?
- Setting up service organization – who is delivering the service? For example, do you need to setup new processes and roles, when supporting new digital services? Do you need to create a network of partners and vendors to support your services?
Overall, the move towards a service orientation allows manufacturing companies to go beyond the traditional transactional model and build long-term relationships with customers. Services provide opportunities for revenue growth, customer satisfaction, and adaptation to evolving market dynamics, ultimately leading to a more competitive and sustainable business.
However, also new capabilities, ways of working, business models and even organizational structures are required – introducing a new service offering may require development and change management in many different levels. The service-based business models would deserve an own blog post, so stay in the loop!
References
Kindström, Daniel: Towards a service-based business model – Key aspects for future competitive advantage. European Management Journal (2010) 28, 479-490.
-
Do You Hear Laughter? Tips for Creating Psychological Safety for Development Teams

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

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.
-
5 + 5 + 5 Tips for making better portfolio decisions

Portfolio governance meetings have often tight agenda’s – there may be many decisions to be made, and complex topics. Smooth decision making requires systematical work – good preparation, discipline and focus during the meetings and also systematical follow up work after the meetings. To help different roles shine, here are 5 tips for facilitators, 5 tips for presenters and 5 tips for steering group participants. Have a look!
5 Tips for the Facilitator – Helping The Presenters Shine!

- Prepare presentations and materials with the presenters – communicate clearly when the materials need to be ready, review and coach also the presenters, so that they can shine during the meeting and the flow of decisions will be smooth!
- Send out agenda and prereading material 48 hours before the meeting. This is especially important, if you have big decisions on agenda.
- Keep the meeting schedule – be clear on time slot planned for each presentation and politely also remind of the slots. It is fair to give all presenter’s their slot.
- Summarize the decisions and key conclusions and share the meeting minutes within 24 hours after the meeting – it is good practice to share the meeting minutes when the participants still have fresh memories on the discussions.
- Follow up on action points systematically after the meeting. I think this might be the trickiest part, but also perhaps most important one!
5 Tips for Presenters – Prepare well, present clearly

- Provide the prereading material on time. Often, a good practice is to provide the materials 48 hours before the meeting – so align on the schedule and meeting practices with the meeting facilitator.
- Be clear with your decision proposal – are you looking for a decision, guidance or support – or is your presentation an update?
- Keep your presentation time slot – if you have 10 min presentation slot, do not come to the meeting with 20 slides! You can always have backup or additional prereading materials, as needed.
- You can ask kindly to take the questions at the end of the presentation, so that you can go through the material without interruptions
- If you are unclear with the decision – be brave and ask for clarification. Usually if you did not get a clear decision, other participants have the same challenge.
5 Tips for Steering Group Members – Give your full focus

- Read the prereading materials in advance, and collect also feedback from your organizations as needed
- Give your full focus on topic – join on time, focus fully on presentations and don’t multitask
- Be an active participant – Ask questions, and give your guidance and comments, but also listen to other view points and presentation carefully
- Support decision making – help facilitator and presenter to reach to a conclusion
- After the meeting check the meeting minutes and your action points, and communicate the decisions with your own organization.
Further reading
-
What Do You Call Your Agile Teams?

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
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.
Check out also the latest blog posts!
Do you want to get the latest blog updates to email?
Processing…Success! You're on the list.Whoops! There was an error and we couldn't process your subscription. Please reload the page and try again. -
10 Ways How Business Agility Transforms Strategic Development Portfolios

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!
Do you want to get the latest blog updates to email?
Processing…Success! You're on the list.Whoops! There was an error and we couldn't process your subscription. Please reload the page and try again. -
5 ways to improve go-to-market of new offering

Previous blog post was focusing on important of deployment and people side of the changes (Don’t Forget Deployment!). Strategic development portfolios include also often development of new offerings, products, and services. How about the deployment of a new offering? What kind of approaches may work there?
It has been fun to work again more with offering development! One of the key topics for offering development teams is to ensure a successful go-to-market for the new offering. This is actually quite tricky – how to ensure busy sales teams get familiar with the new offering and feel comfortable and motivated to sell – especially if the new offering is outside the comfort zone of the sales force.
I have been working with many different types of offerings, some with complex hardware solutions, and some other purely service based. I will share 5 ways which I have seen have been useful, I hope this is helpful!
1. Offering catalog & news letters
When the offering is standardized, and familiar to organization and there are only small changes to way of working, well maintained offering catalog and news letter may work well to keep organization up-to-date.

An electronic version of the offering catalog works best, and with large offerings, there should be great searching functionalities to find easily what is needed.
Newsletter could include the following highlights:
- What is new? And where to find additional information?
- Pricing guideline updates
- Sharing value proposition for new offering
- Sharing learnings and tips related to sales of new offering
- If there are any actions to be taken locally
- Targets for sales
The challenge with the news letters in large organization is how to reach the correct people and to ensure busy sales and offering management personnel have time to actually learn what is new.
2. Community of practice

Communities of practice are one of the great approaches to keep the stakeholders engaged with the development, share learnings and feedbacks from the markets. Communities of practice are great for new growing areas, where content is further developing, and there are rapid cycles for learnings, but also for mature areas. Participants may join to community of practice from many different locations around the globe virtually to meet people with similar role and interest in other locations.
Optimally communities are not only information-sharing channels to introduce new changes, but also a forum to share learnings peer-to-peer and get expert advice as needed. A common platform or channel for discussion may be helpful especially when working with geographically distributed teams, to bring people together. Asking and commenting should be easy, and there should be also experts to find the answers even to tricky questions! Communities of practice are also great for onboarding new team members – it is great to be able to ask from other more experienced colleagues.
There may be for example community calls, to gather together to share best practices and discuss timely topics. Planning the content and facilitating for the community requires always some work, but is often worth the trouble!
Community of practice approach works well also for digital services, where there may be frequent releases happening bringing small changes.
3. Offering release

The third approach, which can be also combined with the first and second approaches is to consolidate all new offerings into offering releases. The frequency of offering releases may vary, and could be held quarterly, bi-annually, or annually, depending on the need and organization’s ability to absorb new offerings.
The benefit of offering releases and dedicated info sessions is to bundle offering changes together so that it is easier to get information on all new things at the same go. Release package may include for example training package, which can be used also for local trainings, as well as new beautiful marketing materials, as well as needed technical documentation.
4. Offering Launch

We have all seen beautiful offering launch events from different companies, e.g. Apple or Tesla. Offering Launches are great for public relations and to create excitement among the customers, but may be also a powerful tool to create excitement within customers, and media, but also among the own organization. Offering launches are also great kickstarts for marketing campaigns.
Offering launch alone is not enough, though! When introducing a completely new type of offering, rollout projects may be needed, too.
5. Rollout project

When introducing completely new type of offering to markets, there may be a need to develop many different capability areas within organization. Setting up a rollout project to ensure good training, change management, go-to-market, sales and operations may be a good choice, when:
- Significant changes for local roles, e.g. new activities needed for sales roles, customer service or operations roles
- New supply chains built to support completely new type of offering
- Organization requires extensive training to sell, install, maintain or service new offering
- New IT tools are needed for example to support sales and operations
- New pricing model, new business model configurations or
- New Go-to-market approach is introduced
- Local legal requirements, or area specific standards
Within rollout projects; this was covered in the previous post (Don’t Forget Deployment!).




