Conditions Apply

Search

Agile Filter

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

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

3982
  • by Steve Ash
  • 05th Nov, 2018
  • Last updated on 24th Mar, 2020
  • 18 mins read
How Not to be Agile – Daily Stand-Up/Scrum

Introduction

Hello 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 Scrum

Daily Stand-Up Meetings in Scrum

The 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:

Daily Stand-Up Meetings in Scrum

  1. What have I been doing since the last stand-up?
  2. What do I plan to do before the next stand-up?
  3. 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 necessary
  • Using video-conferencing and a shared, electronic Team Board for distributed teams
  • Adding 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 process

The 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.

 Physical Team Board Example                                                                      Figure 1 - Physical Team Board Example 

Electronic 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 other
  • One or two members were overly verbose in their explanation of what they had done and what they were going to do

In 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:

  1. 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 using
  2. Whoever is running the daily stand-up, do not allow:
  • Detailed explanations of work done or planned to be done
  • Detailed discussions of points between 1 or 2 team members
  1. Matters will arise during the daily stand-up but discussion of these must be held over until the daily stand-up has finished

If 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.

Lessons

  1. The 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.
  2. 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 need

Case Study 3: 

There have been 3 occasions when time zones  played an important part in choosing when the daily stand-up should be held:

  1. 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.

  1. 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.

  1. 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:

  1. 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.
  2. 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’.
  3. 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:

  1. 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.
  2. 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.
  3. By engaging with the manager, it was possible to shift his ‘old school’ manner to one that understood Agile and could cooperatively support it.

Conclusion

The ‘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.
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
5920
Who Is a CSPO? - Roles and Responsibilities

1.1 What is a Product Owner?A Product Owner is a r... 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
5468
5 Things To Consider While Choosing A Professional...

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

Agile beyond IT – Streamlining The Recruitment Process

Recruitment is a challenging, time-consuming and costly process. It is not only challenging for the recruiter, but also challenging for the candidates.In one of my previous engagements, I had a chance to work with the hiring team to help streamline the Agile recruitment process and make it a wow experience for the recruiters as well as for the candidates. I would like to share the experience we had and how we built an improved Agile recruitment process by streamlining the process.The Challenge: Making the Agile recruitment process more streamlined and visibleFor one of the organizations distributed geographically, we had vacancies across various skill sets to be fulfilled within a certain timeline. However, we faced certain challenges which were typical to any hiring processes.Identifying the right talent and making the whole hiring process faster, visible and streamlined was an issue.Few of the challenges which we faced are listed below:Usage of the traditional talent acquisition tool for tracking the candidate’s profile.Prioritization is usually by whoever shouts loudest.The process was not harmonized across all business units.Non-availability of interviewer to interview the candidates.No established feedback communication channel (candidate and all stakeholders).Usage of too many spreadsheets, recurring meetings, emails for synchronization resulting in:Delay in responding back to the candidates.Delay in sharing the updates on the fulfillment leading to dissatisfaction among the candidates, hiring managers as well as the client.How did we get started?To respond to the above challenges, a meeting was scheduled between the recruitment team, engineering team and we brainstormed and identified a few of the pain areas that needed to be addressed on priority.One of the things which the team identified was that with multiple meetings, e-mails with CV from various sources, there was a delay in identifying and interviewing the candidate and that made the whole candidates suffer.At the same time, we had the executives and business heads across the various business units looking for a consolidated report on the status of the number of open positions and the hiring pipeline daily.So, we planned with priorities and focused on resolving the following-Make the candidate interviewing and onboarding process faster.Provide better visibility and reports to the senior management.Faster feedback mechanism.Agile and Kanban- Tools to make an Agile recruitment process efficientWe all know that the recruitment process is very dynamic. With every iteration, the requirement for the fulfilment may tend to change. To have a better control over the recruitment process and a quick adoption, Agile recruitment seems to be the way forward.As a team, we decided to start with Kanban and the reasons for the same are mentioned below:There was no need to change the current workflow to adopt this process of visualization.We tweaked a little bit and used only the visualization principles to help visualize the flow.We wanted to ensure that everybody has a visual representation of the workflow to help identify the bottlenecks. All the stakeholders became aware of the profiles in the pipeline and how we are moving across the different stages. It helped identify any bottleneck in the flow and take remedial actions.Focus on flowOur aim was to help decrease the candidate’s waiting time. By focusing on the flow of our hiring process, we wanted to spot issues before they arise and help improve communications as well as the candidate profile aging over time.Practice continuous feedback.Frequent connect to review, reflect and make suggestions for further improvement. Tweak wherever necessary.It offers the flexibility to the team.How did the process work?We started first with the candidate board to keep track of each of the candidate through the recruitment process. We started to map out the different steps that follow a candidate through our process and accordingly map each columnBelow is the sample Kanban board in Trello-This helped the team in visualization and identifying the bottleneck leading to a quicker resolution.How did we improve?We could see that the recruitment process was on its path to getting streamlined but as a team, we used to reflect and looked at ways of improving the process. We did the following:Had daily and weekly catch up and used to take feedback on what areas we can improve upon and accordingly modify the board.After a few months, we realized that we need to track the candidate’s onboarding to help the candidate’s experience to turn out to WOW. We updated the board to include the same.We also realized that the profiles can come from various sources (internal, referral, agencies etc.). We looked at updating the board to capture the source of the profile.How Kanban helped in creating an Agile hiring process?We knew that we were on the right track when we started visualizing the following:1. Focus on Priority Items:Everybody knew what’s coming down the pipeline, and we were ready for it.Candidate profiles didn’t get lost in the process.Helped in better prioritization of the demand.2. Increased Visibility:We could see the problems before they happened and pivoted.Greater visibility of the candidate status in the hiring process.3. Increased Communication:Faster decision making on the candidature.Quicker feedback to the candidate on the profile status.Better communication between hiring, engineering, management and customer.Building and fostering a collaborative environment.4. Time-saving:Time-saving by scrapping many meetings and e-mail loops.Applying Agile principles to the hiring process is not simple. It involves re-inventing the current process and applying the principles.However, Agile implementation in hiring process doesn’t need to be complicated in the beginning. We need to  look at the current process and identify the areas where we can leverage and improve the process.
Rated 4.0/5 based on 0 customer reviews
Agile beyond IT – Streamlining The Recruitme...

Recruitment is a challenging, time-consuming and c... Read More