Posts Tagged ‘Product’

These are some product principles that help me make decisions:

  1. We listen to our customers daily, have empathy for them and act on key insights
  2. We understand the market and our customers needs
  3. We work with the rest of the business together to solve the highest priority problems and opportunities in a lean way
  4. We build quality products and features which customers love; recognising that delivering customer satisfaction will grow the business
  5. We have clear product ownership where we are empowered to deliver excellence aligned to the business goals
  6. We trust by giving autonomy at every level across the product delivery lifecycle
  7. We spend time celebrating successes and continuously learn
  8. We acknowledge that there is no bad question or wrong answer and have an inclusive mindset
  9. We see mistakes and failures as a learning experience
  10. We have a strong product organisation, which enables us to achieve our ambitions

Product Owner is a job role that came out of Agile and Scrum, and although many organisations use it as a job title that is interchangeable with Product Manager, it’s not correct. In Scrum the Product Owner is defined as the person who is responsible for grooming the backlog, in Agile it was defined as the representative of the business, and neither entirely describe the full breadth of a Product Manager’s responsibilities.

Product Owner is a role you play in an Agile team, whereas a Product Manager is the job title of someone responsible for a product and its outcome on the customer and the business.

Now a lot of Product Owners out there are great Product Managers, and they should just change their title. But a fair number of Product Owners have simply completed a certified Scrum product owner course and now think they’re equivalent to a Product Manager, which sets them up to fail as they never consider the broader role. So if you’re tasking a Product Owner with the broader product management responsibilities, make sure you provide the training they need to master the full breadth of the role (and then change their title).

Enjoyable short read, where Roman Pichler describes the key product leadership challenges, along with ways to use your heart and mind to work effectively with the dev team and stakeholders to create value together.

Roman talks about mindfulness and the leadership-related gains for product people it can have such as greater serenity, increased empathy and better decision-making.

To focus on the important, but less urgent work you need to “be willing to set boundaries, say no, and let go: You can’t do everything without either neglecting your core responsibilities or sacrificing your health, neither of which is desirable.”

But also success doesn’t happen by magic, as Roman explains that “in addition to embracing a can-do attitude, achievement requires effort and discipline. The better we want to become at something, the more effort we have to invest.”

Leaders need to “be a role model and exhibit the behaviour you want to see in others. Listen empathically, speak truthfully and kindly, and make an effort to be open-minded.”

A must read for both new and experienced product people.

This colossal 786 page desk reference provides a fantastic perspective for professionalising Product Management, inspired by Steven Haines vision for this profession.

Throughout the book it focused on a Cross-Functional Product Team, which most people would immediately think would be just a PO/PM and dev team, but instead it was refreshing to see product in the centre of the whole organisation and that product team including someone from marketing/sales, customer service, operations, development, legal…..also in my experience when a product manager brings this team together is where the magic happens.

Steven explains regardless of development methodology, it’s important to remember that the product manager is in charge of the product’s business, not just the product’s functionality, design or features.

“No one will bestow Product Management leadership on you. It is yours to own, to internalize, and to practice”

“Product Managers will earn greater levels of credibility across the organization when they understand and act on proven facts and relevant data”

This book will remain on my desk and I’d recommend it to any ambitious product manager.

A very timely book by Marc Abraham with Covid adding more tension to everyone’s lives.

Whilst it does take experience and confidence before you can lean into tension effectively, Marc explains that embracing tension is also not easy, but it is absolutely worth it!

Marc explains the benefits of ‘accepting radically’ with tips on how to allow your mind to accept things for what they are (and aren’t), so that you can focus your mind and energy on things you can change which result in more productive outcomes.

“Tensions are inherent to products and that we as product people should find ways to embrace that”

“Pressure is an integral part of life, work, being. We might as well accept this tension, starting with a full awareness of how we perceive tension and how others around us view our perceptions and behaviours”

“When curiosity is combined with passion in the exploration of a subject, an individual may be able to acquire an amount of knowledge comparable to that of a person who is exceptionally intelligent”

“Keeping on top of your product means continuous learning and improvement, with a relentless focus bettering your ways of working”

You can’t get a more comprehensive book on product leadership than this by Richard BanfieldMartin Eriksson & Nate Walkingshaw, where they explain in detail what it means to be a product leader, how they launch great products and build successful teams.

“For many product leaders, work life is a constant tension between delivering value to one group and telling another they can’t have what they want. Shipping product, and its associated value, is the reason these product leaders get up and go to work”

“It is not about individual success, it’s about getting the best out of others”

“What is common in high-performing teams is that they are cross-functional, collocated and autonomous”

How to identify product leaders:

🔸️ Plays well with others
🔸️ Seeks challenge
🔸️ Gets their hands dirty
🔸️ Always acts and thinks “team first”
🔸️ Is comfortable wearing lots of hats
🔸️ Displays curiosity
🔸️ Communicates well
🔸️ Possesses selling skills
🔸️ Has exceptional time management skills
🔸️ Is a visionary
🔸️ Shows equanimity/grace under fire

This has to be the best book I’ve read on product management. I loved the way Marc Abraham has put his heart and experience into every chapter making it extremely authentic and realistic when talking about the different techniques and the challenging scenarios that a product manager often faces.

The book has a good structure to each subject which includes the goal, related tools and techniques to consider, in-depth look, key takeaways and how to apply these takeaways.

Marc explains “Product Janitors..

..because product management can be such a broadly defined role, there is a risk that product managers end up doing a bit of everything-mopping up the things that other team members do not want to do..
..as a result, these product managers are unable to act effectively, by which I mean they fail to identify and manage products that are valuable, usable and feasible”

“When you spend more time talking to ‘internal stakeholders’ than your customers, you’ve lost the ship”

Another nugget from this short read “if I had an hour to solve a problem I’d spend 55 minutes thinking about the problem and 5 minutes thinking about the solutions”- Albert Einstein

Want to know more about the product manager role?

New to product management?

Stuck spending most of your time on tactical work and need a recap on the fundamentals of being a product manager?….

…then I’d recommend this book by Josh Anon where he’s written a really good comprehensive guide to becoming a great product manager.

The way this book uncovers the key capabilities that drive improvements in software delivery performance is brilliant.

It was interesting to read the science behind the research findings and the rigorous research methods used which was predominantly done by surveys, which I’m a big fan of.

I’d definitely recommend this book by Nicole ForsgrenJez Humble and Gene Kim

Agile

Whilst Agile frameworks such as Scrum and Kanban are a great way of taking steps towards becoming more Agile, it’s important to remember amongst their own principles and guidelines, that the ultimate objective is to deliver customer value/the product vision in an efficient and competitive way.

To help avoid losing sight of this objective and falling into the trap of obsessing about the intricate details of the frameworks too much, it’s important that gap analysis is done frequently on the actual Agile manifesto and principles themselves to see how you can shape the Agile framework to achieve agility and the real benefits of being Agile.
The 4 Agile Values/Manifesto

  1. Individuals and interactions over processes and tools
  2. Working software over comprehensive documentation
  3. Customer collaboration over contract negotiation
  4. Responding to change over following a plan

The 12 Agile Principles

  1. Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
  2. Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.
  3. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
  4. Business people and developers must work together daily throughout the project.
  5. Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
  6. The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
  7. Working software is the primary measure of progress.
  8. Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
  9. Continuous attention to technical excellence and good design enhances agility.
  10. Simplicity–the art of maximizing the amount of work not done–is essential.
  11. The best architectures, requirements, and designs emerge from self-organizing teams.
  12. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

How Spotify have adopted Agile

Strategy

VMOST = Vision, Missions, Objectives, Strategies and Tactics

Each product should have a clearly defined product vision, KPIs and strategies if it’s expected for the development team to deliver outcomes/head in the right direction, and using the VMOST canvas is an effective way of showcasing what these are in a clear and concise format.

VMOST example

Vision: A passionate and exciting statement which typically should only be one sentence, where in a nutshell it should explain what your ambition is/what is your end goal of the product and who it’s for. More info on creating a compelling product vision can be found here.

Missions: In order to achieve the product vision, there would be multiple high-level missions you need to go on – what are the biggest problems which need solving before achieving the vision.

Objectives (KPIs): You can track progress of your missions through setting multiple objectives (aka KPIs), which would include metrics which are measurable.

Strategies: Initiatives which would deliver/impact the objectives (KPIs).

Tactics: Multiple ideas (Epics) which would deliver each strategy. The tactics should be laid out on the product roadmap, so there’s a nice link between the product VMOST and product roadmap.

Although the product manager is responsible for defining and owning the product VMOST, it’s important that it doesn’t happen in silo, as it takes collaboration with the rest of the business especially stakeholders/data/customers/tech to help provide some guidance on the selection of problems to solve which would be represented on the VMOST.

Once the VMOST is ready, it’s time for the product manager to showcase this in a passionate way across the business and perhaps print it out on A0 to sit near the dev team on the wall, so it can always be top of mind.

Good luck in creating your VMOST!!

Devops

Development effort isn’t cheap, but extremely valuable no matter what industry you work in, so once a product iteration is ready to ship, automating the final steps including the software build, deployment, environment and release process will help continuously deliver customer value in an efficient way without unnecessary delays or bottlenecks.

DevOps is the combination of cultural philosophies, practices, and tools that increases an organisation’s ability to deliver applications and services at high velocity: evolving and improving products at a faster pace than organizations using traditional software development and infrastructure management processes. This speed enables organisations to better serve their customers and compete more effectively in the market.” – AWS

There’s often a significant amount of thought and effort which goes into getting an idea into development, so when the code (solution) is ready to kick off the build (ship) process, it’s important that this is as automated as possible to avoid unnecessary delays with customers getting hold of the feature within a timely fashion.

Due to the rise of the DevOps culture, it’s now possible to automate the whole build, deployment and release process. As well as customers getting features sooner as mentioned above, other benefits of adopting a DevOps culture includes:

  • Software Development division remaining competitive
  • Reduction in waste from having to wait for software to build, deploy, dealing with environment issues and working with the operation team to handle the release
  • Increasing the R in ROI (Return on Investment) as less waste results in delivering more value to customers
  • Improving team morale – dealing with environmental, build and release issues manually isn’t fun
  • Improving on sprint goal complete rates as it’s less likely stories will drag over to multiple sprints because of build / release issues
  • Decreasing lapsed time of development work
  • Improved security
  • Easier to track build to release timeframe
  • Automated
  • Scalable

Adopting a DevOps culture should ideally come from bottom up rather than top down – a Product Owner shouldn’t need to create stories, sell in the importance of it to dev teams or prioritise it, as optimising the software build and release process should be BAU (Business as Usual) and should always be constantly looked at and improved.

As development teams adopt a DevOps culture and they start migrating over to a fully automated process, the benefits will be obvious and lucrative.

Less

LeSS (Large Scale Scrum) is an agile framework for 3-8 Scrum teams, but when there’s more than 8 Scrum teams it’s time to think about adopting LeSS Huge. So let’s look at the differences.

LeSS
LeSS is a scaled up version of one-team Scrum, and it maintains many of the practices and ideas of one-team Scrum. In LeSS, you will find:

In LeSS all Teams are in a common sprint to deliver a common shippable product, every sprint.

LeSS Huge

Less-huge

What’s the same as the smaller LeSS Framework:

  • One (overall) Product Backlog
  • One Definition of Done
  • One Definition of Ready
  • One (overall) Product Owner
  • One Sprint

So what’s Different?

  • Area Product Owners
  • Area Product Backlogs
  • Area Product Vision
  • Set of parallel meetings per Area

It’s important to remember that these frameworks are just guides and every business has their own org structure, so it’s completely acceptable to mould a framework to suit the organisational structure and industry sector.

Capacity

If a product is to be sustainable, tech fit, compliant and competitive it needs to have a short and long term development capacity strategy which will help to ultimately deliver the product vision.

Not having enough capacity could mean spending months / years only focusing on upgrading software versions / maintaining legacy technology or meeting regulatory requirements – not making any significant progress on getting after the product vision or surpassing competitors, having too much resource could mean that another product in the business could deliver a higher return with that resource instead, but having the right amout of capacity is important.

The product having the right amount of capacity should mean it’s possible to get after low hanging fruit, maintaining current tech whilst also concurrently getting after the next generation technology (product vision), meeting security / compliance requirements and having resource to experiment.

Understanding what the right amount of capacity should be isn’t easy, but a capacity planner will be able to help. A capacity planner should ideally be driven by points and velocity, so that no matter where the feature is on the feature pipeline (received a high level t-shirt size or has been broken down into stories) it’s possible to easily update the capacity planner with a more accurate estimate as the feature goes into development.

The data you’d typically need to lay out in a spreadsheet in order to effectively capacity plan includes:

  • Date (by month)
  • Team velocity – ‘Points to Allocate to Features’ (which already takes into account average sickness, holidays, ceremonies, breaks, training etc)
  • Forecast of future velocity based on an increase / decrease in capacity eg. Are you planning on adding another team to the product in 4 months time?
  • List of features
  • Estimates (in story points) against each feature
  • Priority order of features
  • ‘Points Remaining’ which is calculated as you start filling up the spreadsheet

It’s totally possible to roughly estimate future features by dev sprints, team sprints or man days instead of points as long as you convert it back to points after knowing how many points a whole team burns each sprint (velocity).

Another reason why it’s essential to have a capacity planner is that based on when features start and finish on the plan will drive the product roadmap dates making the roadmap data driven.

Having a capacity planner available is also a handy report when demonstrating to stakeholders that when features are in the correct priority order and once capacity has run out for a given month, then there’s no more room to slip in anymore work and it’s a case of being patient or changing priority / increasing capacity.

Basics

As a product scales there would often be an increase in capacity / scrum teams working on that product, enabling multiple features to be worked on concurrently, which would be a sensible time to review whether it’s time to adopt the LeSS (Large Scaled Scrum) framework.

As there are some additional elements involved in LeSS vs. Scrum including:

  • All of the Scrum teams work as one team, from one product backlog and with one Product Owner to deliver common goals
  • Having a joint sprint planning with members of each scrum team to decide on what product backlog items (PBIs) to commit to delivering in the next sprint
  • Overall Backlog Grooming (OBG) where members of each scrum team decide on what PBIs to assign to what teams, so they know what features to groom and get in a ready state for an upcoming sprint
  • Overall Retrospective where members of each team discuss highlights from their individual team retrospectives with the aim to learn and improve on how the whole team operates

It’s important to ensure that the Scrum teams have mastered the key elements of Scrum before considering using the LeSS framework, so before moving over to LeSS, see how you’re doing against the below questions:

  1. Are the teams using velocity to measure whether process changes they make are improving their productivity or hurting it?
  2. Are fast estimation sessions happening frequently so that the product backlog has rough estimates?
  3. Is it easy to predict when software will be delivered for the current and future projects based on the backlog being sized?
  4. Are sprint burndown charts monitored every day?
  5. Is analytics part of the definition of done?
  6. Is there a strong DevOps culture in all of the teams?

If the answer is ‘no’ to any of these then perhaps it’s a bit too early to adopt LeSS.

Pipeline

With a long list of ideas / problems (features) to solve, there needs to be a solid view of exactly where features are in the idea to customer flow, so that anyone can view the status of a feature anytime without constantly asking.

Having a ‘feature pipeline’ report also proves helpful when providing stakeholder monthly / quarterly product updates.

A feature pipeline typically has multiple columns similar to a Kanban view, but it’s important to keep the content at a high- level (feature / epic) rather than stories.

Pipeline

Example Feature Pipeline Format

Some of the columns you’d have on a Feature Pipeline would be:

  1. ‘Idea’: which would be a long list of features sorted by value
  2. To Be T-Shirt Sized‘ (WIP 5): top 5 highest value features move over to a sizing column – in order for the idea to be prioritised on the product roadmap you need a rough size. It’s recommended to have a WIP (work in progress) limit
  3. Capacity Planning‘: once the feature has been roughly sized, it’s then possible to analyse when the feature can be worked on based on capacity and priority (value vs. effort (t-shirt size))
  4. Delivery Quarter‘: based on the capacity planner which should drive the start and end dates of features on the product roadmap, what quarter does the feature planned to be delivered in

There are plenty of tools available to visualise your feature pipeline eg. Aha! and JIRA and it’s a good idea to compliment that with a guide which includes SLAs for each stage of the pipeline and a t-shirt size mapping, so it’s clear what a ‘Small’ or ‘Large’ is for example.

Having a Feature Pipeline in your product toolkit for everyone to access when they want will help ensure that high priority ideas get to customers in a timely and transparent way.

Goals

No matter what product a development team works on, there will often be a big backlog full of high priority customer-centric / commercial work to deliver, technical improvements to make, bug fixing, getting after the next generation technology and security / regulatory / compliance work, so it’s important that there’s clarity over what the specific headline goals are for the development team to achieve over the next sprint / time period.

Some key points when setting goals:

  • They should be specific, but also be accompanied by a high level summary of the bigger picture
  • They should all be action-orientated
  • Make sure your goals are measurable so you know if they’re done or not at the end of the period
  • Indicate a period they’re valid for until they’re reviewed
  • Share the goals with stakeholders and senior management, as well as the review of whether the goals were ‘done’ or ‘moved over to the next period’
  • They should be realistic and the development team should agree to the goals

Setting frequent delivery goals is not only important so that the right focus is being spent on the right things which will increase the likelihood of making progress on solving the highest priority problems, but it also gives visibility of the overall progress made on product iterations and highlights problems in the process if goals are frequently not met, whether it’s due to build pipeline / environment issues or last minute dependencies for example, which should be discussed in the retrospective.

Setting delivery goals, reviewing, celebrating and learning from them should be the norm like it is when everyone’s objectives are set across the wider business.

Gap analysis

A Product Owner creating and maintaining documentation for new and existing features is just as important as those who maintain documentation in other roles especially developers.

Whether you use Confluence or other documentation software, having documentation makes it easy to provide context and clarity around the importance of getting after a particular feature whether it’s to the development teams or stakeholders.

When a new feature / problem / idea has cropped up, it becomes very useful to start documenting elements before any development effort is spent creating user stories or getting Product Backlog Items (PBIs) in a ‘ready‘ state. The key elements being:

  • One line description about what the feature is
  • Tagging in contacts eg. Product Owner, Technical Architect, Scrum Master, Stakeholders etc
  • Problem / Value including metrics / data
  • High-level requirements
  • As Is‘ and ‘To Be‘ flows which indicates where the gaps are
  • Competitor analysis if relevant
  • Actions / Next Steps
  • Technical details
  • Identifying and Tagging in dependencies

Having ‘As Is’ (Current State) and ‘To Be’ (Desired State) flows is a great way of clearly identifying where the gaps are, where you need to get to, what your competitors are doing in addition and what you need to do to get to your desired state. Having requirements visualised in this way also provides clarity of what you’re looking to achieve and becomes an easy way to digest and collaborate on the requirements vs. a long list of written requirements.

Spending time documenting the analysis of the idea / problem will help get the idea to a customer as efficiently as possible, providing clarity to the stakeholders and developers as to the ‘what‘ and ‘why‘.

Idea

Getting an idea (problem) to customers (solution) is a complex cycle no matter what organisation you work in, but constantly monitoring and optimising the whole cycle will make it as smooth and efficient as possible improving the ROI for product iterations.

Irrelevant of the size of the problem that you’re looking to solve, it’s still important to firstly understand the value of the problem – why does it need to be discussed any further let alone hit the development teams for rough sizing? Unless you have data or a solid rationale to specify the size of the problem or opportunity, it simply shouldn’t go any further than the analysis stage. Not only is the value crucial for prioritisation, but it’s also important for the development team to know the benefit of working on the PBI (Product Backlog Item).

Once you’re confident the problem is worth solving, then it’s time to set the priority by weighing up the opportunity with all other PBIs and having a gut feel on size is totally acceptable at this stage to avoid draining the development team time with every single idea and talking about work, rather than progressing with solving high priority problems.

Before the feature touches a team for grooming it’s important for Product, Delivery and Technical to collaborate on how much resource gets assigned to solving the problem or phase eg. One team, two teams or all teams – depending on the option could impact in flight features and efficiency, so it’s important to collaborate over different delivery scenarios before rushing into a decision just because a deadline looms, as getting more teams onto a problem to solve could make the delivery go slower and impact efficiency unnecessarily.

Getting a PBI / Feature from idea to a ‘ready‘ state for development stage takes a significant amount of grooming which involves the Product Owner, Development Team and Technical Architect all of which is vital to ensure that when development starts that the right problem is going to get solved in the right way, rather than anyone wondering during development what problem they’re solving, what the value is or having to do loads of rework further down the line. This is one of most important parts of the delivery phases with the key elements being:

  • Solid ‘As a’, ‘I want’, ‘So that’ description which should give a crystal clear indication of who wants what and why
  • ‘Value’ of the problem
  • Acceptance Criteria of the requirement
  • Background / context which could be a link to Confluence which shows ‘As Is’ and ‘To Be’ flows / UX and can be used as part of a kick of for the feature to the development team
  • Any dependencies
  • Notes from the team working with the Technical Architect on any up front technical designs

When the PBI is in a ‘Ready’ state and prioritised high enough, then it goes into development whether that’s in a Sprint if it’s Scrum or on a Kanban board. The ‘in development’ phase gives you the most opportunity to improve efficiency / throughput and the Scrum Master is key to help the team achieve this (continuous improvements) whether it’s helping unblock impediments, coordinate with other development product lines or suggesting ways of getting PBIs over the line. There’s no harm also in hiring a Scrum Master for a team using Kanban, as ultimately the Scrum Master role is to help / support the team progress and the things which a Scrum Master would help out a team for Scrum would also apply to Kanban eg. Chasing down impediments, coordinating dependencies, removing blockers and working with the Product Owner on improving the quality of the Product Backlog.

Delivery

Once the ‘Definition of Done‘ (DoD) has been met including demo approved, it’s time to ship the product iteration to customers. Believe it or not, after all the work that happens prior to this, the release process is the part that could get stuck for weeks depending on the architecture and how the release process is monitored for Scrum (as often it’s outside of the DoD), but again this is where the Scrum Master can really step in to add value coordinating with release managers, but also suggesting release, environment and pipeline improvements to the development team and PO by reviewing delivery KPIs. For Kanban, tracking the release process is much easier as every process up to live gets incorporated on the Kanban board as there’s no set time boundary aka sprint.

Lastly it’s time to go back to step 1 (the analysis phase) and iterating based on how customers use the latest product iteration.

Like I said at the start, the Idea to Customer cycle is complex and involves a lot of people, but monitoring, testing out other agile frameworks and optimising the phases within the whole cycle will yield in a higher & quality throughput of features getting delivered to customers, so it’s important that the people responsible for Product, Delivery and Technical collaborate closely having this high up on their agenda and regularly communicate to the business the fantastic efficiency improvements which have happened recently and what’s up next to optimise.

CSPO

Whether you’re a product led organisation or keen to take product ownership to the next level, a good way to ensure that Product Owners are well equiped to effectively handle their product in an agile environment is through various Product Owner Certifications.

The first level of certification is becoming a Certified Scrum Product Owner, where the course is typically over a two day period with modules including:

  • Introductions to Agile and Scrum
  • Agile Basics
  • Scrum Basics
  • Roles and responsibilities
  • Team Chartering (Ready, ‘Done’ and Team agreements)
  • Product Visions
  • Product Roadmaps
  • User Stories
  • The Product Backlog and Product Backlog Refinement
  • Agile Estimating and Planning
  • Sprints
  • Participant-Driven Q&A

Acspo

Once you’ve become a Certified Scrum Product Owner and you want to take product ownership to the next level then attend the Advanced Certified Scrum Product Owner® course which includes:

  • Product Backlog Prioritisation & Refinement
  • User Stories
  • Rapid Vision Generation
  • Roadmapping That Works
  • Value Proposition Design
  • Hypothesis Testing
  • Use Cases
  • Getting to Done
  • In-person Collaboration
  • On-line Collaboration with Weave
  • Understanding Yourself as a Product Owner
  • Lift-off for Agile Teams
  • Scaling Scrum and other Agile processes
  • Extreme Programming
  • Facilitative Listening I & II
  • Inclusive Solutions

Csppo

The final step is becoming a Certified Scrum Professional Product Owner. Certified Scrum Professionals challenge their teams to improve the way Scrum and other Agile techniques are applied. They have demonstrated experience, documented training, and proven knowledge in the art of Scrum.

Are you ready for the next level of experience and expertise in the art of Scrum? If so, it’s time to elevate your career further by earning the CSP®credential.