Moving Demotivators

A demotivator is like an unwanted load on a sinking ship. With it, the ship will sink. Without it, the ship will not sink but it will not help the ship to move forward. To move the ship forward, we need motivators.

So what is Moving Demotivators? Moving Demotivators is a retrospective that you can run with your Scrum team to identify what are the current demotivators that are having a negative impact on the team. With the results from this retrospective, the organization can work on removing these demotivators and then move on to identify what will motivate the team.

Moving Demotivators is inspired by Management 3.0 Practice: Moving Motivators and based on Herzberg’s Motivators and Hygiene Factors. For more details on Moving Motivators, you can follow this link https://management30.com/practice/moving-motivators/.

What is Herzberg’s Motivators and Hygiene Factors

According to Herzberg’s Motivators and Hygiene Factors, job satisfaction and job dissatisfaction are not opposites.

  • The opposite of Satisfaction is No Satisfaction.
  • The opposite of Dissatisfaction is No Dissatisfaction

Remedying the causes of dissatisfaction will not create satisfaction. Nor will adding the factors of satisfaction eliminate dissatisfaction. If you have a hostile work environment, giving someone a promotion will not make him or her satisfied. If you create a healthy work environment but do not provide members of your team with any of the satisfaction factors, the work they’re doing will still not be satisfying.

Picture1

 


How to use Moving Demotivators to identify the demotivators

Step One (5 mins)

Which demotivators are important to you? Place the cards in the order from Left (least demotivating) to Right (most demotivating.)

List of demotivators

  • Boredom
  • Poor communication
  • Job insecurity
  • Micromanagement
  • Disrespectful treatment
  • Lack of material and tool availability
  • Lack of recognition
  • Ineffective utilization of skills
  • Productivity Salary Disparity
  • No follow through on commitments

Step Two (5 mins)

How is the current demotivation level of each demotivator for you? Everybody on his own: Think about the question and assign a demotivation level and frequency to each motivator.

Demotivation Level

  1. Completely not demotivated
  2. Moderately demotivated
  3. Demotivated
  4. Demotivated over average
  5. Very highly demotivated

Frequency

  1. Never
  2. Rarely
  3. Occasionally
  4. Frequently
  5. Very Frequently

Step Three (30 mins depending on group size)

Then one by one everybody talks about the order and demotivation levels he/she chose. The other team-mates standing around the one who’s talking and ask questions, if clarifications are required. If there are more than 7 persons in the team, split the team in two groups.


Step Four (20 mins)

Reflection phase with the whole group.

  • What did you observe?
  • What was interesting?
  • What was surprising?

Evaluation (after the retrospective)

Based on the evaluation sheet the scrum master prepares an evaluation diagram and prints it. This can be used to work on demotivators that are important for the team but have a low level or the make shifts in the demotivation levels after changes visible.

Sample ChartsScreenshot_2.png


Continue reading

Sprint Length

A sprint, according to the Scrum guide, should not be more than one calendar month.

To best determine the sprint length, the following need to be taken into consideration:

  • The risk of being disconnected from the stakeholder
  • The level of uncertainty over the technology to be used
  • Focus level of the scrum team

Typically, Scrum team goes for 1 week, 2 weeks, 3 weeks or 4 weeks sprint length so that the start and end of the sprint are always on the same day of the week. It’s important to keep the sprint length consistent as a constant duration leads to a better rhythm.

LPT: For a Scrum team transitioning from Waterfall to Scrum, a 4 weeks sprint length has the additional danger of being abused if the team has not fully embrace the Scrum Framework. The team could potentially plan their sprint in the following manner

  • First Week – Analysis
  • Second Week – Design
  • Third Week – Coding
  • Fourth Week – Testing

TIL: Daily Scrum is not Daily Standup

A daily scrum according to the scrum guide is a 15 minutes time-boxed event for the development team. However, it does not state that it has to be a standup event. A daily standup is actually a practice from extreme programming telling the participants to do the event standing up.

That being said, it is a good tactic to do the daily scrum standing up as it helps to keep the meeting short and time-boxed to 15 minutes

No fish, prawn also good? Improvised Scaled Scrum Framework

A scaled scrum implementation for multiple teams with separate backlogs working on the same product.

Introduction of the following new events in this scaled scrum implementation

  • Overall Sprint Planning
    • Each team involved in this scaled scrum implementation will share with other teams on what will be considered for the upcoming sprint. Any dependency across teams will be raised and taken into consideration during the individual team sprint planning that happens immediately after this overall sprint planning. The purpose of this new event is for synchronization and identification of any cross-team dependency
    • Attendees: POs, SMs and at least 1 representative from each team
  • Overall Sprint Review
    • Each team will share the outcome of the sprint with a demo and gather feedback from the stakeholders. With this new event, there will no longer be any individual team sprint review.
    • Attendees: The whole world
  • Overall Sprint Retrospective
    • To be held after each team has conducted their own team retrospective. This new event is for the purpose of sharing any feedback regarding cross-teams coordination and the scaled scrum implementation
    • Attendees: POs, SMs and at least 1 representative from each team
  • Overall Daily Scrum
    • To be held daily after each team daily scrum. For the purpose of synchronization of daily work across teams and raising of cross-team dependency
    • Attendees: At least 1 representative from each team

 

 

Defect Retrospective (Experiment)

A separate event from the regular retrospective targeting on defects. The idea of this retrospective is to review the defects identified and fixed by the development team, allowing the team to identify ways to prevent similar defects from re-occurring and improving the quality of the product being developed.

  • Frequency: Once per week (Friday)
  • Duration: 1 hour

To ensure that this event run smoothly, the backlog containing the defects need to have the following information filled up by the development team

  1. Root Cause Category
  2. Detailed Root Cause Analysis
  3. Solution

Category for Root Cause has been set up as followed:

  • Back End – This defect is due to back end
  • Configuration – The defect was caused by incorrect static data setup
  • Environment – The defect has occurred due to a code base lining issue, server level configuration, etc
  • Existing bug – This is an existing defect in the system which is probably also present on the live environment
  • Impact Analysis – Thorough impact analysis has not been done and implicit requirements have been missed out
  • Injected defect – This defect has been injected due to a different defect fix.
  • Requirement – The requirement has not been clearly understood, the team’s assumption does not match with the business user’s expectations.
  • Testing Error – The test case was incorrect effectively resulting in an invalid defect getting logged
  • Wrong Implementation – The defect was caused due to an incorrect coding implementation
  • Others – Please reach out to Scrum Master to create the necessary category

Continue reading

My Daily Scrum setup with Remote Team

“Face to face conversation is the best form of communication (co-location)”

In the present landscape, having a co-located team might not always be possible. When it is not possible to have co-location, then necessary investment must be made in order to bring the team closer together virtually.

For a remote team, a daily scrum should continue to be a standup event instead of sitting comfortably at the desk and having the daily scrum. A video conference will be highly recommended as it will allow the team to see non-verbal communication on top of the expected verbal communication.

Below are the devices that I used for Daily Scrum with the remote team.

Devices used

Genius

Genius 120-degree Ultra Wide Angle Full HD Conference Webcam(WideCam F100)

This webcam was chosen because of the 120 degree capture angle. Normal laptop webcam capturing angle was too narrow as the team members are standing a distant away from the laptop.

E103

E103 Microphone

Using a headphone jack connection to the laptop, it provides better audio and mic functions then using the laptop speaker and mic. In addition, it avoid the situation where the team member has to move close to the laptop to speak to the laptop mic. Was using a bluetooth connection previously on this E103 microphone, but it was not providing voice clarity as compared to using a headphone jack connection and was subjected to intermittent connection lost.

Trello as a task board for Scrum Team – Part 2

And so, the Scrum team started using Trello as their information radiator. One major point of discontent was that it was difficult to see the tasks associated with the story.

One major point of discontent was that it was difficult to see the tasks associated with the story. Tasks were captured as checklist items on the story card, but it is not easily viewable on the task board. One need to open up the card just to see the tasks. While this can be slightly mitigated through the use of “Next Step for Trello” extension, we still faced with the challenge of identifying which team member is working on which task and the task status.

Till Trello starts to introduce horizontal swimlanes, it will not be a good option for a team needing to clearly see the story and tasks association and status.

My first attempt in using Trello as a taskboard for Scrum Team

Trello is free to use and is easy to setup. On top of its existing functionalities, I had included a few extension that I found useful for the taskboard.

  1. Scrum for Trello (Available for Chrome, Safari and Mozilla) – https://chrome.google.com/webstore/detail/scrum-for-trello/jdbcdblgjdpmfninkoogcfpnkjmndgje
  2. Card Color Titles for Trello (Available for Chrome, Safari and Mozilla)  – https://chrome.google.com/webstore/detail/card-color-titles-for-tre/hpmobkglehhleflhaefmfajhbdnjmgim
  3. Ultimello (Chrome only) – https://chrome.google.com/webstore/detail/ultimello-the-features-pa/hahbfgjfimnmogoinnenhheepfcphnmm
  4. Next Step for Trello (Chrome only)  – https://chrome.google.com/webstore/detail/next-step-for-trello/iajhmklhilkjgabejjemfbhmclgnmamf?hl=en

The above extensions are all available on Chrome, some on Safari and Mozilla. So we might have to use Chrome browser in order to enjoy the extensions.

 

Scrum for Trello will allows us to capture and display the estimated story points for each card and also the total story points on the list.

Scrum for Trello

Card Color Titles for Trello will allows us to see the label text on the card when it’s on the list.

Card Color Titles for Trello

Ultimello has a tons load of features. For now we are using it to help show the number of cards on the list.

Ultimello

Next Step for Trello allows us to view the checklist in the card when it is on the list.

Next Step for Trello

Starting a new Scrum Team

Team

  1. Have a team name. An identity for the team goes a long way.
  2. Identify all Scrum team members, role, skillsets, contact information and working hours. Especially useful for distributed team
  3. Conference number and participant code (usually for distributed team)
  4. Taskboard URL (if not using a physical board)
  5. Source code URL and access
  6. Working Agreements (at least 3 not more than 7)
  7. Team Values (at least 3 not more than 7)

Product Owner

  1. Availability of Product owner. Identify slot of time where PO is or not available.
  2. Will the PO attend the daily standup meeting?
  3. What should the team do if the PO is not available for sprint planning, review, question or extend period of time (vacation, sick leave etc)

Schedule

  1. Sprint length
  2. Sprint start date
  3. Sprint Planning (day/time/location)
  4. Daily standup meeting (time/location)
  5. Sprint review (day/time/location)
  6. List of important stakeholder to be invited for sprint review
  7. Sprint retrospective (day/time/location)
  8. Backlog grooming/refinement (day/time/location)
  9. Identify important milestones for the project

Definition

  1. Definition of Done
  2. Definition of Ready
  3. Story point baseline
  4. Estimation scale (Fibonacci or power of 2 or etc)

The above activities can be considered as part of sprint zero. It should not be taking more than 2 days if the relevant parties are available. Once the above activities are completed, it is time for the Scrum Master and the Product Owner to prepare the prioritized backlog and have a product grooming session with the team before the actual sprint begin.


Note:

  • Sprint zero should also cover the technical setup of the necessary tools and environment
  • You might also want to include a half day Scrum training for the team if the team is new to Scrum

 

Retrospective – Three Little Pigs

three-little-pig-retrospective

A retrospective that uses the famous 3 little pigs story. This retrospective is useful for reviewing processes and behaviors.

  • The STRAW house denotes processes and behaviors that are weak and should be dropped or changed.
  • The STICK house denotes processes and behaviors that seem to be working in the short term but will probably not last the weather.
  • The BRICK house denotes processes and behaviors that are strong and should encourage the team to continue to practice these processes.

This retrospective was used on a new team after 4 sprints (2 weeks each). This new team comprised of members from 2 different scrum team previously. At the start of the formation of this new team, the team agreed on a new set of processes.