Conditions Apply

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.
Rated 4.0/5 based on 68 customer reviews

How “Not” To Be Agile – Vision and Objectives

4590
  • by Steve Ash
  • 02nd Aug, 2018
  • Last updated on 05th Mar, 2019
  • 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

Who Is a CSPO? - Roles and Responsibilities

1.1 What is a Product Owner?A Product Owner is a role defined in Scrum. Scrum is a framework for complex product development (*). The Product Owner is responsible for maximising the value of the product resulting from the work performed the Development Team. The role exists in Scrum to have 1 person with a clear accountability of WHAT product or service will be built. The Product Owner role is also used as a title outside Scrum, in other frameworks, but if you want to understand the definition of the role and responsibilities of a Product Owner, you need to start to look and to understand it in the scope of a Scrum Team. (*) (“product”, to be defined in context, this is a generic term for the product or service being developed for the end-users)(*) (“development”, also to be defined in context, this is a generic term for all activities needed to create and deliver value to the end-users)1.2 What’s the job profile of a Product Owner?The Product Owner role is Scrum is a role, both with a tactical, strategical and operational aspect. The Product Owner role is critical as the role is kept by 1 person (and 1 person only) for a specific product. Having 1 person holding the role simplifies the accountability in terms of having 1 spokesperson for product ownership and accountability of maximising value. This doesn’t mean that all activities are to be done by the Product Owner; otherwise the Product Owner could become a bottleneck. The Product Owner does remain accountable at all times. To be able to do the job, the Product Owner has business (domain) knowledge, affinity with end-users, affinity with “development” (activities needed to deliver a piece of value), and knowledge of how to do agile product management. Product management is a multi-disciplinary job, and it involves to understand, empathise, quickly inspect & adapt, each time with the accountability to make the right choices in terms of what to built next, in order to continuously (incrementally) deliver value to end-users. In order to better understand what kind of profile is needed to fulfil the product owner role, it’s valuable to list skills required and activities performed.When looking for a Product Owner, you’re looking for a profile with generic product management skills and product-specific skills.  The generic skills are needed to be able make decisions on a strategic and tactical level.People skills a Product Owner must have:A Product Owner also needs people skills:To empathise with users of the productTo build connections with stakeholders and to create a healthy working relationship with the team building the product. These people skills include- to be able to listen (to stakeholders, end users, team members), to translate information (between people with a different background), to be able to make  informed decisions without undermining longer-term objectives, etc.The product-specific skills are defined by the product or service that’s being built. This includes all the activities to understand the market, the needs, the job the product or service will fulfil, user-journeys, also more technical product-specific knowledge, legislation (if applicable), financial implications and any other constraintIn his book Product Mastery “From Good to Great Product Ownership”, Geoff Watts describes the skills of Product Owners with the acronym “1.3 Product Owner role and responsibilitiesThe role of Product Owner can be quite challenging and high-demanding. When reading The Scrum Guide, it says that product backlog management is the main activity for a Product Owner. The product backlog is a tool to ensure it’s clear what’s needed in the product and what’s the most valuable thing to build next. Managing a backlog, and refining items on the product backlog is a continuous activity.  The Product Owner often serves as the spokesperson of the product. This means he/she needs to be able to answers questions appropriately, for example regarding product vision, roadmap, planning, why certain choices have been made, etc. This also includes NOT answering certain questions, because the Product Owner knows the development team is in a more appropriate position to answer the question more accurately, and as well to facilitate a conversation with the development team involved.Go through other roles and responsibilities of Product Owner here.1.4 How does a Product Owner manage various stakeholders desires for the product?The Product Owner has the challenging task to manage requirements and desires of stakeholders. Each stakeholders will certainly advocate his/her demands are the most important. Here are some recommendations on how a Product Owner can deal with this:Treat requirements & desires as “desirements”, meaning, until by learning or by end-user feedback has been proven that the “desirement” is valuable, treat it as a hypothesisKeep the product backlog and its ordening as transparent as possible to all stakeholdersDon’t be seduced to prioritising in categories such as high, medium, low priority. A product backlog is ordered, no two items can have the same priority.Use techniques to prioritise impacts (impact mapping), simulations to learn stakeholders to prioritise (e.g. buy a feature), techniques to slice for value (user story mapping) 1.5 CSPO vs PSPO CSPO is an abbreviation which stands for Certified Scrum Product Owner. This is a certification offered by the Scrum Alliance, specifically for the Product Owner role. PSPO is an abbreviation which stands for Profession Scrum Product Owner. This is a certification offered by scrum.org, specifically for the Product Owner role.In my opinion, both certifications are equivalent and define a high-quality standard. There’s a difference in the way of obtaining certifications and how to maintain this. Certifications issued by Scrum Alliance are obtained by taking an online exam after mandatory attending a 2-day training given by a Certified Scrum Trainer.Certifications issued by scrum.org are obtained by taking an online exam without the prerequisite of attending a training. Certifications issued by scrum.org do not expire. Of course, to test and validate your knowledge, having a decent understanding of the product owner role is mandatory, therefore preparation and study are key. Participating in a training to learn, and to experience what Scrum is about, is always highly recommended.1.6 Product owner in agile software development The manifesto of agile software development does not specify anything about the Product Owner role. Therefore, it’s perfectly possible to have an agile team without a Product Owner.The manifesto for agile software development does state a few principles which illustrate how we want to work regarding product and value delivery, for example:“Our highest priority is to satisfy the customer through early and continuous delivery of valuable software;”“Welcome changing requirements, even late in development;”“Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale;”“Business people and developers must work together daily; ““Working software is the primary measure of progress;”You can interpret these principles as following, in what you should NOT be doing…Waste time & effort creating long-term plans, long cycle times, etc without actually delivery usable product increments to the end-users, …Waste time & effort on unnecessary specifications; unfinished product (“inventory”); or unvalidated requirements (which are assumptions in disguise), …Waste time & effort on unnecessary handovers between business people and development teams, …Waste time & effort on assuming what’s valuable for the end-users, and not verifying this by letting end-users try out working software and based upon their feedback, inspect & adapt, improve the product together, …Wasting time & effort in demanding upfront detailed estimates for unreasonable long periods (e.g. all estimates for the next year…)Wasting time & effort on detailed long-term planning, fixing agreements, treating change as evil, …1.7 Product owner in Scaling AgileLets first make the statement that you need to consider it twice before blindly scaling up any development efforts. In general, we are trying to deliver value by keeping things simple, simplify working processes, and collaborate to maximise effectiveness and customer satisfaction. In case you need to align several development teams to work together on the same product, take the following into account:A product has 1 product owner, this means in case of several teams developing on the same product, there’s 1 product ownerA product is defined as something meaningful and valuable for a customer or end-user, not a technical componentA product has 1 product backlog, as long the product lives, the product backlog existsA product owner can delegate areas of the product to other product owners, but take care to not have “proxy” product owners, with a mandate to decide. The ‘chief’ product owner remains accountable for overall prioritisation. Some scaling frameworks make a distinction between “product management” and “product ownership”, in any case ensure there’s alignment regarding product management, no conflict in priorities, and no unnecessary handovers of information.1.8 Who is accountable for the business value delivered by a Scrum team?The Product Owner is responsible for maximising the value. A Scrum Team collaborates to deliver value together. The Product Owner remains  accountable.1.9 What exactly is the role of the Product Owner during the Daily Scrum?The Product Owner is not required to attend the Daily Scrum. The Daily Scrum is an inspect & adapt time-boxed event for the development and performed by the development. This is defined in this way because otherwise the Daily Scrum will quickly be run as a status meeting (and not a daily planning event). Of course, the Product Owner can be present during the Daily Scrum, as it’s a great moment to check-in with a team, listen how a team is synchronising, ask and answer questions - after the Daily Scrum. The Product Owner, nor the Scrum Master should be leading the Daily Scrum. They can be present, but the Daily Scrum is an activity (‘Scrum’ metaphor of Rugby), for and by the development team. The Product Owner defines a sprint goal (a sprint is a time-boxed iteration to deliver a potentially shippable product increment); the Development Team inspects its progress on a daily basis towards that sprint goal, using the sprint backlog.1.10 What are certain anti-patterns regarding Product Owner?Some example anti-patterns regarding Product Owners; this can be used in an exercise to coach Product Owners. Ask what should be done to be the WORSE Product OwnerIdentify what’s actually being done of that listIdentify what should be STOPPED doing, in order to improveSome anti-patterns of Product Ownership Becoming a bottleneck in communication, so that’s there’s a delay in the flow of value between the development team, end-users, and stakeholders, …Taking decisions in isolation, so that the reason why decisions are taken are not known, nor understood, …Specifying technical solutions, and not articulating the business value, … (technical solutions are the responsibility of a development team)Pressuring the speed of delivery, resulting in less quality and inability to validate if value is being delivered, …Not listening to the product development team’s recommendations, not engaging in any healthy dialogue, …Not articulating the product’s vision, and/or strategy, resulting in development teams functioning as “feature factory”, without investigating what’s valuable and what’s not, …Inadequate product backlog management, resulting in unready items to plan, long inventory, unclear prioritisation, …Not accepting or rejecting work according to the definition of done, resulting in unclear standards of what’s a done product increment, …Not thinking how to delivery slices of value, forcing development teams to deliver components, instead of ready-to-use product increments, …Not facilitating a sprint reviewNot participating in any retrospectiveNot updating any forecast after finishing a sprintNot engaging with end-users / customers to get feedback etc2 What is the process to get a CSPO certificate?You can also follow the below steps to understand clearly.Find a Certified Scrum Product Owner course on the Scrum Alliance websiteRead and understand the Scrum GuideRead and understand the manifesto for agile software developmentRead and understand the learning objectives of a CSPO courseAttend the 2-day CSPO courseComplete the online CSPO exam, the fee is included in the course price. After completing the course, your Scrum Trainer will upload your user information into the system of Scrum Alliance, next you’ll receive an invite to do the online exam. Recommended books and material to read and further prepare:Articles by Roman Pichler,Book Product Mastery, by Geoff Watts,  Path forward after CSPO at Scrum AllianceCertification gives you access to a renewable, two-year membership with Scrum Alliance. As a Certified Scrum Product Owner (CSPO™), you can continue your educational development to become an:Advanced Certified Scrum Product Owner (A-CSPO™)Certified Scrum Professional - Product Owner (CSP-PO™)Certified Team Coach (CTC™)Certified Enterprise Coach (CEC™) Certified Scrum Trainer (CST™)Remember, if you’re starting as Product Owner, the CSPO certification is only the start of your journey!ConclusionBeing a product owner is a satisfying job! You are the main spokesperson for the product. You act as a catalyst between the Development Team and the outside world. You take decisions to maximise product value while taking into account various constraints.
Rated 4.5/5 based on 2 customer reviews
5919
Who Is a CSPO? - Roles and Responsibilities

1.1 What is a Product Owner?A Product Owner is a r... Read More

How Not to be Agile – Daily Stand-Up/Scrum

IntroductionHello and welcome to this, the fifth article in the series ‘How Not to be Agile’‘How Not to be Agile’ may seem a strange title for blogs about how good Agile is.  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 when an organisation, or part of it, embark on an Agile Transformation.In this article, I will cover some of the misunderstandings and malpractices that I have come across to do with the daily stand-up event; all the Agile frameworks use the term ‘daily stand-up’ for the event except Scrum which calls it a ‘daily Scrum’.As I said before, it is the content and management of the daily stand-up that is important; call the event what you like.I will start with a description of the daily stand-up and then give examples of what can go wrong.Importance of Daily Stand-Up Meetings in ScrumThe concept of a daily stand-up was first introduced to the Agile community by the Scrum framework and has since been adopted by all other Agile frameworks.The idea behind a daily stand-up is to give the whole development team an opportunity to see what has been happening in the development timebox since the previous stand-up, what is planned to be done before the next stand-up and to state any problems that they may be having.The development team uses the daily Scrum stand-up to inspect progress toward meeting the development timebox goal and the likelihood that the development timebox MVP will be met.This is recommended to be done by each team member answering 3 questions:What have I been doing since the last stand-up?What do I plan to do before the next stand-up?What blocks/impediments/issues/problems am I having?Developments over time to the daily Scrum meeting process include:Carrying out the stand-up in front of the Team Board and updating it as necessaryUsing video-conferencing and a shared, electronic Team Board for distributed teamsAdding questions such as:Has anyone given me a requirement change request?Have I learned anything about this product development that I think everyone should know about?Do I have any worries about how the team is progressing?The Scrum Guide states that the daily stand-up should take no more than 15 minutes; the Agile Project Framework suggests that normally the daily Scrum stand-up should not last more than 15 minutes but also suggests that 2 minutes per participant + 2 minutes is a good guide; for a team of 9 members this would equate to 20 minutes.If there are any ‘matters arising’ from the daily stand-up, most teams will delay discussion until after the stand-up is finished and then only those that are needed for the discussion stay behind; the rest go back to work.What the Daily Scrum Meeting is Not?During early Agile transitions it is ‘tempting’ for the management to ‘watch’ the development team closely and the daily stand-up turns into a ‘reporting progress to management’ session.This is NOT what the daily stand-up is for and all attempts to turn it into one must be resisted.An Alternative to Daily Stand-Up processThe Kanban framework and other lean process practitioners realised that the ‘standard’ 3 questions above are not really relevant because people just need to take a look at the Scrum Board (kanban) to see what they did recently and what they will do the next; remember the use of a Team Board is not ‘mandatory’ in most of the Agile frameworks but it would be unusual for a team not to use one, whether a physical board or an electronic one.                                                                     Figure 1 - Physical Team Board Example                                                                                             Figure 2 - Electronic Team Board Example So, here are the questions that a Kanban user answers:What is impeding us?Assuming, that the meetings take place in front of the board, there isn't even a need to discuss what items are impeded (since this will be visible on the board).  Therefore, all there is to focus on, is the possible and the best solutions to the problematic items.What's the flow like?Because Kanban is all about the workflow, what should be discussed at this point are any possible changes that the team can make in order to make the flow even smoother and efficient.  Also, should there be any bottlenecks, the daily stand-up is the right time to work on their best resolution.What can we improve? (how to achieve Kaizen?)This is a question is the means by which the entire team is empowered to strive for constant improvement; by allowing for the change suggestions to come from anyone in the team, there is a big chance of success.Effectively, the Kanban Framework incorporates every day what other frameworks do in the Retrospective.Whatever Agile framework that you use, if you adopt a Kanban style Team Board, you may want to use the Kanban questions during your daily stand-ups.Who Should Attend the Daily Stand-Up?It is important that all of the development team, both full and part-time, and the Agile Project Manager/Scrum Master attend the daily stand-up:The whole development team needs to be there because all team members need to be aware of what is happening in the development timebox, state any problems that they may be having and potentially offer help to other team members who may have problems.The Agile Project Manager/Scrum Master needs to be there as the Risk and Issue Manager to listen to the problems that any team members may have.The daily stand-up should be run by the development team although, in some organisations, the Agile Project Manager/Scrum Master runs the event.Other people outside of the Development Team are ‘welcome’ to attend daily Scrum meeting but are not allowed to speak; they are only there to observe the process.When Should the Daily Stand-Up Take Place?One of the tenets of all Agile frameworks is to have a cadence or ‘heartbeat’; events should be scheduled on the same day, time, and place for the whole product development time.It is strongly recommended that the daily stand-up should be scheduled to take place in the same place at the same time every working day.Case Study 1:In several organisations that I have coached in, when I arrived, the daily stand-ups were taking upwards of 30 mins; this was because:There was a detailed discussion between 1 or 2 team members about some topic or otherOne or two members were overly verbose in their explanation of what they had done and what they were going to doIn all cases, the majority of other team members were not interested in the details of the conversations or another’s work; some used the ‘wasting my time’ reason to avoid attending the daily-stand-ups.In one organisation, I was teaching an Agile class and on day 2, 3 delegates turned up 1 hour late for a 9am start.  I asked, politely, if they had a problem attending on time and was told that they had to attend their team’s daily stand-up; a laudable reason.  When I asked what time their team’s daily stand-up started I was told 9am; the event had taken 50 minutes!What was worse was that one of the delegates was supposed to be the Scrum Master for the development!Lessons:Don’t start Agile product Development without the Agile PM/Scrum Master having had at least 2 days of training on the Agile framework that they should be usingWhoever is running the daily stand-up, do not allow:Detailed explanations of work done or planned to be doneDetailed discussions of points between 1 or 2 team membersMatters will arise during the daily stand-up but discussion of these must be held over until the daily stand-up has finishedIf a team member says they have an impediment and it can be solved in about 15 seconds, then that is OK; for example, a team member may say:“ I cannot get hold of person XYZ to get the information I need”Another team member may have had the same problem in the past and may say something like:“He/she never answers the phone during the morning; call him/her after 2 pm”Case Study 2:For one engagement that I was working on, the Development Team was dispersed in 5 locations in 3 different time zones.  I noticed that one team member in another location never attended the daily stand-up; the Scrum Master obtained the answer to the 3 questions later in the day over the phone.I asked the Scrum Master why this was so and he told me that the person was in a time zone 1 hour behind the main team and had travelling difficulties getting into work for the daily stand-up time.I asked when the team member could ‘guarantee’ getting into work and would there be any problem moving the daily stand-up time.  It transpired that the time of the daily stand-up could be moved to suit the team member without inconveniencing any of the other team members.LessonsThe time for the daily stand-up should be set when all development team members have a good chance of attending; this is important for geographically dispersed teams.The Scrum Master gathering daily stand-up information after the event wastes his/her time and the rest of the team miss the opportunity to have all the information that they needCase Study 3: There have been 3 occasions when time zones  played an important part in choosing when the daily stand-up should be held:The main team was in Tokyo, there was a sub-team in Beijing, the ‘customer’ was in San Diego and management was in Helsinki; this was the first Agile product development for this team although other teams in the organization had transitioned.Although it is not normal for the customer or management to attend the daily stand-up, in this case, both the customer and management wanted to attend to make sure that the team were ‘on the right track’; the fact that I had trained the main team hadn’t given the management sufficient confidence!But the time zone differences made it difficult to choose an appropriate team for all attendees.Because there were only 1 customer and 1 manager who wanted to join the stand-up, it was decided to hold the stand-up at 1pm Tokyo time to inconvenience the main and sub-teams the least; for the customer in San Diego it was 11pm and for the manager in Helsinki it was 5am.We ran like this for 1 week after which both the customer and manager decided that they were happy with the way the main team and sub-team were operating.The Development Team were in Cebu, Philippines, and the Product Owner was in Duluth, USA; the Product Owner wanted a daily update on how the requirements were being implemented.There was no overlap in the work times of the different time zones so it was decided that the Scrum Master would start work at 1pm Cebu time, the daily stand-up would be run at 2pm Cebu time and the Scrum Master would update the Product Owner at 9pm Cebu time, 8am Duluth time.The majority of the team were in Dundee, Scotland with a few team members in Hyderabad, India.In this case, there was a 3.5 hour overlap in the work times of the different time zones so it was decided to run the daily stand-up at 10am Dundee time and 3:30pm Hyderabad time.Lessons:Although this Case Study does not demonstrate anti-Agile behaviour, it is worth noting the following lessons:When deciding a time to run the daily stand-up, the time should be set to inconvenience the development team members as little as possible; other people must choose whether their attendance during ‘unsocial hours’ is worth it to themselves.The Agile PM/Scrum Master does not have to work the same hours as the rest of the development team in the same time zone; it does depend on whether the Agile PM/Scrum Master is prepared to work ‘unsocial hours’.Where work times overlap across time zones, ensure that the time to run the daily stand-up is within the work times of all time zones. Case Study 4:I was coaching a team that was in the early stages of an Agile transformation and the team members had picked up the basics well; the daily stand-ups were running well with some good banter and team member help being offered freely.During one stand-up, I noticed a marked lack of relaxation amongst the team members when speaking and their heads were down most of the time.I asked the Scrum Master if he knew the reason for the change of atmosphere and she said that she had expected something like it but not quite so marked.There had been a manager attending for the first time; this manager had a reputation for being a bit ‘old school’; “do as I say and no arguments”.After confirming with the team members that they had felt intimidated, I researched the manager and discovered that he headed a department that was just starting to try Agile; the manager had attended the stand-up just to see how it worked and had had no intention of ‘interfering’ or making any opinions about the team members.I asked if he would like me to coach ‘his’ team through their early Agile events; he accepted and I invited him to attend all the events as an observer.After each event, I mentored the manager about his opinion of what went on.  He had a few questions about ‘why this’ and ‘why that’ and I was able to answer his questions to his satisfaction.I asked ‘his’ team members what they thought of having the manager at their events and they said that they had had some trepidation at first but after they could see that he had been there to learn and had not lived up to his previous reputation, they became quite comfortable with the manager’s presence.I told the members of the original team of this apparent change to the manager’s ‘personality and asked if he could attend the next daily stand-up; they agreed and the next stand-up with the manager present went as ‘normal’.Lessons:If there is a change of demeanour of any individual or several team members, investigate the reason; it is most probably an impediment to smooth team running.The Scrum Master could have just asked the manager not to attend anymore but given the manager’s perceived reputation, that would have taxed the Scrum Master’s diplomacy skills.By engaging with the manager, it was possible to shift his ‘old school’ manner to one that understood Agile and could cooperatively support it.ConclusionThe ‘mechanics’ of the daily stand-up are relatively straightforward if the rules of the Daily Scrum are followed strictly in a daily routine. Collated below are the best practices while implementing daily Scrum:All development team members must attend, both full and part-time members.The time and place for the daily stand-up should be chosen to give the least inconvenience to the development team members.Geographically dispersed teams can run daily stand-ups using video-conferencing and shared desktop facilities.The questions to be answered by development team members should be adjusted to suit the type of Team Board being used.Non-development team members are welcome to attend daily stand-ups but are not allowed to speak.If the attendance at a daily stand-up of a non-development team member is considered to ‘intimidate’ one or more team members, this is an impediment and the resolution must be sought.
Rated 4.5/5 based on 11 customer reviews
3981
How Not to be Agile – Daily Stand-Up/Scrum

IntroductionHello and welcome to this, the fifth a... Read More

5 Things To Consider While Choosing A Professional Scrum Master Certification

With ScrumMasters gaining an increased demand and a lot of scope when it comes to career prospects, certifications are abundant. You can choose between a variety of courses to learn the Agile and Scrum practices. Eventually, you’re left with a choice between being a Certified Scrum Master and a Professional Scrum Master. Let’s take a quick look at which is a better course for you. CSM Vs. PSM You can easily obtain a CSM by just attending classes, whereas for a PSM, you mainly require assessment skills. Both the courses are priced around the same range, and with CSM your study material would include only the course outline. The training required is mandatory and with each instructor, you get to learn through a different training material with CSM. For PSM, you don’t need any training and the training is standardised throughout. CSM gives you a superficial knowledge on the subject, whereas with PSM a comprehensive knowledge is assured. The biggest advantage is that PSM does not require any certificate renewal, which is not the case with CSM certification that must be renewed every two years. Here are some important factors you must consider before kickstarting the course.   1. Name When choosing the best options, you have to consider a reputed course and institution. You can rely on them and can expect a hassle-free training process from experts around the world. The PSM has a globally recognised brand name that can designate an identity to you across most organisations all over the world. 2. Content CSM may be a more popular course, but PSM has a thorough syllabus that tests your true abilities in the fields of Scrum and Agile. The course is definitely a more difficult one, but pursuing it only proves your capabilities and calibre as a Professional ScrumMaster. PSM gives you a more practical approach as it deals with assessment over just a training session. You’ll be exposed to research on vast areas of Agile and how you can implement them into your projects and encourage your teams to implement the practices. 3. Exam While CSM requires just attending of classes to clear the exam comprising of 35 questions and a reasonable pass mark of 65%, PSM requires a lot more effort. To crack a PSM exam you need to go through an open assessment that tests your capabilities to take up the exam. The actual exam consists of 80 questions, and a minimum of 85% is required to pass the exam. There is also the additional pressure of time limit in PSM. Clearing the challenging PSM exam definitely adds value to your bio data. You will definitely have an upper hand at bagging a great job when compared to CSMs. 4. Training You can prepare for a PSM certification by yourself but the process could take longer and requires a lot more effort. Find the right choice from the list of reputed institutions that offer tactful training to crack the certification exam. The availability of trainers is also an important factor. If there is a scarcity in the number of instructors, you’ll end up attending a class with a large size, which in turn affects the quality of learning. 5. Cost While PSM is priced nominally, at around the same price as CSM and other Agile courses, it is absolutely worth your money. With an enhanced practical knowledge, the certification gives you a better idea on how to deal with real-time situations and problems that you are likely to face managing a team. Additionally, your career prospects are more promising with a PSM certification. Before you choose to enroll yourself in a famed institution or even decide to take up the test, research and identify the right school with courses that best suit your qualifications, requirements, and time constraints. If you choose to prepare without external assistance, gear up to put in extra effort from your end.
Rated 4.5/5 based on 1 customer reviews
5467
5 Things To Consider While Choosing A Professional...

With ScrumMasters gaining an increased demand and ... Read More