Agile Trainers and Coach's opinions coming across as facts
I've started to notice a disturbing trend with some Certified Scrum Trainers and Agile Coaches; this phenomenon generally occurs when I join a Team as their new coach. I've found that the teams' previous CST's or Coaches have laid the groundwork to use their own personal methods as Scrum gospel. The CST or Agile Coach has established that their own personal opinion is a requirement, a must, and the only way. This way of thinking contradicts the fundamental purpose of the Scrum Guide. The correct way of thinking employs a comprehensive understanding of the Scrum Guides. If there is no definitive answer to the query at hand, then the CST should offer up possible solutions, noting which solution they believe, based on their experience, is best.
The CST or Agile Coach has established that their own personal opinion is a requirement, a must, and the only way.
It's OK to state what you believe. It's welcomed. Just don't make it come across as a fact. Let it be known that there are other viewpoints, maybe even offer up a few. You can differentiate your opinion from the rest, but be ready to talk about why you believe in it so strongly. It's also important to note what is part of official Scrum and what is not.
User Stories
This avenue completes an objective of "seeding" the Product Backlog
User Stories are not part of official Scrum. You're not required to create them however, most Teams do. This avenue completes an objective of "seeding" the Product Backlog. Whenever this item is discussed on my Team or in a class, I am quick to state that implementing User Stories is one possible way to fulfill this objective. It's prudent to state that implementing the method of User Stories, to seed the Backlog, is my opinion based on my experience.
Capacity Planning
Scrum doesn't talk about capacity planning. We all understand that capacity planning process involves determining the hours available across the team members, breaking down a story into tasks, then deducting those same hours from the respective team members' capacity (hours). Depending on who you ask, you may be told that Capacity Planning is not productive, in other cases, some Trainers may tell you they employ the method categorically. These are both opinions as neither is endorsed or mentioned, by the Scrum Guide.
Depending on who you ask, you may be told that Capacity Planning is not productive, in other cases, some Trainers may tell you they employ the method categorically.
In my world, Capacity Planning works great because it helps the Team not to over-commit. If you were to hire me as an onsite coach, I'd let you know that not all Coaches believe that Capacity Planning is effective. I will always recommend to try it for at least three sprints, disclaim that this is my opinion, then I'll reference my experience to explain why.
Estimating
Some Trainers and/or Coaches come from an in-house corporate background. In this environment, they build software on an on-going basis and believe that it's "done when it's done". To them, there's no need to estimate the backlog ahead of time. Heck, some believe there's no need to estimate any of the stories, just pull them in based on what you think and use the count of stories as the estimate. This method can work in some environments, but not across the board.
Other coaches have more experience in the client/provider model. In this environment, there is a lot of refinement. Planning and estimating are required to give the Client a timeline (including a release plan) and budget before a project ever starts. In this case, estimating is required to the point where you can plan "a first" release.
Further, choosing not to disclaim the method as an opinion is in detriment to the Team in counsel and to the Scrum community. It fosters confusion.
Scrum doesn't talk about how you estimate. There are some highly suggested or common techniques, some of which I've used. In fact, in working with paying clients, my team has to estimate the entire backlog to be able to provide a budget and timeline. Without the former, the latter is impossible.
It's not that one method is right and one is wrong. In the examples above, the environment dictates the most effective method. It is a disservice to a Team to teach that just one of the methods is the holistic solution for all Scrum endeavors. Further, choosing not to disclaim the method as an opinion is in detriment to the Team in counsel and to the Scrum community. It fosters confusion.
CST's Be-Mindful
...put ego aside, communicate multiple methods, and let the Team decide which is the most effective route to achieving the respective objective.
My message to my fellow CST's and Coaches is this: be mindful of unilaterally employing methods outside the boundaries of the Scrum Guides. These methods should be disclaimed as opinions based on your experience as a CST and Coach. Be mature and humble enough to recognize that there are other avenues to achieve certain objectives. We should state our opinions as opinions, then be prepared to back them up with reasoning. A true Scrum Evangelist will put ego aside, communicate multiple methods, and let the Team decide which is the most effective route to achieving the respective objective.
Thank you!
