Optimizing Success: Results-Driven Scrum Practices

The Scrum methodology, if pursued correctly can deliver excellent results. Unfortunately, many organizations have what they consider 'Scrum' but in reality is more 'hybrid Scrum'. To realize Scrum benefits, it is important to approach Scrum the 'right' way. In doing so, your organization values from:

• Quality, which means less bugs.
• Faster delivery, which converts to lower costs.
• Internal (on the job) and external (customer/end user) satisfaction. This of course converts to continued and increased business, and staff retention.

An example of Scrum implemented the wrong way, which seems to be fairly common in 'hybrid Scrum' organizations:

What is wrong?

• In 'true Scrum', a Manager does?not?manage in the traditional sense, but takes more of an observational and support role,?in the case where issues cannot be resolved within the Scrum team itself, or after the Scrum team communicates with other Scrum teams.
• A Product Owner does?not?manage Scrum Masters, Developers or QA in true Scrum. The diagram above shows a hybrid Assistant Manager/Project Manager in waterfall environment.
• The 'management' approach or unspoken mentality thereof assumed by?anyone other than the true Team Lead/Manager?is also wrong. It is of course okay for Product Owners, Scrum Masters, Development and QA to assert confidence and express opinions, but none of these roles should tell others what to do. This includes selection of stories (team commitment/agreement is required to ensure that everything is manageable),?one?person?mandating?a certain approach, and so on.
• The more 'true Scrum' is stretched, the less favors it does for you from a personal perspective if you ever apply or move to another division or organization where a more 'true Scrum' approach is used, especially if you pursue a Scrum coach role. With that said, even when presenting a convincing argument to approach 'true Scrum', sometimes it is difficult to change an organization's culture and ways of working and proposals to change can only be pushed so far from a political perspective.

The concept of Scrum completely removes the old ways of project management and places power and decision making within the team in a way that the team is truly self organized, self disciplined, and self motivated. Notice the diagram below:

In the selection of new Scrum teams, or new team members, one should consider a balance of personalities (to avoid personality conflicts), skill sets (a mix of junior and senior resources to help people grow), and experience (to help people share ideas from various perspectives).

In addition, it should be stressed that a true Scrum organization is collaborative. They are in constant communication with each other, which helps build trust and respect. Story issues should be raised early and risks reduced or mitigated with Scrum of Scrum or other team Scrum Masters and Product Owners included. General areas for improvement are also discussed and recorded in retrospectives with clear owners with actions/next steps noted during retrospective sessions. Retrospectives should consider the entire spectrum of 'work' - to include the good and bad of Scrum 'management' (i.e. story detail, grooming), team communication (internal and outside a team), training needs, technical issues, etc.

Scrum Masters should also be careful not to approach sprint ceremonies as a checklist item in terms of setting up meetings and forgetting about them after: they should follow up on questions and concerns to support further improvement.?There is value in each Scrum ceremony if approached correctly.?A Scrum Master's role as a servant leader is to support and facilitate, with emphasis on ensuring that stories are properly assessed during grooming, that stories completed on time and that team members remain motivated. As part of grooming, it is important to note that story points and estimates are not arbitrarily assigned. During grooming, consider counting down (3, 2, 1) and have everyone provide their assessment then... or use online planning poker tools. This prevents others from waiting to see what others use for their estimates and sizing, and then copying them. Deviations should be discussed, which helps identify misunderstandings while reaching a more valid estimate and sizing.

As part of Scrum, the concept of 'hybrid roles' should be avoided as well, to avoid conflicts of interests. For example, a Product Owner should typically follow the traditional approach of writing stories, seeking dependencies, review and accept user stories. But if other roles in the team compliment the PO role (i.e. Technical Business Analysts), where there is documentation and dependency research overlap, to increase efficiency (from a duplicity perspective) and help with work load, this type of 'hybrid role' work is okay as long as it gets approval from the PO (as the?accountable owner?of sprint stories and backlog). On the latter, only the PO can accept stories. The Scum Master or any other role should never do this. This is important to remember on the last Friday of every sprint—the PO should set deadline expectations (cutoff time) for story acceptance to ensure any remaining stories are reviewed and accepted. Preferably, completed stories are reviewed and accepted as they are completed or perhaps once a week to reduce the review load at the end of the sprint.

Another common mistake in Scrum is approaching stories that are too large. Stories should be broken down into small, manageable tasks. This allows stories to be worked on in parallel with other Developers and also increases velocity. While not always the case, larger stories tend to have a higher story point value, whereas multiple small stories tend to have a lower story point value, so there is less 'lost' at the end if not all work can be accomplished by the time the sprint ends.

_________________

Curtis Carmichael is a Certified Scrum Master (CSM), Senior Technical Business Analyst, UX Designer, and Digital Marketing Expert with an MS in Information Technology. He currently resides in the general Boston metro area and works remotely. Email: [email protected], phone: 603-769-8012.

Disclaimer: These views are my own and are not endorsed by any W2, 1099 or other contract relationships. In addition, improvement examples provided are not reflective of observations during the course of prior or current employment.

Copyright???2021 Curtis Carmichael. All rights reserved.