Search

Series List

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 3550
  • by Steve Ash
  • 05th Nov, 2018
  • Last updated on 13th Nov, 2018
  • 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

How To Pass Leading SAFe® 4.5 Exam ?

Scaled Agile Framework is a roadmap that leads the organizations in implementing the Lean and Agile Practices. SAFe® includes the three foundational bodies of knowledge that are System Thinking, Lean Product Development, and Agile Software Development. It helps the organizations to improve themselves according to the business requirements, deals with challenges involved in developing and delivering ideal software and systems within a specified time. SAFe® practices are essential but, sometimes they can be complex and entail some challenges. It might be easy to deal with such challenges and move your enterprise towards SAFe® practices by becoming a professional SAFe® Agilist. Passing a SAFe® Agilist Certification exam proves that you are an expert in implementing Agile and improving the project you want to get involved in.Here, in this article, we will guide you through your Leading SAFe® 4.5 exam preparation.Firstly, the 2-day Leading SAFe® 4.5 training is the most crucial part of this certification. Join the course and ask all the doubts you have during the workshop without any hesitation. Make a note of all the important things which will be helpful for future references. After completing the course successfully, you should pass the exam to obtain SAFe® Agilist Certification.Exam DetailsFormat of the examThis is a web-based, timed, and closed book exam that will be conducted in English and delivered in the format of multiple choice questions. Upon completion of the Leading SAFe® training, candidates will get access to the exam within the SAFe® Community Platform. Candidates will have 90 minutes to finish the exam once it starts.The exam consists of 45 questions in total and you must answer a minimum of 34 questions correct out of 45. You can take the exam at any time and the fee for the first attempt will be included in the course registration fee only if the exam is taken within 30 days of course completion.Retake policy of the examIf the certification exam is not cleared in the first attempt, you can retake the exam again and again, but each retake costs $50.You can take the second attempt immediately after the first attemptYou need to wait for a minimum of 10 days to retake the exam for the third timeA minimum of 30-day wait is required to retake the exam fourth timeCandidates are not allowed to retake the exam, once they got a minimum passing score of 76% unless there are updates announced to the exam.Exam preparationThe exam is specifically designed to analyze the skills and knowledge of a particular candidate. Develop a study plan before going to take the exam.Here are a few important points you should remember-You should gain both practical and theoretical knowledge in order to pass the exam successfully.The course materials are more helpful to prepare for the exam and we at KnowledgeHut offer course materials authored by the Scaled Agile Academy. These materials can be used for referring the concepts that are presented during the training.Take the practice tests that are designed with the same level of difficulty, time duration, and the same number of questions. You can take the exam without any additional cost. The practice tests once completed, let’s you know the chapters you should study more in pink color. Study those topics again.  As a preparation, on scaledagileframework.com, on the big picture (framework) click on the words if have confusion/not sure and read the guidance article. It makes you prepare well for the main certification exam and boosts your confidence level.Choosing a right path takes you to important destinations in your career. Becoming a SAFe® 4.5 Agilist is a career path for many and it requires an excellent range of skills. The best institute guides you towards a bright career. So, choose the right and best institute that is authorized to do so and can help you reach your goals.
Rated 3.5/5 based on 4 customer reviews
2291
How To Pass Leading SAFe® 4.5 Exam ?

Scaled Agile Framework is a roadmap that leads the... Read More

Scrum Master Job Descriptions and Responsibilities In Agile

Agile can be loosely described as a set of predefined principles or values that are used to manage software development. One of the most used Agile frameworks is called Scrum and is best used for small teams of developers who split their work into cycles, also referred to as sprints, with the aim of developing working software at the end of every cycle. Such a framework needs a person to manage the delicate timelines that are often associated with this kind of software development model. This person is called an Agile coach or a Scrum Master.   A Scrum Master is not your traditional project manager. In fact, Scrum Masters and project managers have distinct differences in their job descriptions. The role of a project manager is to manage project timelines, the scope of the project and the resources used to make sure that the project meets the requirements. We will now look into a little more detail, the job descriptions of a Scrum Master and why proper agile and Scrum training is important for business success!     Scrum Master Job Description and Responsibilities 1. Coaching the Team The Scrum Master is responsible for making sure that the members of the team are well trained into following the values of the Scrum framework and Agile practices. The Scrum Master also ensures that the team members are aware of their respective roles and how they will fulfill them while using the framework. Such is also important if new members join the team midway through the project. Team members also need to be coached on how to be accountable, productive and how to get the most out of being self-organized. The members also need to be coached on how to have a sense of ownership of projects and view them as something they want to do rather than something they are paid to do. It is not the team alone that needs coaching, event management and the company as a whole require coaching.   This is helpful especially when it comes to organizations that are adopting the Scrum framework for the first time.   2. Managing and Driving the Agile Process The Scrum Master is in charge of how the whole process is played out from the start all through to the end. A Scrum Master manages the scope and timeline of the entire project, which in turn guides them to set achievable goals. Therefore, what the team delivers at the end of every sprint has the required quality and supports the larger business goal. They are also in charge of making and implementing changes to the process if necessary. Throughout the lifespan of the project, the Scrum Master is required to monitor the schedule performance as well as the cost performance and make alterations where necessary. The Scrum Manager is also responsible for planning and setting up retrospective meetings and daily meetings. They should plan what can be delivered quickly so that they can prepare the team accordingly. If there is no project manager, it is up to the Scrum Master to document project requirements and proposals, status reports, handle presentations and ensure that they get to the clients.   3. Protect the Team from External Interference Communication is a crucial aspect during the course of a project. However, when the right channels are not used, it becomes dangerous for the whole project. For instance, there have been cases of disgruntled product owners or operational staffs, event management in some cases, going to an extent of approaching an individual team member with their concerns and new demands, and this affects the individual. The Scrum Manager has the mandate to ensure that they are the guardian of the team, speaking on behalf of the team and not allowing direct access to members in case of any concerns.   Managing the Team Working together is what makes any group project successful and that is one of the duties of a Scrum Master; to ensure that there is adequate cohesion amongst the members of the team. The Scrum Master should invest in creating an environment of openness, respect, and honesty so that the team members can feel comfortable with each other and with themselves. Such is important, since an individual would be more resourceful if they worked in conditions where they are not being intimidated, judged or discriminated in any way. In the event of a fallout between team members, a Scrum Master is responsible for identifying, resolving and eliminating the source of conflict. It is also in the power of the Scrum Master to appoint a project manager if it is deemed necessary. 4. Foster Proper Communication Poor communication is arguably one of the fastest ways to ruin a well-planned project, regardless of how good the developers may be. A Scrum Manager needs to be well equipped with excellent verbal and written communication skills to ensure that every piece of information gets to the team, related stakeholders and is delivered accurately and on time. This starts with the initial scope of the project, and it is even more important when it comes to relaying changes. All important changes of scope, project plan, change in timeline and so on should be communicated as soon as possible to ensure minimal interruption to the workflow. A Scrum Master should also ensure that there is a good communication flow within the development team internally, in particular, between the developers and the user experience or visual designers. They should also make sure that other relevant stakeholders know what's going on in the company. This encourages transparency and builds up trust across the whole organization. 5. Dealing with Impediments A Scrum Master should anticipate, identify, track and remove any impediments. Predicting impediments makes the Scrum Master alert to potential threats to the project and ensures that they can easily identify and eliminate them. They find ways to deal with the issues internally, and they can also get help from the larger company or other stakeholders, if it is beyond their power. As part of coaching, the team can be trained to identify impediments themselves or the Scrum Master can select members to remove the barriers once they come up. 6. Be a Leader A Scrum Master should be a leader to the team. They should be ready to come up with new solutions, and they should be open to receiving new ideas from team members and other stakeholders to make the deliverables meet the required standards. They should be able to work with the team and develop and empower the individuals, helping them achieve their full potential as developers and as individuals. They should also be servant leaders in that, it is not all about giving orders for them; they can also dive in and give a helping hand and work with the developers, which is the traditional meaning of leading by example!   Conclusion How do you choose a scrum manager? Above is just a summarized list of responsibilities of a scrum master. The responsibilities and duties may vary from one organization to another or from one project to another, but it does not take away the base importance of having a Scrum Master as part of the development team and the organization as a whole.
Rated 4.0/5 based on 20 customer reviews
Scrum Master Job Descriptions and Responsibilities...

Agile can be loosely described as a set of predefi... Read More

Scrum Master vs. Project Manager: Differences and Similarities

Organizations that are new to Agile and Scrum commit some deadly blunders. The most common and overlooked one is the lack of clarity of the roles of the Scrum Master and the Project Manager. This is more often seen in smaller Scrum teams, where these two discrete roles overlap.  There are of course similarities between Scrum Master and Project Manager roles. But that does not give way to ignoring the distinct differences between an Agile Project Manager and Scrum Master.  We have spaced out this article into various sections-    Scrum Master vs. Project Manager roles and responsibilities Scrum Master roles and responsibilities: Scrum Master is referred as a facilitator, who manages the teams that are implementing the Agile methodology. Scrum framework is the best framework for smaller teams of developers, who can break their work into a Sprint in order to get your project done at the end of every sprint.  The roles and responsibilities of the Scrum Master includes- Sprint planning  Scheduling the daily Scrum meeting Managing Scrum process responsibly Helping the Scrum teams to follow Scrum practices Removing barriers so the team can focus on their work Assisting with the Product Backlog Co-operating with Product Owner in designing Product Backlog items for the next Sprint Protecting the team from external distractions Recording and assisting to improve team dynamics   *Project Manager roles and responsibilities: Project manager’s role is to manage the projects and ensure that the project meets the requirements. The roles and responsibilities of the Project Manager are as follows- Defining project scope to the team Planning project target Preparing the work schedule for the team members Gathering requirements Defining the resource requirements for the project Preparing the budget for a project Assuring quality Mitigating the risks Monitoring the plans Getting user feedback Managing relationships with the client and the stakeholders Ending the project   Similarities between the Scrum Master and the Project Manager Project Manager and Scrum Master both are humans and they both make mistakes. But they both debug and learn from the mistakes. They both can communicate, receive feedback, mitigate the risks, and enable a great bonding within a team. Actually, neither the Project Manager nor the Scrum Master is the supreme authority. The Project Manager has to report to the client and the stakeholders, whereas the Scrum Master has to report to the Product Owner alongside the stakeholders and clients. Both Project Manager and the Scrum Master fail when they ignore the basic principles that are supposed to be adhered to. They fail when they not only neglect being professionals, but also when they are any less than skilled professionals. Sometimes, they may also fail when they disrespect the team members’ opinions. Differences between the Agile Project manager and Scrum Master While noting down the differences between the Project Manager and the Scrum Master, you will find out that the Project Manager plays the leadership role by leading a planning for the execution of the project. Scrum Master plays a support role for the team members, by working closely with the team and assuring that they are following Agile principles properly. Let’s look at the major differences between the PM and SM: Project Manager(PM) vs.Scrum Master(SM) Goals Has defined goals like- Completing the project on time, planned budget, and scope Makes sure that the team members are well trained to follow Agile practices appropriately. Also, SM coaches the Scrum teams and mentions the timeline to finish the project. Quality Assurance PM also knows the importance of quality, but doesn’t know how to achieve this. Usually, a consultant is hired to fix the errors. SM assures the quality and very well knows the importance of it. Team Size Project Managers like to make the things large. PM works with more people and a huge budget. In this way, they improve to Program Manager Scrum Master always tries to keep things smaller. They like to work in small teams irrespective of budget. Average Salary Rs.1,351,403 per year Rs 1,036,017 per year Job Description The job description of the Project Manager includes- Planning, creating budget and the related documents PM has to work with upper management to ensure a scope and direction of a project PM has to work with another department also, in case of emergency sometimes have to work themselves or instruct the team to finish a goal. The job description for Scrum Master includes- Resolves barriers and controls the Scrum processes. Making a team aware of Agile and Scrum to deliver successfully Facilitates the Scrum ceremonies Ensures that a project is running smoothly with the help of the tools Executes the Product Backlog as per the Product Owner prioritization Solves team conflicts with good communication skills Motivates the team Monitors the Scrum processes to increase efficiency   Scrum Master vs. Project Manager certification The Scrum Master and the Project Manager certifications are the two most popular certifications of the Agile and Waterfall methodologies.  Scrum.org report as of 30th April 2017 states that around 110,000+ people are  Scrum certified. Only 56% of the Project Management Specialists are holding a Project Manager Certificate, even in Big IT companies. This was revealed in a survey conducted by IBM.    Last words: Deciding between the Scrum Master and Project Manager certification is indeed a tough choice and entails a careful consideration of the prospects of each. Eventually, the role of a Scrum Master is proved as a ‘deciding factor’ of the successful projects. The Scrum Master and the Project Manager both have distinct roles. Both need particular skill-sets and a right person to make the work happen.       
Rated 4.0/5 based on 9 customer reviews
2673
Scrum Master vs. Project Manager: Differences and ...

Organizations that are new to Agile and Scrum comm... Read More