Search

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. 
How Not to be Agile – Daily Stand-Up/Scrum
Steve
Rated 4.5/5 based on 11 customer reviews

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
3582
How Not to be Agile – Daily Stand-Up/Scrum

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

Everything you need to know about PSM certification

1. Introduction to Professional Scrum MasterWho is Professional Scrum Master (PSM)?We partially give some elements in a previous article on our blog: “ How To Choose A Scrum Master? “. On top of that, it is important to       highlight that the Professional Scrum Master wear different hats according to the context: s/he is a coach, facilitator, enabler, problem- solver, proxy. His/Her main characteristic is to embody Servant Leadership. And basically, as the first promoter of Agile in the   organization, s/he truly has the Agile mindset and is more than willing to share it.Role and Responsibilities of PSM in the teamBecause the position of Scrum Master depends so much on the context, you will find multiple potential roles and responsibilities description by searching on the Internet. However, here are the basics:Coaching the organization, especially the Scrum Team, to get an Agile mindsetIncreasing the quality of deliverables and reducing time to deliverHelping the Dev Team to become self-organized and self-empoweredBuilding culture of trust, transparency, feedback and “fast failure to learn fast”\Advocating in favor of the more appropriated framework to make the Dev Team performant – it can be something else than Scrum!Ensuring that this framework is properly implemented to fit with the Scrum Team needsRemoving any impediment and blocker that prevent the Scrum Team to perform Requirements to become a PSMOfficially, there is no specific requirement: everyone is a potential candidate to become a Professional Scrum Master (PSM).Why become a PSM and what do I need to become a PSM?Do you live and breathe Agile? Ok, that sounds too much.Nevertheless, have in mind that learning theory and training to open assessments is one sufficient thing to get certified but acting as a good Scrum Master requires a true behavior and belief in Agile philosophy coupled with large experience, ideally in organizations that have succeeded in their transformation.Like other jobs at “vocation”, you feel a true desire to become Scrum Master when working or at least meeting with one of them. When you meet a great Scrum Master, at some point you could become aware that you do want to do the same job: because you help people working better, feeling better at work, you participate to a radical transformation in the workplace for a better organization.2. What’s the importance of a PSM certificate?Getting a PSM certificate demonstrates the capacity to know, understand and apply Scrum in real-world situations.3. PSM Certification TrainingHow to become a PSM?Although it is highly recommended, taking a training is optional. However, taking the official exam is mandatory to get certified. Scrum.org is the official provider:https://www.scrum.org/professional-scrum-master-i-certificationSyllabus of Professional Scrum MasterA core of knowledge about Scrum remains the Scrum Guide from Ken Schwaber and Jeff Sutherland.Spend time and train seriously on the Scrum Open Assessment: this is the most realistic assessment you can train on!Next very useful resources are available with the Scrum Master Learning Path: this is a set of Professional Scrum Competencies which each contain a number of focus areas.Scrum.org recommends strongly these books:Scrum: A Pocket Guide by Gunther VerheyenSoftware in 30 days by Ken SchwaberScrum.org offers also:A very complete glossaryforums populated by threads of quality, written by contributors with solid experience in ScrumA popular blog regularly updated with highly valuable posts, again made by writers shortlisted by Scrum.orgOther Open Assessments might be relevant to gain additional perspective on the other roles of a Scrum Team: check the Scrum Developer Open Assessment and the Product Owner Open Assessment.What is the eligibility to become a PSM trainer?Eligibility to become a PSM trainer requires three conditions. First, candidates must have at least four years of intense experience as Scrum Master in software development. Second, candidates must have conducted real-world training and have delivered coaching using Scrum. On top of that, candidates passed their PSM 1 assessment with at least a 95% score.After PSM training within how many days do I need to take the certification?After PSM training, there is no minimum duration to take the certification. As soon as candidates feel they are ready, they can schedule an online assessment.4. Exam and Certification Information Who provides the certification?Scrum.Org coursesA list of Scrum.org official sessions is available online. As stated on their website:Professional Scrum Master™ (PSM) is a 2-day course that covers the principles and (empirical) process theory underpinning the Scrum framework and the role of the Scrum Master in it. This course is a combination of instruction and team-based exercises and teaches what is at the heart of the Scrum and Agile movement. The course also includes a free attempt at the globally recognized Professional Scrum Master I certification exam (PSM I).It is also important to know that taking a Scrum.org official training offers candidates a free attempt at the assessment.What is the process for applying for the certification?As passing the certification does not require to attend to the official course, candidates can directly apply on the Scrum.org website. They will receive a personal password (with no expiration date) and then they can connect to a specific page and take the exam.Cost of the Professional Scrum Master certificationThe cost is $150 per attempt. If you attend a Scrum.org training class, fees include a free attempt.The structure of the examThe exam is exclusively online. It consists of 80 Multiple Choice, Multiple Answer and True/False questions. 60 minutes maximum are allowed to perform the full exam, and only English language is available.Topics covered in the PSM examScrum Framework: this is foundational knowledge for every Scrum Team member. It covers Scrum theory as described in the Scrum Guide.Scrum Theory and Principles: this topic is more about understanding Scrum theory: empirical process, principles, and values of Scrum.Cross-Functional, Self-Organizing Teams. Questions here cover how Scrum Teams are different from traditional development teams:cross-functional, self-empowered and self-organizing people promote flexibility, creativity, and productivity.Coaching and Facilitation. Questions here are about how mindset and behavior of Scrum Master are different from traditional Project Manager: by acting as a Servant Leader, the Scrum Master facilitates and coaches full organizations in understanding and using Scrum.Sample questions of PSM exam Here are three potential questions at the PSM exam:Question 1: When many Development Teams are working on a single product, what best describes the definition of “done”?Each Development Team defines and uses its own. The differences are discussed and reconciled during a hardening Sprint.Each Development Team uses its own but must make their definition clear to all other Teams so the differences are known.All development Teams must have a definition of “done” that makes their combined work potentially releasable.It dependsCorrect answer : 3Question 2:The three pillars of empirical process control are:    1. Inspection, Transparency, Adaptation    2. Transparency, Eliminating Waste, Kaizen    3. Planning, Inspection, Adaptation    4. Respect For People, Kaizen, Eliminating Waste    5. Planning, Demonstration, RetrospectiveCorrect answer: 1Question 3:The maximum length of the Sprint Review (its time-box) is:4 hours for a monthly Sprint. For shorter Sprints, it is usually shorter.As long as needed.2 hours1 day.4 hours and long as needed.Correct answer: 1Tips to pass PSMThe best way to be well prepared for the PSM official exam is to work on the Scrum Open Assessment.You can consider that you are ready once you get 100% at every attempt.Salary of the Professional Scrum MasterSalaries of the PSM can vary a lot according to level of experience, industry, company size and location. Here is a table with most common figures:CSM vs PSM exam:"Differences to note" 5. Is the PSM I certification worth investing?The first goal at Scrum.org is to make candidates understanding how to get valuable software thanks to a high level of maturity in Agile using Scrum. In order to achieve that, Scrum.org deliver assessments to examine, improve and certify candidates’ knowledge of Scrum. On top of that, the Scrum Guide and the Nexus Guide serve as the main background for all Scrum.org assessments. Individuals that are successful at the PSM 1 certification demonstrate a fundamental level of Scrum mastery: they understand Scrum as described in the Scrum Guide and the concepts of applying Scrum. The PSM 1 certification is considered significantly more valuable than other options for Scrum.6. What next after PSM?People who follow Scrum.org courses can claim Project Management Institute (PMI) Professional Development Units credit: 14 PDUs after attending a two-day Professional Scrum Master (PSM). Keep in mind that PMI PDUs are earned for course attendance and not for passing a Scrum.org assessment.7. How much should I pay to renew PSM certification?There is no need to renew PSM certification: Scrum.org certificates are lifelong and do not require any additional payments or renewals.Career benefits of PSM certifiedConsequently, becoming now a certified and experienced professional in Agile expertise seems to be an interesting option to stay at least “employable” and marketable. Still being realistic, professionals in Agile will be directly requested either to perform the Agile transformation in many big (old) organizations or to build the Agile culture from scratch in new companies and startups. Attractive and valuable challenges are in perspective.
Rated 4.0/5 based on 29 customer reviews
3269
Everything you need to know about PSM certificatio...

1. Introduction to Professional Scrum MasterWho is... Read More

Scrum vs Kanban: Deciding The New Agile Benchmark

Today in the rapidly changing market, software development is changing its list of requirement every now and then. As we all know, Agile is one form of software development methodology which mainly focuses on the continuous delivery of project with client satisfaction. Agile always accepts the change and works on complete specifications to turn the project into a deliverable product.In the recent times, Kanban software development methodology is in the limelight for its ability to enable DevOps. Many of the organizations are moving from Scrum to Kanban for better results. So the question arises, which Agile methodology works better?And  Scrum vs Kanban becomes the essential question today. The key differences between Kanban and Scrum depend on the rules for using the Scrum methodology and the Kanban workflow.When the organization implements any methodology which is not flexible and useful, this can make the organization inefficient. This leads to the introduction of an Agile methodology in the organization. So, the first step while implementing the Agile methodology in the organization is to decide which Agile framework will be the best for you and your team.Suppose, you have chosen a Scrum framework and Kanban workflow, then what is the difference between Scrum and Kanban? Is Kanban Agile? What is Scrum vs Agile? And so on.GOLDEN RULESBoth Scrum and Kanban have a list of mandated and optional rules for their implementation. According to the Agile advice list for implementing Scrum, there are around 23 mandatory and 12 optional rules. Here are the few examples:Teams are functioning in a  cross-functional mannerDuring sprints, Interruptions are strictly avoidedWork is always time boxedScrum meetings are held on a daily basisTo measure the progress a burndown chart is usedFirstly, the problem arises when organizations follow “Scrum-But”- which is basically ignoring some specific set of rules for internal reasons. The next issue arises with timeboxing, which forms the core of Scrum. It allows the developer to define milestones for the Stakeholders to evaluate and guide their project.Now, in the case of Kanban, the rules are comparatively less restrictive. The principal rules are-Limiting the work in progressTo Visualize the workflowKanban is a flexible and an open methodology that can add rules as needed, borrowed from Scrum depending upon the requirement. In Kanban, the focus is mainly on the flow and not on the timebox. This feature makes Kanban a very appealing choice to use with DevOps.WORKFLOW METHODOLOGYFor Scrum:If we take the case of Scrum, every feature is decided before and it is ensured that it will be completed by the next sprint. After that, the Sprint is locked and work is finished over a couple of weeks, that is, usual sprint duration. The locking of the sprint is done to make sure that the team is getting enough time to make last minute changes depending on the requirement. There is a feedback session for reviewing the work accomplished. This helps to ensure that the delivered amount of work is approved by the stakeholders and is enough for directing the project as per business requirement.Implementing Scrum is not as easy as learning its principles. It requires to change the team members’ habits. The team members have to raise the quality of coding, take up more responsibilities, increase a speed and many more factors need to change. Scrum allows team commitment as the team commits to the Sprint goals, they always stay motivated to get better and fast results as per the user requirements.  For Kanban:In the case of Kanban, the priority is to focus on the workflow and not on the time. The limitation is only regarding the size of the queues. The main aim behind implementing Kanban is the productivity and efficiency of the product. This allows them to deliver superior quality work items. In addition to this, concentrating on the workflow will keep things moving. In Kanban, there is an extended feature known as stakeholder participation.In Kanban board, it is mandatory to define a “Work-In-Progress-Limit (WIP Limit)”. This helps to know the status of the work items to be delivered. If a status reaches the fixed WIP-limit, no new task is allowed at that state. This board helps to resolve the bottlenecks, as it makes the progress visible for further improvements. So, these WIP Limits acts as a change agent in Kanban.The Workflow of the KanbanComparison of Scrum and KanbanScrum vs Kanban: Deciding between the duosIf your team is responsible for enhancing the feature development feedback of the Stakeholder, then go for Scrum. But, if your team is in charge of maintenance and requires to be more reactive, you have to consider Kanban. Eventually, the need for every team is different and depending upon the requirements, methodologies need to be decided for the achievement of the goals.
Rated 4.0/5 based on 35 customer reviews
1922
Scrum vs Kanban: Deciding The New Agile Benchmark

Today in the rapidly changing market, software dev... Read More