Having been on a number of different projects attempting to use Scrum in multiple organizations, I have noticed recurrent patterns of it being applied incorrectly. The decision to use Scrum (or in some cases force its use) is well intentioned. But when the rubber meets the road and a project gets underway, typically teams find out Scrum is more difficult than originally thought. This leads to skipping parts of or trying to shortcut the methodology and process. This results is the team not reaping the benefits Scrum has to offer and gives the impression to team members that Scrum doesn’t work. Here are some of the behaviors I have observed.
Skipping the Planning Session
I have seen this happen because the stakeholders, project managers and architects/engineers can’t or don’t want to all meet up to do the planning. I have also seen this happen when the primary project driver or stakeholder refuse to do nothing more than throw a bulleted list of ‘things’ desired at the development team with a completion date.
This results is an incorrect or incomplete set of backlog items for the team to deal with. Of course, this increases risk and probability of failure.
To help alleviate this problem a surrogate should be appointed for those key stakeholders and team members that can’t or won’t participate. Also the team can rally and not start any further work until a planning session is accomplished making it clear the non-participants are the road block.
Missing the Point of the Scrum
It is very common for team members to chat way beyond necessity during the scrum meeting. People just like to chat. It’s also common for members to talk about things other than their assigned tasks. I have seen scrums complete in the allotted 15 minute time box where none of the defined task were truly discussed.
This behavior unequivocally leads to a project out of control. Probably leads to the typical chaotic behavior that was being practiced before Scrum was mandated. There are a number of causes for this happening including the Scrum Master not enforcing proper behavior probably due to lack of training and experience with Scrum. It is also caused by the tasks not being properly defined. If a developer is discussing working on things other than assigned tasks, that person is either goofing off (probably not the case) or has identified another set of tasks which need to be captured. This probably means the backlog items weren’t defined correctly (see Skipping the Planning Session) or the project development has gone way off track.
It helps to have some training or an experienced person lead or help run the Scrum process. It is difficult to learn from scratch and stumble over all the typical mistakes. It also helps to scope the sprints short adding only a few backlog items with a small number of tasks. 2 weeks max for the sprint 4-8 hours max for each task.
Task Lengths Way Too Long
Defined tasks with a length greater than 12 hours means either you don’t have a good understanding of how to break down the task or you’re padding the time you think it will take so there is no pressure in completing it. Probably the former. I have seen task length definitions of 40+ hours.
Not taking the time to plan out the tasks and not making an effort to scope them properly does not help the project and defeats the purpose of using Scrum. Part of Scrum is learning how to estimate properly and learning the capabilities of the team. This knowledge helps in future planning sessions.
Assuming Nothing Changes
Change happens on virtually all projects whether or not you use Scrum. The fallacy is that once the project plan is in place nothing will change. Most management teams put in place a set of defined product features that is fixed. It is to be completed by a fixed date with a fixed set of resources. I have never seen a plan Not waver while in progress.
Scrum and Agile methodologies are specifically designed to help address changes during development. It’s ok to set long range goals but define short sprints, spend time planning them, use feedback from the sprint results and changes that happen during the sprint in a feed back loop during planning and expect anything may change mid-flight during development. You will be able to better adjust if you have flexible development cycles.
There are other wrong Scrum practices. These unfortunately occur frequently. If you plan on using Scrum, take the time to learn it first and decide if it’s appropriate for your organization. If you use it, make a concerted effort to follow the methodology correctly. It will be beneficial!