This Festive Season, enjoy 10% discount on all courses Use Coupon NY10 Click to Copy

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 3633
  • by Steve Ash
  • 05th Nov, 2018
  • Last updated on 11th Jan, 2019
  • 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 Is Agile Design Thinking Helping In Business Innovation?

Design thinking is no longer a practice monopolized by designers. It has pushed itself beyond the “design” confines and found its place in multiple avenues. The new-age connotation of design thinking is significantly different from the traditional one. Today, it is seen as a problem-solving methodology in businesses. It is essentially a solution-oriented approach and entails five steps-1) Empathize- Understand your audience, customers and target market2) Define- Specify your requirements, understandings, and problems3) Ideate- Create new ideas to form innovative solutions4) Prototype- Solutions are created by looking at a prototype5) Test- Test the solutions once they are finishedThese phases should not be executed in series. They should be implemented organically to get the target solution at the end regardless of the sequence.  Design thinking is assumed as the most effective way to understand a customer’s requirements. It involves thinking- ‘why they do’, ‘what they do’, ‘how they do’ and finding out some novel ideas, which may turn out as a solution the customers will love.Why Is The Agile World Talking About Design Thinking?How design thinking met Agile is a matter of interest and the topic of today’s discussion. While the two appear mutually exclusive and uncorrelated, an unbelievable intersection has recently come to the fore.                                                                                         Fig. Design Thinking and Agile development processBefore proceeding further it is crucial to know about the term ‘Innovation’. Generally, we hear this term everywhere and we know that innovation is all about providing ideas out of the box, that will lead to achieving business targets. Let us move on to the actual definition of it.Innovation is defined as a commencement of something new and unique. Actually, it is an act of innovating that leads to significant discoveries, processes, and devices.                                                                                                            Creativity + Work = InnovationTherefore, be an innovator to harness your creative ability. Here are some points that will help you know the importance of Innovation.Innovation in businesses is important as it provides not only an edge to penetrate the market at high speed but also better ways to develop a market to generate bigger opportunities, especially in abroad countries.It also results in developing new things if an innovator is given an enterprising and confident attitude for taking risks and accomplishing a task.Introducing an innovative culture to the businesses will help the latter grow easily, in spite of the creative process being unique. Usually, tried-and-tested methods are reliable, but trying out new things may be a worthwhile experiment.Is Design Thinking A New Agile?How does the design thinking concept complete Agile? Design thinking practices consider Agile principles by giving the customer the highest priority. It complements Agile in following ways-Customer interactions are done before getting an idea of the target solution. There are some tactics that can be used to identify your customers, such as carrying out interaction with the group, single person, or experts from the target market. This will help you better empathize and solve a problem. It is recommended, in this context, to build a product for your market, than searching a market for the product.During interaction, add customer engagement, observation and some useful techniques which will help you to immerse yourself in the client’s requirements. Ensure what problems the clients are facing and what you can do to solve them.Once you discover the problem and call it out, you are almost halfway through. Next, you sit down and ideate. This is nothing but envisioning the problem with its pros and cons and finding ways to solve it. The best way to do it is to think of a “prototype”, which essentially is your tentative solution. The basic idea in design thinking is to outline the prototype as a high-level concept, in a form closest to the real solution. This is where some of the popular tools like Axure and Invision come into the picture. They seamlessly create a high-quality model of the final product, without having to run through the complete software development life cycle.It is important to provide a solution as per the customer’s requirements because for the customer there exists only one criterion: Does the solution solve their query? If it is, they will pay for it. If it is not, they will search for the better fit elsewhere. Therefore, developing a product which fits the market is important.Another key technique that Design Thinking can promote is to have a multitasking, robust team that can view a query from various perspectives. This is similar to the Agile principles, in which autonomous and self-empowered Agile teams develop a solution themselves.How can the right environment be created for an effective combination?You may feel awkward while combining Design Thinking with Agile for the first time. Design thinking team, like Agile, needs to accomplish the task with the help of the entire team. There is enough room for collaboration of Design Thinking practices and Agile principles. An ideal environment needed for Design Thinking includes developers, UI designers, and testers in the team. To ensure success in combining Agile with Design thinking, one should keep the following things in mind:The combination of Design thinking and Agile will be successful when the team involves people with different skill-sets, backgrounds, perspectives and creative ideas that they can share with each other. Also, one can have the freedom to define ‘how’ while understanding the story behind the scene.Each team should be allowed to take risks and should be given exposure to the process of the other teams’ work. The team discussions will bring up new and innovative methods of addressing thereby resolving the problem which may arise.The team discussion will help you to micromanage your team. It is recommended as the best way to let the team manage system works more effectively.Last Thoughts-Scrum is derived from the Agile framework. Agile works in an iterative manner to deliver valued solutions in fixed time to the customers. Scrum plays an important role while transferring Agile framework to the Design Thinking process. In this regard also, Agile and Scrum are forming the bedrock of the organizations. Consequently, the demand for Scrum in successfully implementing Agile Design Thinking is rising as it is an effective, smart and perfect way to gain more productivity.  The world domination of Agile due to the incorporation Design Thinking is clearly happening and you may have archived various courses as well. But despite all your struggles, there is that glass-ceiling that is limiting your potential as a Scrum Master. This can mean only two things-# You are yet to practise the design thinking principles religiously# You are just a certification away from the best Agile practicesThe need of the hour is to introspect and find the shortfalls in your Agile practices. The final step, and invariably the way forward, is to opt for CSM certification courses.See for yourself what it means to make Agile work for you in the Design Thinking way!
Rated 3.5/5 based on 1 customer reviews
How Is Agile Design Thinking Helping In Business ...

Design thinking is no longer a practice monopolize... Read More

How To Pass Leading SAFe® 4 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 exam preparation.Firstly, the 2-day Leading SAFe® 4.6 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 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 4.0/5 based on 1 customer reviews
26682
How To Pass Leading SAFe® 4 Exam ?

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

Scrum Master and Product Owner: Understanding the Differences

According to the State of Scrum report 2017-2018 based on the data collection initiated in 2013. This survey represents the real world implementations of Scrum.     Agile methodology imparts the easy and convenient path to work. Scrum is one of the renowned Agile methodologies. The agile methodology consists of 4 main roles, viz. Product Owner, Scrum Master, Scrum team and Stakeholder. Each role has its share of responsibilities. These roles are all about commitment.     Scrum Master and the Product Owner are the two vital roles in the Scrum software development methodology. Since they both are working on different areas of the project, they are indispensable for the project. Scrum Master is a mediator between the Product Owner (PO) and the Development Team.     Let’s see how a Scrum Master is different from a Product Owner. Difference between the Product Owner and Scrum Master-   Though the Product Owner and the Scrum master vary in their roles, they complement each other. Scrum master should support the Product Owner in every step possible. There should be an amicable relationship between the Product Owner and the Scrum master. Disputes may happen between them if the roles are not clarified. Let us have a look at the differences in roles between the Product Owner and the Scrum Master. The Scrum Master concentrates on the project success, by assisting the product owner and the team is using the right process for creating a successful target and establishing the Agile principles.     Skills of the Scrum Master (SM): Removes the impediments and keep the team on track The Scrum Master helps the team to strictly adhere to the Scrum practices and helps them in reaching the target. The Scrum Master find out the distractions that are hindering the team from delivering the product quality. The distractions include unwanted meetings, complexity in the procedure, work environment etc. Encourages Collaboration The Scrum Master notices the daily activities of the team members. Also, the SM share his/her experiences with the team members via meetings, conferences, and seminars. The Scrum Master encourages the collaboration through the stand-up meetings, the release of planning sessions, iteration planning, and demo sessions. Good listening and Communication power The Scrum Master should have good communication skills in order to discuss the ideas and plan with the team. Good communication helps to deliver messages to customers, teams, and target audiences. Also, listening to the team members will help them share their ideas with the Scrum Master. So, Scrum Master should be a good listener also. Mentors the team as a Coach A successful Scrum Master understands the importance of the team working in collaboration. He/She mentors the team members as a Coach to implement the Scrum practices.    Flexibility for adopting the change The Scrum Master should be flexible for adopting any change. While implementing the Agile methodology, the team members may face the problems. So, the Scrum Master should be able to help the team members to adopt the changes. The Scrum Master facilitates the daily Scrum meetings for the team members to discuss their issues that are hindering the project growth.     Partnership with the Product Owner Scrum consists of three roles – Product Owner, Scrum Team and Scrum Master. The Scrum Master acts as a mediator between the development team and the Product Owner. The two roles- Product Owner and Scrum Master are valuable for the team, as they build a perfect relation with the team and thereby delivering the best results. Servant Leadership quality The Scrum Master provides collaboration. Scrum Master is also known as a Servant Leader.  He/She guides the team members on how to follow the Scrum approach to motivate the team members to deliver the best. Responsibilities of the Scrum Master:   Scrum Master facilitates team for better vision and always tries to improve the efficiency of the teams. Scrum Master manages Scrum processes coordinating with the Scrum team in the Agile methodology. Scrum Master removes impediments for the Scrum team. Scrum Master arranges daily quick stand-up meetings to ensure quick inspection and proper use of adaptation processes. Scrum Master helps Product Owner to shape the product backlog and make it ready for the next sprint. Conducting retrospective meetings. Scrum Master organizes and facilitates the sprint planning meeting. Most importantly, the Scrum Master removes the impediments that hindering the project success. Scrum Master keeps the team away from the distractions. The Product Owner’s responsibility is to focus on product success, to build a product which works better for the users and the customers and to create a product which meets business requirements. The Product Owner can interact with the users and customers, Stakeholders, the Development team and the Scrum Master.   Skills of the Product Owner (PO): Product Owner should have an idea about the business value of the product and the customers’ demands. Certified Scrum Product Owner Certification (CSPO) will be beneficial for the sales team. The development team consults the Product Owner, so he should always be available for them to implement the features correctly. Product Owner should understand the program from the end-user point of view. Marketing is discussed on the sales level in most of the Organizations. So it is the Product Owner’s duty to guide the marketing persons to achieve the goals successfully. Product Owner is responsible for the product and the ways to flourish a business. Product Owner has to focus on the proper production and ROI as well. Product Owner should be able to solve the problems, completing trade-off analysis and making decisions about business deliverables. After Certified Scrum Product Owner course, Product Owner can work with the project managers and the technical leads to prioritize the scope for product development. Sometimes Product Owner and the Customers are same, sometimes Customers are thousands or millions of people. Some other skills are as follows: 1.Communication Skills Communication is the key factor for any team member to be successful.  The team should be open to working together to achieve a common project target. It is very important that everyone on the team should communicate effectively. Most probably, the Product Owner should possess good communication skills. As the Product Owner needs to work with the customers’ to understand their needs and conveying that to the development team to bring it to reality. If they could not able to communicate effectively, it may affect the organization value. 2.Commitment The Product Owner should be committed to the project target, product vision, team, and the business. They have to attend all the meetings and work with all the team members. So, it is very important for them to collaborate with everyone. Furthermore, the Product Owner must be accountable for the process and be committed to the success of the project 3. Vision The Product Owner should be able to clearly communicate the product vision between the backlog items and the large project goals. They check whether the product vision is aligned with the company’s vision and needs. 4.Curious about what they work Concerning that “bad product owner” is so often the excuse for bad product. I coach towards product leadership and team ownership. My worst case is product owner telling the team exactly what to build, and team not taking ownership of the outcome. That’s what “bad” looks like. https://t.co/Um4rgvJ7yk — Jeff Patton (@jeffpatton) April 4, 2018 The Product Owner (PO) need to be curious always to ask ‘Why’ from the client (about his/her requirements) and ‘How(to the development team). But before asking the questions to the team, they should understand the rules and able to create a clear vision of the final product. Responsibilities of the Product Owner: Product Owner has to attend the daily sprint planning meetings. Product Owner prioritizes the product features, so the development team can clearly understand them. Product Owner decides the deadlines for the project. Product Owner determines the release date and contents. Product Owner manages and creates the product backlog for implementation, which is nothing but the prioritized backlog of user stories. Product Owner defines user stories to the development team. Spending some time to prioritize the user stories with a few team members. The Product Owner and Scrum Master Relation     This question is highly debatable in an Agile world. Many say that there needs to be a clear contrast between these the Scrum Master and Product Owner and therefore needs two individuals to manage these two roles. The Product Owner should have an overall vision of the client’s requirements. Due to this reason, the Scrum Master needs the Product Owner. Whereas the project team requires the Scrum Master to work maintaining the velocity and capacity of the team. Choosing the best The Product Owner has to get involved in grabbing the project details. But, along with that, the Product Owners expect an experienced Scrum Master should work and guide his/her team members to work efficiently yielding good results. The Scrum Master and the Product Owner have mostly overlapping roles and responsibilities and skills as well. Every one of them requires an alternate level of communication and mindset.  
Rated 4.0/5 based on 1 customer reviews
6369
Scrum Master and Product Owner: Understanding the ...

According to the State of Scrum report 2017-2018 b... Read More