Search

Series List 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

4384
  • 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

How Agile Can Help Remote Teams Work

Remote teams have their own pros and cons but managing remote teams can be a big challenge, specially when no working methodology is being followed. Thanks to the frameworks like Agile that the remote teams working in different parts of the world have equal chances of success. When you combine Agile and Remote Teams; you get Remote Agile Teams, which is possibly one of the greatest ease that modern world can offer.  Many businesses are now opting to get their work done via Agile Teams which are flexible, super-fast, dependable and most importantly efficient. There is a constant demand of Agile, especially for the Software development companies. According to the stats released by Atlassian in 2016, about 80% of the software development companies use Agile Software development methodology.  Since Agile is attracting so much businesses, it has become vital for remote teams to follow end to end Agile Development Methodology. Which has given birth to modern Remote Agile Teams.  Let’s look at ways that Agile benefits remote teams.    1. Clear milestones When working with remote teams the product owners usually don't set out clear milestones. Instead they just assign a project and when things go wrong both parties suffer. While with Agile the product owners and team decide the plan of execution for the project by setting out clear milestones. This way the remote teams even being on different continent know the expectations and goals for any project. Setting out clear milestones also help in avoiding any sort of problems that might come in way by outlining the requirements and deliverables first.  Read suggestions here: Divide Agile Software in clear milestones.  2. Daily and weekly reports  Agile includes concepts like Scrum and Sprint meetings. Sprint meetings are done to plan activities for upcoming weeks. The team and product owner mutually decide the deliverables for upcoming specific weeks. While Scrum meetings are held on daily basis with the team in which every team member reports the progress of their part and any possible hurdles. All these reports are communicated with the product owners to stay on the same page and to avoid any potential issues. Remote teams specifically can benefit from this framework as it doesn't leave any room for confusion and the progress of remote team can be easily tracked with Agile methodology.  Learn more about Scrum and Sprint here.  3. Diversity support Remote teams have the best chances to bring diversity and experience into the overall culture of any organization. Your one team might not have the same creative and experienced approach which can be a main foundation of your team. Agile supports the diversity of remote teams because it provides a well organized framework to get the work done according to the requirements. While Agile is always open to changes the team can offer the best solution to any changes, thus highlighting and supporting the diversity of all remote teams. Learn how Agile can unlock diversity.  4. Flexibility  Agile promises flexibility! And with the higher affordability of remote teams, it becomes even more promising to go for it. Remote teams have different expertise and usually higher affordability but when you put Agile in the mix all teams can be made flexible, dependable and co-operating because of core Agile principles. Agile Teams and product owners go hand in hand for success of the project and due to flexibility of Agile, any desired or unforeseen circumstances can be catered. 5. Timely Deliveries Another prominent benefit of Agile is that you get the work done within the project time. When working with Agile you get to set the milestones together with team and still leave room for any extra problem that may come. What can and can’t be achieved is usually cleared out first and then the deadlines are set. However, if any problem comes in the way, the cushion time can be consumed. When the remote teams work on Agile principles, they can meet their deadlines and with the Agile flexibility it becomes even easier for the remote teams to make timely deliveries.  6. Lower Risks Remote teams have higher risks because of communication gaps and expectation differences.  However, when working with dependable Agile Teams, you thoroughly minimize the risks of failure. These risks range from the investment risks to productivity risks; thanks to Agile these risks are not a problem anymore. Mainly because of constant feedback from the product owners, the risks for any sort of changes afterwards can be thoroughly eliminated. Also, the constant feedback sets out the right way for team to progress, which is very important for remote teams.  Read in detail how Agile helps you reduce risks here.  7. Agile project management tools Agile took the world by storm because of its strong concepts and that why many realized its potential to help in software development. There are many Agile project management tools available in the market. However, only few are rather detailed and customizable. Two most detailed Agile projects management tools are Jira and Yodiz. Jira is owned by Atlassian and Yodiz is run by Viztrend. Both tools have Agile as core and are very customizable, however Yodiz edges out Jira in terms of cost effectiveness. These tools are a bliss for remote teams and help them work on Agile principles with extensive features support that help in easy Sprint planning and project tracking.  Final Thoughts  Agile has made lives easier by giving a very easy and flexible framework for project management. This even becomes more interesting when it works even better for remote teams. Remote teams working on Agile methodologies are efficient and productive as compared to non-agile remote teams.  Remote teams working on Agile:  
Rated 4.0/5 based on 20 customer reviews
How Agile Can Help Remote Teams Work

Remote teams have their own pros and cons but mana... Read More

Scrum Master Certification Cost

Over the past few years, the job market has witnessed an exponential growth in the demand for Scrum Master professionals. Getting a certification for the same will help you reach milestones in your career. Becoming a certified professional will not just help you grow in your career, but you can also draw a higher salary from your organisation.With varied certifications available to opt for, you might be confused on which to decide on. But, fret no more! Help yourself with the following compilation of Scrum Master certifications and their costs, which includes the cost of certification as well as their renewal costs. The following table lists the certifications with their cost and renewal cost for different certifications. Sr. No.CertificationCost of CertificationRenewal Cost1.CSM2-day Certified ScrumMaster (CSM) course costs around $1000-$1400$100 and 20 SEUs, every two years2.PSM$350 if opting for training, depending on the training provider$150, if opting for the examinationNot required, has lifetime validity.3.SAFe® Scrum Master$995-$1,295, which includes the mandatory course fee as well as the exam fee.Each retake after the first attempt costs $50.Not required, has lifetime validity.4.EXIN Agile Scrum MasterThe examination cost comes around $260.$100, every year.5.Scrum Master Certified (SMC™)The examination cost comes around $450.Maintain a minimum of 40 Recertification Units (RCUs) every three years.6.Scrum Master Accredited Certification™$69Not required, has lifetime validity.Read along to know more on the Scrum Master certifications listed above in the table. The main objective of the same is to provide you with an in-depth knowledge of the cost of the various Scrum Master Certifications as well as their renewal costs.   1. Certified ScrumMaster (CSM)Certified ScrumMaster (CSM) is the most widely acknowledged Scrum Master certification. To attain the Certified ScrumMaster (CSM) certification, you will be required to attend a 2-day classroom training, following which you will have to take an online test. Certified ScrumMaster Certification CostDepending on where you choose to get your training from, the 2-day Certified ScrumMaster (CSM) course costs around $1000-$1400. This cost covers the following:The 2-day courseFirst two years of certification Two attempts to take the exam (within 90 days of attending the course) Course materials which will be provided by the instructor in the class Two-year membership to the Scrum Alliance community Certified ScrumMaster (CSM) Renewal costYou need to renew your CSM credentials by paying a renewal fee of $100 and earning 20 Scrum Educational Units (SEUs). This renewal fee includes the Scrum Alliance membership fee, which has a validity of two years. CertificationCost of CertificationRenewal CostCSM2-day Certified ScrumMaster (CSM) course costs around $1000-$1400$100 and 20 SEUs, every two years2. Professional Scrum Master™ (PSM)Offered by Scrum.org, Professional Scrum Master™ certification is highly sought after. It is a 2-day long course that covers the principles and process theory of the Scrum framework, along with the roles of a Scrum Master. The Professional Scrum Master™ assessment is available for anyone who wishes to exhibit their fundamental level of Scrum mastery.Professional Scrum Master™ Certification CostIf you feel that you have a high level of Scrum knowledge, understand the Scrum Guide and the process to apply Scrum within Scrum Teams, then taking the course is optional. You can take the PSM I assessment directly, which costs $150 per attempt. But if you choose to attend the 2-day training, then the exam fee will be included in the course price, which costs around $350, depending on the training provider. You’ll have two attempts to clear the exam if you choose to attend the training, as opposed to the one chance that you will get when attempting without any training. Professional Scrum Master™ Renewal CostCertifications provided by Scrum.org hold a lifelong validity. Hence, PSM certification does not require any additional payment or renewal. CertificationCost of CertificationRenewal CostPSM$350 if opting for training, depending on the training provider$150, if opting for the examinationNot required, has lifetime validity.3. SAFe® Scrum MasterBy attending a 2-day course, gain a proper understanding of the roles of a Scrum Master in a SAFe® environment. Explore the roles of a Scrum Master at an enterprise level and learn ways to execute the Program Increment successfully. Learn various approaches to become a servant leader and coach in order to build high performing Agile teams.The SAFe® Scrum Master certification is accredited by Scaled Agile.SAFe® Scrum Master Certification Cost:The course registration fee includes the first attempt of the exam, provided the exam is taken within 30 days of completion of the course, after which each retakes attempt costs $50.The certification costs for around $995 - $1,295, which includes the mandatory course fee as well.SAFe® Scrum Master Renewal Cost:SAFe® certifications are valid for one year. After completion of the first year, you will have to get your certification renewed by paying a renewal fee of $100. CertificationCost of CertificationRenewal CostSAFe® Scrum Master$995-$1,295, which includes the mandatory course fee as well as the exam fee.Each retake after the first attempt costs $50.Not required, has lifetime validity.4. EXIN Agile Scrum Master (ASM)The EXIN Agile Scrum Master certification stands unique dues to its combination of Scrum practices and Agile methodologies with practical assignments. The certification tests the proficiency of a Scrum Master, who coaches, facilitates and enables a cross-functional team. Professionals belonging to the fields of business management, IT project management, software development, IT service management can opt for the EXIN Agile Scrum Master certification. EXIN Agile Scrum Master certification Cost: The examination cost for EXIN Agile Scrum Master certification comes around $260, without any training. If in case you decide to opt for the training course, it will include the exam fee as well.EXIN Agile Scrum Master Renewal Cost: There isn’t any renewal cost for EXIN Agile Scrum Master certification as it has lifetime validity.CertificationCost of CertificationRenewal CostEXIN Agile Scrum MasterThe examination cost comes around $260.$100, every year.5. Scrum Master Certified (SMC™):It is the responsibility of a SMC™ professional to ensure that the Scrum Team is working under proper conditions which helps teams in completing projects in a successful manner. He has to make sure that the Scrum process is being followed, along with guiding, facilitating and teaching scrum practices to all the members involved in the project.The Scrum Master Certified (SMC™) certification is accredited by SCRUMstudy.Scrum Master Certified (SMC™) Certification Cost:The cost of SMC™  certification examination is $450.Scrum Master Certified (SMC™) Renewal Cost:To maintain your certification, you need to maintain a minimum of 40 Recertification Units (RCUs) every three years.CertificationCost of CertificationRenewal CostScrum Master Certified (SMC™)The examination cost comes around $450.Maintain a minimum of 40 Recertification Units (RCUs) every three years.6. Scrum Master Accredited Certification™Accredited by the International Scrum Institute™, the Scrum Master Accredited Certification™  Program is an online test examination which can be taken from anywhere in the world. It has a success rate of 98%.Scrum Master Accredited Certification™ Cost:The certification and test costs for Scrum Master Accredited Certification is $69. There are no other hidden costs or fee involved. CertificationCost of CertificationRenewal CostScrum Master Accredited Certification™$69Not required, has lifetime validity.
Rated 4.5/5 based on 2 customer reviews
8713
Scrum Master Certification Cost

Over the past few years, the job market has witnes... Read More

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
5759
Who Is a CSPO? - Roles and Responsibilities

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