Search

Agile Filter

How “Not” To Be Agile – Vision and Objectives

Introduction‘How Not to Be Agile’ may seem a strange title for blogs about how good Agile is. The benefits that can be obtained from adopting an Agile approach are well documented all over the web.  What I intend to do over this series of articles is to share with you the misinterpretations, omissions, and mistakes that people make that significantly reduce the potential benefits of Agile when an organisation, or part of it, embark on an Agile Transformation.The content of all my articles is based on my personal experience from my training and coaching practice; there will be no ‘third party’, apocryphal stories that I do not know the truth of.Agile Transformation is not easy!  Yes, the ‘mechanics’ of all the Agile frameworks are relatively straightforward to implement, given that people are trained adequately.However, the root cause of just about all the problems that I have come across is inadequate training and/or coaching of everybody involved with the Agile Transformation including the development people as well as the senior and middle management, both business and technical.Let’s start with the importance of the Vision and Objectives of whatever it is that we are trying to achieve.Vision and ObjectivesRight before the headlong plunge into the vision and objectives of an Agile team, you should first know whether your team and Agile are meant to be together.Simply put, do not adopt Agile just for the sake of being Agile. The following diagram will help you understand the situations wherein you need to have second thoughts before embracing Agile.Most of the popular Agile frameworks such as Scrum, eXtreme Programming (XP) and Lean Software development, start the process from ‘given a set of requirements, ordered by business value, this is what you should do’.The problem with such frameworks is that they give no advice about deciding whether the development initiative should even be started in the first place; they assume that an organisation that is adopting their framework, already has processes in place to create things like Business Cases and do ‘Portfolio Management’. But even if these, what I call, ‘governance processes’ are in place, they are usually based on the organisation’s current ‘waterfall’ approach to product development and are generally unsuitable forAgile development.Notable Agile frameworks that do include some, if not all, governance considerations are the Agile Project Framework, from the Agile Business Consortium; the Lean Startup and the Scaled Agile Framework (SAFe®).Vision StatementIdeally, a Vision Statement should be of one or two sentences mentioning the problem to be solved, who has the problem and the benefits of carrying out some development; it should be aspirational, i.e a target if the best-case scenario is realised. Eg:“To solve the problem of the Board not having ‘real-time’ financial information available in order to make better strategic and tactical business decisions”In this example, it is clear who has the problem- the Board. And also, what the problem is- no real-time financial information; the benefits are implied in this example, it is probably obvious that it is important for the Board to be able to make good strategic and tactical business decisions.ObjectivesClearly, it is not possible to scope a development at any level directly from a Vision statement such as the example above:What specific financial information do the Board members need?Which Board members need it?When do they need it?Which decisions are affected?When does this ‘improvement’ need to be in place?Questions such as these can be answered in a list of Objectives:1. Current, ‘real-time’ information about {x, y, and z} needs to be available2. The information needs to be available to Board Members {a, b, and c} by the 25th of each     month.3. An improved financial reporting system must be in place by the beginning of the next financial year with a minimum of information a (the Minimum Viable Product) and hopefully with information b; the best-case scenario is that c will be included as well.We can see that this list of objectives gives us clearer detail about who to focus our efforts with and what to focus our efforts on.  Objectives are not Agile requirements.We don’t measure Vision statements; we can measure Objectives.So what problems have I encountered with Vision?Case Study 1:I had been asked by a member of an organisation to conduct an ‘Agile Audit’ of a large development programme that was supposed to be a part of the organisation’s Agile Transformation. He had asked for the audit because he was finding it difficult to see the benefits that the ‘partner’ development company had promised.For those of you yet to acquaint yourselves with Agile Audit procedures, a standard audit template may look like the one shown below. Following a similar variant, not just for Sprint planning, but also for other ceremonies in Agile can help find and fix impediments.  Initially, I concentrated my audit efforts with the numerous development teams (12), finding many ‘horror stories’ that, if you stick with me in this series of articles, you will read about later.Having submitted my audit report, I was asked to stay on to help sort out the mess; I became part of the programme management team.It became clear to me, when interacting with the different teams, that there was no consistent view of why they were doing what they were doing or what the expected value of what they were doing was supposed to be; they were used to being told what to do and they did it like they had always done; some good, some bad. The teams were made up of some of the organisation’s internal people and people from the ‘partner’ development company.Core checklistsRecommended checklistsClearly defined POTeam has a sprint backlogDaily scrum happensDemo happens after every sprintDefinition of done availableRetrospective happens after every sprintPO has a product backlog(PBL)Have sprint planning meetingsTime Boxed iterationsTeam members sit togetherTeam has all skills to bring backlog item to done.Team members not locked into specific roles.Iterations doomed to fail are terminated early.PO has product vision that is in synch with PBL.PBL and product vision is highly visible.Everyone on the team is participating in estimating.Estimate relative size(points) rather than time.PO is available when team is estimating.Whole team knows the top 3 impediments.Team has  a scrum master.PBL items  are broken into task within a sprint.Velocity is measured.Team has a sprint burndown chartDaily scrum is everyday, same time&place.I asked the programme manager and some senior programme business people what the Vision and Objectives for the programme and the Vision and Objectives for the transformation were and was assured that they existed but nobody could tell me where; there were some attempts to tell me what the Visions were but, again, there was no consistency.One afternoon, the equivalent of the CEO had a space in her diary and decided to visit the development area. After some organisational ‘notices’ she asked if there were any questions; silence!This typically happens when right at the inception of the project, a clear product vision is not drafted in a discrete format as the one shown below-So I asked her if she knew where I could find the Vision statements and/or Objectives for the programme and/or the Agile Transformation. She assured me that they existed and dispatched one of her aides to my PC to find them on the intranet. Fifteen minutes later, the aide found a section of a document, on page 34 of that document, titled ‘Vision’; the section contained 3 paragraphs none of which described the problem that the programme was trying to solve nor the benefits that were being sought. He could not find an Agile Transformation Vision or Objectives of any description.I told the programme manager of my unease about a visible and adequate programme Vision and the fact that I was uncertain of the business value of some of the programme projects but had no ’yardstick’ to measure the value by. One project had been running for about 18 months, had spent £1.5 million, and had delivered nothing!There was an attempt to measure the value of the projects by the 3-paragraph Vision and it was decided that the project mentioned above was not even in the scope of the programme; the project was cancelled. Three other projects had their scope reduced but they had already developed parts of the original scope that were removed.Lessons:1) Without a visible and concise Vision statement and list of Objectives at programme and project levels, it is highly probable that the scope at both levels will end up being something like ‘that seems like a good idea – let’s do it’.2) Without a Visible and concise Vision statement and list of Objectives at programme and project levels it is highly likely that money will be wasted; anathema to Agile.3) Governance is not just about what is happening, ie progress, it is also about why it is happening; in the beginning, and the ‘why’ may be reasonable but times change and governance processes must investigate whether the ‘why’ is sustainable; initially, in no development reviews that I attended, nobody asked the question ‘is the business case still viable?Case Study 2:I had been asked to do some Agile coaching for some teams in a global organisation that was undertaking the Agile transformation of one of their divisions; the transformation had been running for 6 months.Imagine my surprise, when starting the assignment, to find that none of the teams were involved in product development but were supporting existing systems; this support did not involve ‘coding’ of any sort, just manipulating the data; the team members had a role of ‘Analyst’.I was further surprised to find that some of the teams were organised into SAFe® Agile Release Trains (ARTs) and using Scrum.The clear majority of product development in the organisation was done by another division and Agile was not being used. However, when the product development teams needed analyst support, they co-opted members of the support teams thereby reducing the capacity of the support teams.As in Case Study 1 above, there were many anti-Agile practices in place which I shall cover in later articles.Firstly, I asked the division’s senior management why they were undertaking the Agile transformation. The answer was that the previous practice of some analysts being permanently with the development teams and the others permanently doing support, was not liked by the analysts and they were ‘mixing and matching’ within analyst teams. A worthy ambition, but I was not sure how they expected Agile to solve the problem.So I asked why the ART teams were using Scrum when Kanban was probably a better fit for the work that the teams were doing; SAFe® allows for the ART teams to use Scrum or Kanban.  I was told that it had been decided that all ART teams were to use Scrum for consistency; the answer to my next question informed that decision.Then I asked why they had chosen SAFe® given that SAFe® is designed mainly for product development; SAFe® does allow for product support teams in the ART; such teams usually use Kanban.  I was told that the product development division had experimented with SAFe® for a product development and it was considered very successful. Based on that success, the division that I was working with had decided to implement SAFe® ‘en-masse’.None of this information was written in a transformation Vision Statement nor were there any transformation Objectives with which to measure how the transformation would be measured.I am not dogmatic about Agile practices, even the ‘strange’ ones being employed by this division.  I decided to help the teams where I could.With many team members, I encountered a reluctance to follow some of the basics of Scrum which was slowing their work.My anecdotal issues about the team members’ reluctance and lethargy that I raised with the division senior management were all met with ‘show us proof’.After 3 months, it was decided to run a ‘team health check’ exercise with all the teams globally.  It was further decided that this health check would use the Spotify Squad Health Check Model by which team members are asked various questions about their team and respond via ‘traffic lights’; red, amber or green.The diagram below outlines the popular health check metrics followed by highly functional Agile teams.One of the questions asked was about ‘Suitable Process’ with ‘Our way of working fits us perfectly’ as green and ‘Our way of working sucks!’ being red.I ran the health check with the teams that I was directly responsible for and some that I wasn’t.  The answer they gave to the Suitable Process question was overwhelmingly red with a few ambers; there were no greens. I sat in on a couple of the health checks run by the senior coach; he did not use the ‘Suitable Process’ question and avoided any discussion about the process; I realised that there were politics in play that I hadn’t previously been aware of.Lessons:1) The division clearly understood the problem that they were trying to solve and who had the problem but the solution was inappropriate. Without a transformation Vision Statement and suitable Objectives List, it is likely that an inappropriate solution to the problem may be selected.2) Without a suitable list of Agile Transformation Objectives, it is impossible to measure how the transformation is progressing and to find impediments to the process that need to be addressed.ConclusionOne of the tenets of Agile is to ‘Fail Fast’. If you set out on an Agile Transformation, a product development programme or a project without everybody involved knowing:What is the problem that we are trying to solve?Who has the problem?What benefits the initiative is expected to bring?you will probably:Waste moneyChoose the wrong solutionAlienate staffIf you do not have a list of measurable objectives for the initiative:You cannot check the initiative progressYou will not identify initiative issues that must be resolvedYou cannot ‘fail fast’ and pivot your solutionBasic speculations and uncertainty aside, if you strongly intend to run a healthy Agile team, this is how your Agile journey should look like.

How “Not” To Be Agile – Vision and Objectives

4939
  • by Steve Ash
  • 02nd Aug, 2018
  • Last updated on 11th Mar, 2021
  • 5 mins read
How “Not” To Be Agile – Vision and Objectives

Introduction

‘How Not to Be Agile’ may seem a strange title for blogs about how good Agile is. The benefits that can be obtained from adopting an Agile approach are well documented all over the web.  What I intend to do over this series of articles is to share with you the misinterpretations, omissions, and mistakes that people make that significantly reduce the potential benefits of Agile when an organisation, or part of it, embark on an Agile Transformation.

The content of all my articles is based on my personal experience from my training and coaching practice; there will be no ‘third party’, apocryphal stories that I do not know the truth of.

Agile Transformation is not easy!  Yes, the ‘mechanics’ of all the Agile frameworks are relatively straightforward to implement, given that people are trained adequately.

However, the root cause of just about all the problems that I have come across is inadequate training and/or coaching of everybody involved with the Agile Transformation including the development people as well as the senior and middle management, both business and technical.

Let’s start with the importance of the Vision and Objectives of whatever it is that we are trying to achieve.

Vision and Objectives

Right before the headlong plunge into the vision and objectives of an Agile team, you should first know whether your team and Agile are meant to be together.

Simply put, do not adopt Agile just for the sake of being Agile. The following diagram will help you understand the situations wherein you need to have second thoughts before embracing Agile.

When Not To Use Agile
Most of the popular Agile frameworks such as Scrum, eXtreme Programming (XP) and Lean Software development, start the process from ‘given a set of requirements, ordered by business value, this is what you should do’.

The problem with such frameworks is that they give no advice about deciding whether the development initiative should even be started in the first place; they assume that an organisation that is adopting their framework, already has processes in place to create things like Business Cases and do ‘Portfolio Management’. But even if these, what I call, ‘governance processes’ are in place, they are usually based on the organisation’s current ‘waterfall’ approach to product development and are generally unsuitable for
Agile development.

Notable Agile frameworks that do include some, if not all, governance considerations are the Agile Project Framework, from the Agile Business Consortium; the Lean Startup and the Scaled Agile Framework (SAFe®).

Vision Statement

Ideally, a Vision Statement should be of one or two sentences mentioning the problem to be solved, who has the problem and the benefits of carrying out some development; it should be aspirational, i.e a target if the best-case scenario is realised. Eg:


“To solve the problem of the Board not having ‘real-time’ financial information available in order to make better strategic and tactical business decisions”

In this example, it is clear who has the problem- the Board. And also, what the problem is- no real-time financial information; the benefits are implied in this example, it is probably obvious that it is important for the Board to be able to make good strategic and tactical business decisions.

Objectives
Clearly, it is not possible to scope a development at any level directly from a Vision statement such as the example above:

  • What specific financial information do the Board members need?
  • Which Board members need it?
  • When do they need it?
  • Which decisions are affected?
  • When does this ‘improvement’ need to be in place?

Questions such as these can be answered in a list of Objectives:

1. Current, ‘real-time’ information about {x, y, and z} needs to be available
2. The information needs to be available to Board Members {a, b, and c} by the 25th of each     month.
3. An improved financial reporting system must be in place by the beginning of the next financial year with a minimum of information a (the Minimum Viable Product) and hopefully with information b; the best-case scenario is that c will be included as well.

Difference between Agile look like & should not look like
We can see that this list of objectives gives us clearer detail about who to focus our efforts with and what to focus our efforts on.  

Objectives are not Agile requirements.

We don’t measure Vision statements; we can measure Objectives.
So what problems have I encountered with Vision?

Case Study 1:

I had been asked by a member of an organisation to conduct an ‘Agile Audit’ of a large development programme that was supposed to be a part of the organisation’s Agile Transformation. He had asked for the audit because he was finding it difficult to see the benefits that the ‘partner’ development company had promised.

For those of you yet to acquaint yourselves with Agile Audit procedures, a standard audit template may look like the one shown below. Following a similar variant, not just for Sprint planning, but also for other ceremonies in Agile can help find and fix impediments.  

Sprint Planning
Initially, I concentrated my audit efforts with the numerous development teams (12), finding many ‘horror stories’ that, if you stick with me in this series of articles, you will read about later.Having submitted my audit report, I was asked to stay on to help sort out the mess; I became part of the programme management team.

It became clear to me, when interacting with the different teams, that there was no consistent view of why they were doing what they were doing or what the expected value of what they were doing was supposed to be; they were used to being told what to do and they did it like they had always done; some good, some bad. The teams were made up of some of the organisation’s internal people and people from the ‘partner’ development company.

Core checklistsRecommended checklists
  • Clearly defined PO
  • Team has a sprint backlog
  • Daily scrum happens
  • Demo happens after every sprint
  • Definition of done available
  • Retrospective happens after every sprint
  • PO has a product backlog(PBL)
  • Have sprint planning meetings
  • Time Boxed iterations
  • Team members sit together
  • Team has all skills to bring backlog item to done.
  • Team members not locked into specific roles.
  • Iterations doomed to fail are terminated early.
  • PO has product vision that is in synch with PBL.
  • PBL and product vision is highly visible.
  • Everyone on the team is participating in estimating.
  • Estimate relative size(points) rather than time.
  • PO is available when team is estimating.
  • Whole team knows the top 3 impediments.
  • Team has  a scrum master.
  • PBL items  are broken into task within a sprint.
  • Velocity is measured.
  • Team has a sprint burndown chart
  • Daily scrum is everyday, same time&place.


I asked the programme manager and some senior programme business people what the Vision and Objectives for the programme and the Vision and Objectives for the transformation were and was assured that they existed but nobody could tell me where; there were some attempts to tell me what the Visions were but, again, there was no consistency.

One afternoon, the equivalent of the CEO had a space in her diary and decided to visit the development area. After some organisational ‘notices’ she asked if there were any questions; silence!

This typically happens when right at the inception of the project, a clear product vision is not drafted in a discrete format as the one shown below-
FORMAT of Clear product vision
So I asked her if she knew where I could find the Vision statements and/or Objectives for the programme and/or the Agile Transformation. She assured me that they existed and dispatched one of her aides to my PC to find them on the intranet. Fifteen minutes later, the aide found a section of a document, on page 34 of that document, titled ‘Vision’; the section contained 3 paragraphs none of which described the problem that the programme was trying to solve nor the benefits that were being sought. He could not find an Agile Transformation Vision or Objectives of any description.

I told the programme manager of my unease about a visible and adequate programme Vision and the fact that I was uncertain of the business value of some of the programme projects but had no ’yardstick’ to measure the value by. One project had been running for about 18 months, had spent £1.5 million, and had delivered nothing!


There was an attempt to measure the value of the projects by the 3-paragraph Vision and it was decided that the project mentioned above was not even in the scope of the programme; the project was cancelled. Three other projects had their scope reduced but they had already developed parts of the original scope that were removed.

Lessons:

1) Without a visible and concise Vision statement and list of Objectives at programme and project levels, it is highly probable that the scope at both levels will end up being something like ‘that seems like a good idea – let’s do it’.
2) Without a Visible and concise Vision statement and list of Objectives at programme and project levels it is highly likely that money will be wasted; anathema to Agile.
3) Governance is not just about what is happening, ie progress, it is also about why it is happening; in the beginning, and the ‘why’ may be reasonable but times change and governance processes must investigate whether the ‘why’ is sustainable; initially, in no development reviews that I attended, nobody asked the question ‘is the business case still viable?

Case Study 2:

I had been asked to do some Agile coaching for some teams in a global organisation that was undertaking the Agile transformation of one of their divisions; the transformation had been running for 6 months.

Imagine my surprise, when starting the assignment, to find that none of the teams were involved in product development but were supporting existing systems; this support did not involve ‘coding’ of any sort, just manipulating the data; the team members had a role of ‘Analyst’.

I was further surprised to find that some of the teams were organised into SAFe® Agile Release Trains (ARTs) and using Scrum.

The clear majority of product development in the organisation was done by another division and Agile was not being used. However, when the product development teams needed analyst support, they co-opted members of the support teams thereby reducing the capacity of the support teams.

As in Case Study 1 above, there were many anti-Agile practices in place which I shall cover in later articles.

Firstly, I asked the division’s senior management why they were undertaking the Agile transformation. The answer was that the previous practice of some analysts being permanently with the development teams and the others permanently doing support, was not liked by the analysts and they were ‘mixing and matching’ within analyst teams. A worthy ambition, but I was not sure how they expected Agile to solve the problem.

So I asked why the ART teams were using Scrum when Kanban was probably a better fit for the work that the teams were doing; SAFe® allows for the ART teams to use Scrum or Kanban.  I was told that it had been decided that all ART teams were to use Scrum for consistency; the answer to my next question informed that decision.

Then I asked why they had chosen SAFe® given that SAFe® is designed mainly for product development; SAFe® does allow for product support teams in the ART; such teams usually use Kanban.  I was told that the product development division had experimented with SAFe® for a product development and it was considered very successful. Based on that success, the division that I was working with had decided to implement SAFe® ‘en-masse’.

None of this information was written in a transformation Vision Statement nor were there any transformation Objectives with which to measure how the transformation would be measured.I am not dogmatic about Agile practices, even the ‘strange’ ones being employed by this division.  I decided to help the teams where I could.

With many team members, I encountered a reluctance to follow some of the basics of Scrum which was slowing their work.

My anecdotal issues about the team members’ reluctance and lethargy that I raised with the division senior management were all met with ‘show us proof’.

After 3 months, it was decided to run a ‘team health check’ exercise with all the teams globally.  It was further decided that this health check would use the Spotify Squad Health Check Model by which team members are asked various questions about their team and respond via ‘traffic lights’; red, amber or green.

The diagram below outlines the popular health check metrics followed by highly functional Agile teams.
One of the questions asked was about ‘Suitable Process’ with ‘Our way of working fits us perfectly’ as green and ‘Our way of working sucks!’ being red.

I ran the health check with the teams that I was directly responsible for and some that I wasn’t.  The answer they gave to the Suitable Process question was overwhelmingly red with a few ambers; there were no greens. I sat in on a couple of the health checks run by the senior coach; he did not use the ‘Suitable Process’ question and avoided any discussion about the process; I realised that there were politics in play that I hadn’t previously been aware of.

Lessons:

1) The division clearly understood the problem that they were trying to solve and who had the problem but the solution was inappropriate. Without a transformation Vision Statement and suitable Objectives List, it is likely that an inappropriate solution to the problem may be selected.

2) Without a suitable list of Agile Transformation Objectives, it is impossible to measure how the transformation is progressing and to find impediments to the process that need to be addressed.

Conclusion
One of the tenets of Agile is to ‘Fail Fast’. If you set out on an Agile Transformation, a product development programme or a project without everybody involved knowing:

  • What is the problem that we are trying to solve?
  • Who has the problem?
  • What benefits the initiative is expected to bring?

you will probably:

  • Waste money
  • Choose the wrong solution
  • Alienate staff

If you do not have a list of measurable objectives for the initiative:

  • You cannot check the initiative progress
  • You will not identify initiative issues that must be resolved
  • You cannot ‘fail fast’ and pivot your solution

Basic speculations and uncertainty aside, if you strongly intend to run a healthy Agile team, this is how your Agile journey should look like.

Steve

Steve Ash

Blog Author

Steve Ash has been working with ‘Agile’ since 1993 when it was known as ‘Managed RAD’.  He was an early adopter of the DSDM Framework in 1995 becoming a DSDM Board Member in 2002 and was a DSDM examiner.  He is a DSDM Advanced Practitioner and Accredited Trainer/Coach. Steve has since embraced Scrum, Kanban, the techniques advocated by XP, Lean Software Development and Lean Startup. He joined the Agile Alliance in 2002 and is a Certified Scrum Master (CSM), Certified Scrum Product Owner (CSPO), SAFe® Certified Consultant (SPC4) and certified by APMG International to teach Agile Project Management and Agile Business Analysis courses. Since 1996, Steve has trained, mentored and coached hundreds of people in many public and commercial organisations in 11 countries from the USA, through Europe and India to Asia/PAC.
 

Join the Discussion

Your email address will not be published. Required fields are marked *

Suggested Blogs

The Best Product Development Process

What Is Product Development? Product development relates to the creation of a new product that has some benefit; up-gradation of the existing product; or improvement of the production process, method, or system. In other words, it is all about bringing a change for the better in the present goods or services or the mode of production.  Product development includes the following elements:Creation and Innovation pave the process for new discoveries and the creation of a new product that offers benefits to the consumers. Amendment of the existing products is essential to enhance the past products and to attain perfection. Improvement of the existing production process, methods, and practices helps give customers an improved experience. It is cost-efficient for the organization too. For Example; Apple CEO Steve Jobs envisioned an idea of using a touch screen to interact with a computer, which would allow him to directly type onto the display, instead of using a stylus. This idea of a touch screen was first implemented for the first iPhone that was launched in 2007 in the US. Apple, with its new product development, revolutionized the way we use mobile gadgets.Why Is It So Important to have a Product Development Process? Product development is the procedure for the successful development of new products or adding new features to the current product. In business terms, the product development policy provides a skeleton that aids enhancement of the performance and quality of products.  The approaches outlined below can bring up scores of advantages to help and expand the business in today’s contentious market. Control over productThe development of a product without a decent approach is quite a precarious challenge. To manage and to be sure of success, it is necessary to plan the development of your products or services and this is what the business or organization requires. The planning would help in fulfilling business goals. Enhanced performanceSeveral times, even after spending thousands of dollars on promotion or marketing the product, a business owner faces setbacks because of poor quality of the product. Hence, it is important to monitor the production and other processes to preserve a record of wrongdoings and improve the same. Reduce costCreating and implementing new products leads to additional cost to the company. The owner has to bear a huge cost in the primary stages of product development, but after the execution process, it is noticed that there is a decrease in product development cost.The History of Product Development Processes Product improvement is closely tied to creativity, invention, and insight—and follows the vision of an idea. For example: the present-day Gas stove is the consequence of some ancient human's insight that a fire is created by rubbing two stones together: the rest was product development. According to Michael McGrath (in Next Generation Product Development), keen focus on the development process began late in the 19th century. McGrath divides the time since into "generations" of product development importance. First ending in 1950s, the focus was on commercialization of discoveries; in the second, formalization of product development as a process began, and this lasted until the 1980s. In the third "generation" of product development, corporate management concentrated on getting products to market faster. In the 21st century, according to McGrath, stress had shifted to R&D-based development. All types of strategies to product development proceed to exist side-by-side. As in gambling, no "method" ensures success.Product Development Process Models There are different software development life cycle models defined which are helpful in designing the software development process.  Some important and popular SDLC models supported in the industry are as follows: Waterfall Process Model Iterative Process Model Spiral Process Model V Process Model Big Bang Process Model Agile Process Model RAD Process Model Prototyping Process Models Waterfall ModelThe Waterfall Model is the traditional Process Model. It is considered as a linear-sequential life cycle model. Waterfall model at each stage must accomplish the next phase before and there should be no overlapping phases.Iterative Process Model  Iterative process starts with an easy implementation of a subset of the software requirements and iteratively improves the evolving versions until the full system is implemented.  With every  new iteration, new design modifications are produced and new functional capabilities are added.  Spiral Process Model The spiral model has four phases. A software project repeatedly passes through these phases in iterations called Spirals i.e. Identification, Design, Construct or Build and Evaluation and Risk Analysis. V Process Model The V-model is an SDLC model where execution of processes occurs in a sequential manner in a V-shape. It is also acknowledged as Verification and Validation model. The V-Model is an extension of the waterfall model. Big Bang Process Model The Big Bang model is an SDLC model where we do not follow any definite process. The development begins with the required money and efforts as the input, and the output is the software developed which may or may not be as per customer demand. Agile Process Model Agile product development life cycle promotes frequent inspection and adaptation. The methodologies rely on the experience of small teams and teamwork to address any changes and promote trusted customer collaboration. Agile product development methods begin things in small increments. Iterations are small; typically of one to four weeks duration. RAD Process Model The RAD (Rapid Application Development) model is based on prototyping and iterative development with no special planning involved. The method of drafting the software itself involves the planning required for producing the product. Software Prototype Process Model The Software Prototyping refers to building software application prototypes which illustrate the functionality of the product under development, but may not truly hold the precise logic of the original software.What Is the Product Development Lifecycle? The product life cycle is an influential concept in marketing. It defines the stages a product goes through right from its inception to when it is removed from the market. Not all products relinquish the final stage. Some advance and grow while others rise and fail. The main stages of the product life cycle are: Research & development - Researching and developing the product before it is made available for sale in the market Introduction – Driving the product into the market Growth – When sales are expanding at their fastest rate Maturity – Sales are near their highest, but the percentage of growth is slowing down, e.g. new rivals in market or saturation Decline – Final step of the cycle, when sales begin to fallThis can be illustrated by looking at the sales during the time span of the product.What is a New Product Development Process? The product development method is a well-defined series of steps or stages a company uses to achieve its accomplishment of new offerings. Every company develops new product or services, but product development processes vary considerably from one company to another depending on the industry, the product type, whether the product is an incremental improvement or a breakthrough innovation, and the extent to which you focus on product portfolio management. What are the six steps of a traditional new product development process? A typical product development process of this kind has six steps with five gates. Step 1: Product Discovery  Step 2: Definition of Product Step 3: Product Business Case Development  Step 4: Detailed Product Design  Step 5 Validation/Testing of product developed Step 6: Product Launch Step 1: Product Discovery This initial step or stage of the new product development process is where new product ideas originate. A company forms a small team to study the idea and initial draft of the product, perform market analysis, and explore technical and market risk. The concept is the most important step for new products as this is where the most product ideas come from - and this determines the necessity for the development. If the study or product concept is wrong at the early stage, then not only is time wasted but it also increases opportunity cost.    Step 2: Definition of Product This stage encompasses polishing the definition of the product. The team creates the first comprehensive evaluation of the technology, and the market and business features of the new product concept. Developers and managers review and illustrate the important points of differentiation for the new product. If this process is carried out incorrectly, then it can increase time to market or cause the product to misinterpret the needs of the market. Step 3: Product Business Case Development Action supports the organization’s investment in the development of a product by having the team create a comprehensive business plan. This plan comprises exhaustive market research. The team explores the new product and where the intended product fits within it, and also creates a monetary model for the innovative offering that makes presumptions about market share. Step 4: Detailed Product Design The team outlines and assembles a working prototype of the product. In most cases they alpha-test the archetype, working with customers in an iterative manner; receiving feedback, and incorporating it into the prototype. This step in the new product development process is sometimes called Development, and charters the next step, “Validation/Testing.” Step 5: Validation/Testing of product developed Validation and testing mean ensuring the prototype operates as predicted. It also means verifying the product in the opinions of the customers and markets and testing the viability of the financial model of the product. Step 6: Product launch During the product development process, the team realizes everything required to bring the product to market, including marketing and sales plans.   Gate Reviews Each of these six phases finishes within a gate review where the team gives the management specific, pre-defined deliverables, and displays the outcomes required to move on to the next phase of the product development process.The world is moving away from this waterfall product development approach.  It is extremely process heavy and encourages additional interference from Senior Management.Image sourceMinimum Viable Process: A Modern Approach What value does the planning of a new product development bring to customers? Irrespective of its form-i.e. physical or digital, it should be able to solve the customer’s problem. It doesn't matter how complex the problem would be, but it should deliver a high-quality product that brings value to your customers.  In a nutshell, Minimum Viable Product (MVP) is a variant of a software product that has enough functionalities to satisfy the primary needs of the first users and persuade investors to invest money into it. It is not a fully-grown product, but it can nonetheless bring business privileges and has the potential for additional development.  In other words, an MVP is a working prototype that should: Be fast to build Contemplate all resources (money, developers, etc.) on providing customers with real value Create those features that are important for a product to generate value The theory of an MVP was developed by Eric Ries in his book The Lean Startup. The author believes that the most important factor is to focus on business goals and not on the technology which has only secondary importance. Focus on investigating the market and understand the obstacles your potential customers want to solve.  Any product before it is released to the public is a mere theory. Testing in a real-life scenario is important to collect market feedback and then iterate. Each idea, even the most profound one, brings no business value until it is put into practice. An MVP allows you to verify, without making an ample investment of time and money, if the product attracts new customers when launched.  If your product is successful, continue to develop it so it becomes a foundation for a fully-grown product. When MVP needs improvements to be transformed into a product it should be completely reworked. MVP strategy allows you to considerably shorten your time-to-market.  A Modern, Lean Product Development Process Toyota began its journey with lean product development at Toyota Loom Works. Toyota started manufacturing cars. There were differences in manufacturing conditions between Japan and the USA. Toyota had few skilled engineers and had limited prior experience. Car companies in US employed a well-educated work team and benefited from the research and skill-sets of their engineering teams. To tackle this shortfall in knowledge and experience, Toyota escorted an incremental approach to development that built on their current knowledge and this became the basis of the lean systems. Lean Product Development (LPD) is based on lean thinking and lean principles that originally were developed in lean manufacturing. Lean thinking relates to way of thinking and specific practices that maintain less of everything – less resources, less work-in-process, less time, and less cost – to manufacture a physical product, knowledge product or service product.  The five Lean Thinking Principles are: Define and maximize customer value Identify the value stream and reduce waste Make the value-creating steps flow Empower the team Learn and improve Approach: Creating products that delight customers and meet business objectives. Agile methodology versus Waterfall methodology The waterfall project methodology is a traditional pattern for developing engineering systems that were used in manufacturing and construction projects. When executed in software development, specific tasks completed in one phase need to be assessed and validated before moving to the next phase. It is called a linear and sequential approach, where phases flow downward to the next.  The agile project methodology is an example of an incremental model for software development based on principles that focus more on people, decisions, and manageable responses to change. Planning of the whole project is broken down in small increments or short time spans. Each iteration involves the whole SDLC cycle so that a working product is delivered at the end. Some of the distinct differences are: Agile is an incremental and iterative approach; Waterfall is a linear and sequential approach. Agile distributes a project into sprints; Waterfall distributes project into phases. Agile helps to finish many small projects; Waterfall helps to complete one single project. Agile incorporates a product mindset with a focus on customer satisfaction; Waterfall introduces a project mindset with a focus on successful project delivery. Requirements are planned everyday in Agile, while in Waterfall, requirements are adjusted once at the start. Agile enables requirement changes at any time; Waterfall shuns scope changes once the project starts. Testing is done concurrently with development in Agile; testing stage comes only after the build phase in Waterfall. Testing teams in Agile can take part in specifications change; testing teams in Waterfall do not get involved in specification changes. Agile empowers the entire team to manage the project without a project manager; Waterfall requires a project manager who performs an essential role in every phase. Cross-functional teams Cross-functional collaboration involves people from diverse spheres, bringing together their knowledge, expertise, and experience. The major point is “work-interdependency”. Teams have to work together to accomplish results. Cross-team collaboration has become the demand of continually emerging new technologies, with new competitors scrumming, and companies aspiring to stay on top of the game. The success of a cross-functional team depends on several factors, without which a team would be struggling. Highly motivated team members Teams hold responsibility to achieve the mission Open-minded team members Management to support the team No opposing personal goals Clear priorities or direction Adequate communication Cross-functional collaboration can be a great team building measure and can build a more creative atmosphere. The 8 Benefits of Cross-Functional Team Collaboration are: To bring a gulp of creative ideas Engaged employees Spurring innovative ideas Exercising communication skills Developing management skills Chance to get in leadership roles Break stereotype and benefit from diversity Build better team spiritExample: Product development—Agile methodology (Case Study) Below is the case study of a team that faced issues but managed to implement solutions to resolve the issues and delivered output with high standards Issues Products or Services were not delivered on-time. Rework and burden caused employee stress and customer disappointment Lack of clear and well-defined product development methods Excessive projects in the pipeline; team was small, and resources were spread too thin Projects were continuously reprioritized leading to incompetent resource utilization Lack of clarity to project status The absence and missing of key resources led to inefficient product development Lack of strategic management Poor communication and hand-offs between departments Solution implemented Designed a portfolio management system that managed an appropriate and optimal number of projects based on available resources Acquired a scalable and robust lean product development process with integrated lean/agile techniques Implemented cross-functional teams with designated roles and responsibilities Standardized project management processes and enhanced project clarity across the organization Coached the product management team on maturing product strategies and roadmaps Trained and mentored senior management and project team members What made the solution successful? Active and strong senior management buy-in and support played an important role in implementing the solutions at high standards Built organizational knowledge that can be used in other active projects Projects were kept on hold until resources were available Efficient project planning facilitated proper collaboration within cross-functional teams Product development strategies and roadmaps helped the development team Daily stand-up meetings organized helped cross-functional teams to monitor project work, front and center Accommodated implementation timing based on the organization’s capability Effect or Consequence Within a couple of months, important and high priority projects were completed on-time (some early); the client was hence satisfied The client acquired a major contract from the customer due to improved on-time delivery and this, in turn, ensured more business Enhanced communication and coordination across all departments Senior management was competent to evaluate and prioritize the most important projects  Weekly Reports granted visibility to project status Product development and lean/agile processes are now efficiently embedded into the organization The internal conflicts between team members and departments have declined ConclusionNew product development is about transforming new and uninitiated ideas into workable products. This product will be your brainchild, which will provide a contentious advantage and help monopolize the market.The eight stages of product development may seem like a lengthy process, but they are outlined to save time and resources. New product improvement plans and prototypes are experimented with to assure that the new product will meet target market demands and desires. Implement a test launch during the test or marketing stage as a full market launch would be expensive. Finally, the commercialization stage is meticulously planned to maximize product success. A poor launch will affect product sales and could even affect the reputation and vision of the new product.Hence, A Certified Scrum Product Owner® (CSPO®) is one such certification that helps holders become successful product owners by training them on aspects of on-time delivery of high-value releases and maximizing the ROI.
9566
The Best Product Development Process

What Is Product Development? Product development... Read More

Becoming a SAFe® 5 Program Consultant

“Man must rise above the Earth—to the top of the atmosphere and beyond—for only thus will he fully understand the world in which he lives.” – Socrates Over thousands of years, scientists & architects around the world, have been bewildered trying to understand how the great pyramids of Egypt were erected. The key lay in some extraordinary planning, known only to a few chief architects, who at that time, were one of the most important members of the king’s inner circle and responsible for all the royal work carried out. Although everyone knew ‘who’ built the pyramid, the million-dollar question was, ‘how’ did the chief architect of the pyramid communicate his precision planning techniques to a workforce of around 10,000 men?I know what you are thinking next, but yes, I am going to use this analogy to relate the chief architect of a Pyramid to an SPC (SAFe Program consultant). This analogy for me is relevant, since much like the architects who built the pyramids, the SPCs have an important task, of not only designing & charting out plans to take an enterprise on its path of efficiently scaling Agile but also to ensure, that they clearly communicate the plan to the very last scrum team involved in day-to-day product delivery. So, if you want to be an architect who wants to build a pyramid in your kingdom, oops, sorry got a bit carried away; I meant, if you are willing to become an SPC, who wants to implement SAFe in your Enterprise, then this blog is definitely for you, so please do read on.The role of an SPC:‘With the demand for Certified SAFe® professionals continuing to grow at an accelerated rate—especially among Global 2000 enterprises—the value of an SPC certification is greater now than ever before.’ – Scaledagile.com SAFe Program consultants are lean agile change agents who provide knowledge, share experience and pump in that extra horsepower needed to implement change. They are very much the first point of contact for the executives, when the organization reaches the so-called tipping point, running too many programs, hundreds of delivery teams and pretty much a chaotic situation. SPCs work on this rationale for a significant change.  Most importantly, SPCs are empowered to officially train people on the SAFe Framework which has an obvious multiplier effect on organizational competitiveness by increasing productivity, quality, and time-to-market.  There is also a strong return on investment for these trainings, especially if you are an internal change agent. At the end of the day, a SAFe Program Consultant helps increase employee engagement and fosters continuous learning while helping enterprises achieve better outcomes. Yep, that’s what they do. Amazing, isn’t it?  SPCs in their role should also be looking to address some of the gaps in other frameworks, like the below: Constantly ideate a tangible outcome by design in order to bring up the team's right brain activity. Formulate the possibility of teams & portfolios, ending up creating incremental productivity boosters by effective utilization of the IP sprint, as it’s the official approach to have better chance of disruptive innovation.Key areas of competency:By now I am sure, we all would agree that an SPC is a true servant leader who plays a crucial role in SAFe implementation, by applying the latest expert knowledge. They can correlate to existing enterprise (lean agile) ways of working and help the transformation team to identify the sweet spots to start the SAFe transformation. In order to achieve this, SPCs generally would have a very lean focus area, as shown below. As an SPC, you would be expected to be committed to helping people understand and implement SAFe properly and that too in a servant leadership manner. Many enterprise coaches have mentioned that SAFe isn't the only scaling approach that they work with, but a lot of people say (more often than others) that they do want to implement SAFe but want to keep to the true spirit of Agile and that probably is a key thing to keep in mind for any aspiring SPC candidate. Why should I be an SPC?Well, if I have to be brutally honest, you actually don’t need any specific certification in order to become an agile coach at an enterprise level. However, this only works out if you are well recognised within your organization, as a person who values agile practices and SAFe principles and has the key ability, to contribute to the enterprise level scaling initiatives. For everyone else (at least 90% of us) there is an SPC (SAFe Program Consultant) certification. This course is intended for all those who will be materially and directly involved in a SAFe adoption. This includes practitioners, change agents, and consultants responsible for implementing Agile programs and portfolios as part of an enterprise Lean-Agile change initiative. SPC certification definitely gives you an edge over the competition, as SAFe is pretty popular and in some cases, leads the way to adopt and professionalize aspects of scaling agile. SPC certification holds a lot of market value. It will also give you a deep dive into the SAFe implementation roadmap and its nitty gritty concepts. You will learn all about implementing SAFe in organizations at an enterprise level and how you can support this process in the capacity of consultant or internal change agent.  For e.g. a major concern that is raised against SAFe is the incorrect usage of the IP iteration. Rather than taking a break and finding ways to improve productivity, these iterations are more or less used as a Hardening sprint. Where an effective SPC will come into the picture, is when he/she coaches the team to take this time to do some design thinking, create prototypes to communicate about their business ideas (in most cases, the teams are the ones who know the problems much better as they are closer to it), present them to product VP and get them funded for next planning cycle.  You see the difference straight away, don’t you? These are some important things that an SPC needs to be empowered to take up. So if you are a senior agilist in your organization, instead of cribbing about some of the anti-patterns, why don’t you empower yourself by taking an SPC certification? Food for thought, eh?How to get certified? Given that SPC is an advanced level certification, its mandatory to go through the Implementing SAFe course, details of which can be read through in the following link. This is a 4-day training program, typically a classroom training but given the pandemic situation, a remote training mode (an online course with many practical tools) has been adopted and that too quite successfully. The hours are approximately 6 hours per day and may be extended to an extra course day. Please do expect some detailed case studies (success stories), some pre-reading/ video viewing material sent in advance so that you are better prepared (along with mock tests where applicable). Most of the trainers have quickly transitioned to online courses and they do a great job. Things have managed to move on faster than I thought and its only for the larger good.  However, there are some pre-requisites for taking up the certification, as below: 5+ years of experience in software development, testing, business analysis, product, or project management 3+ years of experience in Agile One or more relevant Agile certificationsThere is also the money factor, yes training & exam costs. For SPC, you may need to spend a min of $3000 (some training academies may offer a discounted price, so please do watch out for that) and then you have to pay $800+ per annum (yes, that is correct!) towards renewal costs. This can take a toll on quite a few but believe me there are many organizations willing to bear these costs for their employees as they understand its importance.Image SourceExam Tips: Here are some tips which you might be interested in, on how to prepare yourself for the SPC exam. Most of the SPC aspirants have applied these tips/tricks and have provided positive feedback that this actually works.  Please ensure that you go through and completely understand the big picture of SAFe.Make sure that you take an effort to sincerely relate it to the enterprise where you are working. Jot down a name in front of each role listed in the big picture and then map it to the relevant functions. Exam study materials – SAFe recommends that you go through multiple resources from the SAFe community platforms. Your trainer will be providing the details.  Attempt the sample tests provided by Scaled Agile, along with the mock tests that your trainer will provide. The practice test is available at no additional charge, and you can take it as many times as you like no matter the outcome (pass or fail). However, it provides the same bank of questions randomized in a different order. Once you have taken the sample tests / practice tests, I would highly recommend that you organize yourself and make some stats to data drive your decision of area of improvement and track progress. Questions are more or less, equally distributed from each level like foundations, portfolio & enterprise. Review the whole workbook and do not skip any slide. Every bullet point has a meaning and complete flow. Don’t even leave the glossaryKnowing your trainer:Whilst you are getting prepared to immerse yourself into the workshop or the exam, also please spend some time on understanding who is going to give you the training. It’s a sound advice, especially to those planning to register to an Implementing SAFe class to become SPCs – please do ask around and make sure you verify your SPCT knows his/her Scrum and Kanban properly. This can be done by checking if they have also obtained related scrum/Kanban specific certifications etc.  The Benefits: ‘Once trained, SPCs have the knowledge, skills, and resources needed to educate and train managers, teams, and the other stakeholders necessary to effectively drive the change. They become a critical part of the sufficiently powerful coalition for the changes needed to drive the next critical move’  - © Scaled Agile, Inc. I think this in itself is a very powerful motivation which can be used to reap further benefits.  As you can see, you clearly can’t ignore the enormous benefits of becoming a SAFe Program Consultant. Given that this certification is a formal recognition world over, it helps in supporting you advance in your professional development and for a few of you an SPC certification may as well be an important prerequisite to even apply for certain assignments. Taking up international assignments will only become that much easier. Since SAFe is so prevalent, an SPC certification will open up huge opportunities. A great SPC would be the one who can guide an organization to balance business agility with predictability; both of which are extremely important to the typical enterprise-scale technology organization. Thanks for your patience and wish you all the very best in your Agile journey. In case you want me to write about any specific topic, please feel free to comment below and I’ll be more than happy to add them to my ‘Blog Backlog’. If you liked the article, please do share it in your agile community to help spread the word.  Hope to see you soon, with more such interesting topics. 
5382
Becoming a SAFe® 5 Program Consultant

“Man must rise above the Earth—to the top of t... Read More

Why and How to Pass the PSPO Exam?

The role of the Product Owner is in high demand in the current market. It has consistently appeared among LinkedIn's most promising jobs. Agile and Scrum methodologies have overtaken the traditional methods of building software and managing projects, as they have been consistently proven to give better results than traditional project management methods.In this article, you will learn about PSPO, among the most sought-after Product Owner certifications around the world. PSPO stands for Professional Scrum Product Owner and this certification is offered by Scrum.org.  Before jumping into the details, let’s get to know about the accreditation body, that is Scrum.org, that offers the PSPO certification. Ken Schwaber, the co-creator of Scrum, who founded Scrum.org in 2009 as a global organization, has been dedicating himself to improving best practices in the world of Scrum. Unlike other training and certification organizations, Scrum.org is focused on improving professionalism in complex product delivery and that drives everything they do. For getting the Professional Scrum Product Owner certification, you would be required to demonstrate your familiarity, understanding and capability to apply Scrum fundamentals in the real world. All training materials are collaboratively maintained and improved by the community of Scrum experts and the founder Ken Schwaber, the co-creator of Scrum.Prove your Product Owner KnowledgePSPO is offered in 3 levels—I, II, and III. Before signing up for the training and certification for any of the three levels, Scrum.org gives you a chance to assess your readiness, and prove your knowledge, understanding and ability to apply Scrum in the real-world. This can be done with the free assessment offered by Scrum.org.  The assessments are available to anyone who wishes to validate their knowledge of the Scrum framework and ability to support value creation and delivery. Scrum.org has decoupled the certification assessments from the training. Although each Scrum.org training class includes a free attempt at a Scrum.org assessment, you would still need to prove your knowledge by passing the assessment test with a score of 85% or better to receive the associated Professional certification. Those who pass the assessment receive the industry recognized PSPO I, II and III Certification to demonstrate their mastery of the content. However, Scrum.org highly recommends that you should take a Professional Scrum Product Owner course. This is not mandatory, and participants can attempt any of the three certifications after self-study also.Prepare for the assessmentTo prepare for the certification assessment, you should be thorough with the multiple focus areas as defined by the Professional Scrum Competencies.Here are the Professional Scrum competencies and the key terms that you should learn:Understanding and Applying the Scrum FrameworkDeveloping People and TeamsManaging Products with AgilityDeveloping & Delivering Products ProfessionallyEvolving the Agile OrganizationEmpiricismScrum ValuesScrum TeamEventsArtifacts\DoneScalingSelf-Managing TeamsFacilitationLeadership StylesCoaching & MentoringTeachingForecasting & Release PlanningProduct VisionProduct ValueProduct Backlog ManagementBusiness StrategyStakeholders & CustomersEmergent Software DevelopmentManaging Technical RiskContinuous QualityContinuous IntegrationContinuous DeliveryOptimizing FlowOrganizational Design & CulturePortfolio PlanningEvidence Based ManagementDetails To navigate through the preparation, you should: Be very familiar with the Scrum Guide. Read it at least 4-5 times Understand the Product owner Learning path As the Product Owners work closely with Scrum masters, hence it is required for Product owners to understand the Scrum Master Learning Path Go through various blogs available here Read and understand at least 4-5 times:  Scrum Glossary Evidence Based Management Guide Evidence Based Management Nexus Guide is also a valuable resource You can take Open assessments as many times you wish. Find out why you got an answer wrong and read up on the answers in the Scrum Guide. My advice would be that you should not attempt the real assessment unless you have scored 100% at least three times in a row in the open assessments.CertificationLet’s understand the various levels of the PSPO certification. There are 3 levels:Details are available at.For this certification, there are steps and preparation that you should follow and this article will take you through all you need to be a PSPO.Exam Fee, Passing Score, Time limit, Number of Questions, Exam Format, Difficulty and LanguageExam FeePassing ScoreTime limit# of QuestionsExam formatDifficultyLanguagePSPO I Assessment$20085%1 hour80Multiple Choice, Multiple Answer and True/FalseIntermediateEnglishPSPO II Assessment$25085%1 hour40Multiple Choice, Multiple AnswerAdvancedEnglishPSPO III Assessment$50085%2 hours35Multiple Choice and essayExpertEnglishOnce you pay the exam fee for the respective assessment, you would receive the password for attempting the assessment in 1 business day. Assessment passwords do not expire and remain valid until used.  PSPO Subject Areas To clear PSPO certification, you should have thorough understanding of the Subject areas. The Subject areas for PSPO are: Agile Product Management: The role of a Product Owner in Agile Product Management is to maximize the value of the product developed by the implementation team. From the certification point of view, you should understand the importance of the role of Product owner, which is an internal facing role and requires gathering technical requirements, grooming the product backlog, and detailing user stories. Additionally, while reading you should keep focussing on how a product owner envisions a product’s life in an agile environment. You should also learn the techniques of building a Business Model Canvas, writing a business case and creating the value proposition. Eventually, that will help you in defining the customer segments, value proposition, and major activities that you should perform during the agile product lifecycle. You should also understand the core responsibilities carried out by the Product Owner in the Agile product management as part of Product Strategy-understanding the customer needs, creating the product roadmap, prioritizing the features, understanding customer experiences and measuring the product success.Value Driven Development The primary motto of Agile is to satisfy the customer needs through early and continuous delivery of software. The Product Owner should focus on delivering the maximum value at the earliest in Value driven development. You should have sound understanding about user stories and should follow the INVEST rule, that is user stories should be: I - Independent N - Negotiable V - Valuable E -Estimable S - Small T - Testable Each of the user stories should have a clear story point. You should also have an understanding of the business value so that Return of Investment can be calculated. The KPI i.e., Return of Investment helps the Product Owner to perform prioritization in the Value Driven Development.Scrum Theory and Empiricism The Scrum Values are the foundation for behaviour and practices in Scrum. They are closely related to the theory and first principles of Scrum and support teams in their work.  The Scrum Team can always fall back on these essentials.  The Product Owner should demonstrate following 5 attributes: Courage: Product Owner should help in encouraging the scrum team members to do the right thing and work on tough problems. Focus: Product Owner should ensure that scrum members focus on the work of the Sprint and goals of the Scrum team. Commitment: Product Owner should create the environment where Scrum team members should personally commit to achieve the goals of the Scrum team. Respect: Team members in the Scrum team should respect each other. Openness: Team members in the Scrum team and the stakeholders should be open about the work and associated challenges.Scrum Framework As a Product Owner, you should have a great understanding of the Scrum framework and the constituting team members--Developers and Scrum Master.  You should also understand about the artifacts used in the Scrum framework such as Product Backlog, Sprint backlog and Increments. Various events take place in Scrum like Sprint, Sprint planning, Daily scrum, Sprint Review and Sprint Retrospective meetings. An understanding of the entire framework is highly recommended for the prospective Product Owners and for this certification.Product Backlog Management You should have a decent understanding about product backlog management. While you prepare the backlog, you should keep the following in mind: Your backlog should be the single source for delivery of valuable items It should possess transparency to the scrum team and stakeholders It should follow the prioritization and should be ordered based on the value, dependencies, and risk You should always keep an eye on the estimates for the product backlog items Your product backlog should be a point for starting conversations with the team members Ensure that the items in your product backlog contain specifications, mock-ups, architecture models, user acceptance criteria etc Release Management Product Owners can follow different release strategies. The releases can be Major, Minor or functional releases.  A major release can contain many large changes. They should be infrequent as they are often aligned with the organization timelines. While a major release is in progress, other works should be frozen, as a major release incurs high customer absorption costs and high business risks. A minor release can contain broad changes. They should be pre-scheduled as they often align with the sprint boundaries. Minor release should contain bug fixes and patches. A functional release can contain individual functionalities. Functional releases offer immediate value to the stakeholders. They incur low customer absorption costs and have minimal or no business risks.Required Course There are various courses available online for undertaking product owner certifications. You should pick the course based on your needs and the level of expertise you expect to achieve.  Recommended Course: PSPO PSPO (Professional Scrum Product Owner) from Scrum.org is one of the recommended certification courses for Product Owners because it gives following benefits: PSPO assessment from Scrum.org requires you to have a good knowledge of Scrum and the passing score is high i.e., 85%, ensuring that your level of understanding is sound  It is not required to renew the certification once you have passed it, as it has a lifetime validity Once you have cleared the certification, your name would be added to the Scrum.org website and anyone can verify your credentialsWays to learn more to help you prepare Here are the tips that you can follow to clear the PSPO certification: 1. Ensure that you give equal importance to all the subject areas as questions would arise from all of them. However, the weightage varies roughly as below. Please note these are based on the inputs taken from various PSPO takers: Agile Product Management: 20% Value Driven Development: 20% Scrum Theory and Empiricism: 15% Scrum Framework: 15% Product Backlog Management: 15% Release Management: 10% Miscellaneous from Open Assessment in Scrum.org: 5% 2. Make sure you are alert and focused when you are taking the exam. Take the exam according to your convenience, at a time that suits you.  When you are taking the exam, move to a silent place so that you are uninterrupted. 3. Read the questions carefully and then answer. They may trick you by asking questions which contain ‘never’, ‘always’, ‘not’ or ‘which of the following cannot be available’ option. So, pay extra attention to the keywords in the questions. 4. There are multiple choice questions as well in the exam, make sure you have read all of the options and then answer. 5. Be very attentive about the questions related to specific subject areas. Conclusion   PSPO is among the more difficult certification exams for Product Owners. Ensure that you have given yourself sufficient time to prepare, around 4-6 weeks.  Remember, that PSPO is a very valuable certification in the Product Owner profession and as of January 2021, there are only 97,208 PSPO 1, 1906 PSPO II and 347 PSPO III certified holders around the globe. This certification can be a great way for you to be noticed by potential recruiters. Also, this is a great way to validate your skills and knowledge of Product Owner responsibilities and demonstrate your expertise to your employer.
7357
Why and How to Pass the PSPO Exam?

The role of the Product Owner is in high demand in... Read More

Useful links