I have been Agile for about 7 years. I am SCRUM Master, PMP holder but have spent most of my career as a Software Developer and Architect. I have been on several Agile SCRUM teams throughout many organizations. Throughout the years, I have had the opportunity to observe how companies implement Agile SCRUM. In Part one of this blog series, I wanted to talk about what I believe are some of the critical mistakes companies continue to make when implementing Agile SCRUM.

Too Much Ceremony

One of the consistent mistakes I see companies make when they go Agile is obsessing over the ceremonies ie meetings of Agile SCRUM. Agile SCRUM defines 4 meetings, SCRUM, Grooming, Planning and Review. When companies are too strict about Agile SCRUM ceremonies, the Agile Team can spend way too much time in meetings.

I have been in several organizations where 5 hour planning sessions and 3 hour grooming sessions are the norm. At a macro level, if you have 8 team members and your planning sessions are 5 hours, then the team is spending 40 person hours in meetings, when they could be doing actual work.

In one organization, which Sprint Planning was around half a day, the team spent hours doing very mundane tasks. Here is an example:

• SCRUM Master asks who wants to take a User Story
• A Team Member volunteers
• The User Story is opened up in whatever Agile Software the organization uses
• A subtask for Code is created and the developer is asked how many hours it will take
• A subtask is created for Code Review, a Team Member is asked who wants to take it and how many hours it will take
• A subtask is created for Test in QA, a Team Member is asked who wants to take it and how many hours it will take
• A subtask is created for Test in Dev, the developer is asked how many hours it will take

Rinse and repeat this entire process for every User Story that will be placed in the upcoming Sprint

After attending just one of these Sprint Planning sessions, I suggested to the SCRUM Master and the team that we just use Sprint Planning to assign User Stories to Team Members and as a team, decide which User Stories will be placed in the Sprint. Once Sprint Planning is completed, Team Member would individually create their own subtasks for the User Stories they were assigned and use Slack or Cisco Spark to find out which Team Member would work on the subtasks they created.

After the Team agreed to implement this change, the Sprint Planning sessions went from 5 hours to 45 minutes, which meant that the team was no longer losing half a day at the beginning of each Sprint iteration in planning.

Leaders not Recusing Themselves from Team Decisions

Another mistake I have seen organizations make when implementing Agile SCRUM is that Managers and Leads are not recusing themselves from decisions. What I mean by this is that when the team is making decisions such as what size to give a User Story or whether a Backlog item should be added to the Sprint, Managers and Leads should not have a vote.

When someone is in a position of authority over you, it is human nature to want to please this individual and one of the ways people do this is by agreeing with them, even if it is against their own self-interest. Team members voting against their own self-interest to appease the corporate hierarchy is inefficient, problematic and will only cause problems for the entire team.

For example, on one SCRUM team I was on, the Lead Developer was apart of the Development Team. During Sprint Planning, when the team would size User Stories, many times I saw the Lead size a User Story one way and the Team Members would size a User Story a different way, typically higher than the Lead Developer. What do you think the Team Members did when the team took another vote on what the final size of the User Story would be?

Yep, you guessed it! When the Lead Developer stated that a User Story was a 1 and everyone else said it was a 5, in final voting, the Team Members would suspiciously change their voting to a 1.

On one SCRUM team, during the beginning of a SCRUM stand up, the Lead Developer was proposing to add a new User Story to the Sprint, which was set to end the next day. He was very insistent that the code change was easy and not difficult to test. When the Team was asked if they thought it was appropriate to add a User Story to the Sprint a day before the Sprint was set to end, who do you think they agreed with?

QA was now forced to take on a last minute testing task at the very end of the Sprint, the developers had to perform another Code Review and help QA test the new changes, which at the very least, increased stress and possibly put the Sprint in jeopardy.

Insisting on Putting Hours on Tasks

Putting story points on User Stories was originally conceived because people are pretty bad at estimating in hours. One of the biggest mistakes I see organization that implement Agile SCRUM make is insisting that Team Members put hours on tasks, which is inefficient, a task that isn’t beneficial to the team and results in double guessing.

Forcing Team Members to put hours on tasks is a bad idea because:

• You have already asked them to estimate a size for a User Story, now you are asking the team to guess again, by putting an hourly estimate on a task.
• that you have forced a Team Member to associate a task with hours, the Team Member will subconsciously try to meet those hours, sometimes sacrificing quality and it was nothing but a guess in the first place
• Team Members many times will panic when they see that they have exceeded the hours that they estimated, which brings on unnecessary stress and tension
• Hours on User Stories has nothing to do with the Team and everything to do with Management wanting to see numbers on a chart
• Hours on tasks has a feel of micromanagement and it can be construed that this is being done because there is little trust in the team completing the User Stories they have agreed to complete in an iteration

Team Members at the very most, should only be asked 2 questions:

• How many points should be placed on a User Story
• Can you complete the User Story in the upcoming Sprint iteration

At the end of the Sprint iteration, the Team should be judged on whether or not they completed the User Stories the entire team committed too at the beginning of the Sprint iteration.

That completes part one of this blog series on mistakes companies continue to make when implementing Agile SCRUM. I hope this was beneficial and I will be back with more of my personal observations.