One might think that when one wants Scrum training all they have to do is pick a CST near them. Unfortunately, there is a tremendous variation in the curriculum and quality of Scrum training in the industry today. Picking on the basis of location or their certification alone has resulted in many teams being taught a CSM course that really doesn't meet their needs. This, of course, makes it difficult to achieve the results they desired. What you experience at a CSM course is basically at the discretion of the individual trainer - certification does not mean any standardization. Some teach the class assuming people already understand Scrum and focus on the Scrum Master role. Some recognize many people there won’t know much about Scrum so teach more of an introduction to Scrum class. At a minimum, you should know what is being covered in the class.
Unfortunately, the variety in curriculum is not the greatest challenge. Nor is style – different trainers have different styles – an interactive lecture course is not necessarily better or worse than a fully experiential course. Ironically, it is the mindset of the trainers that often causes the problem. Not that any CST's mindset is wrong. It is just that this too has great variation and may not match the mindset that would work best for the client at hand. By mindset, I mean a person’s view of how the world works - software development in particular. Many in the Agile community are firm believers that the team is king and that management needs to stay out of their way. In our mind this is an over-reaction to when management over (micro) managed. The new paradigms of Lean and Kanban allow for a better collaboration between management and teams. Some CSTs have embraced this while others have not. This variation also needs to be addressed to ensure the effectiveness of your training.
We've written a couple of blogs on the importance of mindsets:
In an effort to alleviate this problem, we’ve put together a list of essential questions to ask anyone who is going to give you CSM, or other Scrum, training. This will enable you to be sure that their approach, curriculum and how they believe software should be developed matches what you think best to get the training you need. At the risk of this sounding like a marketing pitch, we’ll make sure we make it clear what we believe for each question. Whether you use us or not is not relevant. Finding a trainer who matches your own needs is the point. Questions:
Will the course be an introduction to Scrum or will it focus on the Scrum Master’s role?
What do you see as the role of management in agile transitions?
How important is mapping out my value stream?
What Type of Estimation Methods Do You Teach?
What practices around test-driven development do you espouse and cover in the course?
Is there value in defining my workflow?
How should I scale Scrum to the enterprise?
What do you teach about managing delays and limiting work in progress?
Does the CST believe he/she should give minimal information only?
We’ve seen CSTs offer what is essentially a “how to coach agile teams” course – with little explanation of what Scrum is. We've also seen the opposite extreme where the course is really about what Scrum is and where the Scrum Master role is barely discussed. Know what you are getting. We offer both Scrum Master Certification courses and Team Based Scrum courses.
Responses will vary from – “get management out of the way so teams can do their job” to “management is good as long as they don’t interfere with the teams” to, “management is important, but mostly to remove impediments the team is facing.”
We believe management is critical to any agile transition that is beyond a single team. Management has the ability to change the way teams are staffed, interact with other teams and interact with other parts of the organization. Management must be involved to improve the value stream that the team finds itself in. This does not mean management gets to tell the teams what to do, however. Teams must still display self-organizing behavior, but management can oversee teams to ensure that they are manifesting the vision of the business.
TIP: See Guy Beaver's blog Mid-Management in the Lean-Agile Enterprise: Competencies Required for a comment on management's role in Lean-Agile. See “Management’s Role in Lean-Agile Development” from Lean-Agile Software Development: Achieving Enterprise Agility for a brief introduction.
To us, understanding the value stream is critical. Agile transitions must involve more than isolated teams – one must see how they interact with each other. It is very difficult to change things that aren’t visible. We’ve seen many organizations stumble over challenges that were relatively easy to fix because they could not see them. Value stream mapping is a straightforward way to achieve this visibility. It is highly suggested that your Scrum trainer have experience here.
TIP: See “An Agile Developer’s Guide to Lean Software Development” (pgs 18-21) from Lean-Agile Software Development: Achieving Enterprise Agility for information on value stream mapping and why it is so important.
The most commonly used method is Planning Poker. However, we’ve found that most teams fare much better with Team Estimation. Your trainer should know both and be able to teach what will be useful to you.
TIP: See “The Team Estimation Game” from Lean-Agile Software Development: Achieving Enterprise Agility for a brief introduction.
We advocate all Scrum teams (actually, all Agile teams) follow a practice called Acceptance Test-Driven Development. Essentially, this is when acceptance tests are defined (not necessarily written) prior to programming. We have found teams following this practice achieve significant improvements to quality while lowering work effort. Unfortunately, most CSM trainings do not cover this.
We strongly encourage our clients to adopt Acceptance Test-Driven Development. This is one of the few practices that has an immediate, positive impact on the teams in terms of time and quality. Given most teams are overwhelmed with work, it is important to start a transition with something that will actually save you time. One Scrum practitioner remarked ATDD led to their “best sprint ever” immediately after she learned of this process. Make sure your CST is familiar with this concept and incorporates it into your Scrum training.
TIP: See The “Role of Quality Assurance in Lean-Agile Software Development” from Lean-Agile Software Development: Achieving Enterprise Agility for a brief introduction. Click here for essentially the same information in a webinar format.
The success of Kanban has demonstrated that doing so aids continuous process improvement and team learning. Unfortunately, the answers you get from CSTs will mostly vary from “it’s impossible to do” to “there might be.” Few CSTs are strong proponents of this Lean practice. Creating a defined workflow forces the team to discuss the best way to develop software and then manage it to continuously improve it. Defined workflows are typically tuned by the teams managing their work-in-progress at each stage of the workflow.
If you need iterations and don’t want to do Kanban, you can retain iterations with your defined workflow and do Scrumban. We have seen many Scrum teams improve their process dramatically by creating a visible, explicit statement of how their work is done. The large number of teams who were stuck in their Scrum process that used this method to improve demonstrates its effectiveness.
TIP: See Alan Shalloway's blog on Why a Kanban Board is a Value Stream Map. To learn more about how a defined workflow can assist your team, read Alan Shalloway’s blog Lean/Kanban 2009 – Wow! You can also watch Chris Shinkle’s experience report from the conference that was the inspiration for many of Alan’s comments.
Many CSTs will tell you Scrum of Scrums is the method to use. Unfortunately, there is a big division of thought as to whether it actually works or not. Scrum of Scrums is a good method for sharing information, but few companies have made it work to scale Scrum throughout the enterprise. The essential difference relates to people’s attitude about the role of management. Does your prospective CST believe in a management vision or a team vision driving your enterprise agile transition?
TIP: See “Management’s Role in Lean-Agile Development ” from Lean-Agile Software Development: Achieving Enterprise Agility for a brief introduction..
Agile teams have been discovering huge benefit in managing how much work in progress they have in order to minimize delays between different types of work. Again, it is unfortunate, that few CSTs teach this. Make sure yours does.
In an interview with Agile Collab, Ken Schwaber said " I estimate that 75% of those organizations using Scrum will not succeed in getting the benefits that they hope for from it." Later in the interview he ascribes this result to "many organizations change Scrum to accommodate the inadequacies or dysfunctions instead of solving them." He discounts the possibility that perhaps Scrum is not the right method to be using for certain organizations or teams. We have found that team agility is often not the problem. In fact, in large organizations we've found that starting with the team alone, especially with Scrum, is often counter-productive. See Where to Begin Your Transition to Lean-Agile. If your CST only knows one method they may very well be like the person with a hammer seeing everything as nails.
As you might expect, we teach Scrum, XP, Kanban, Scrumban and Lean. We do not believe in a one-size fits all approach. This means, of course, that we need to know how to teach different sizes - and we do.
If you are having success with Scrum but want to polish your practices, check out our Lean-Agile Pocket Guide for Scrum teams. You can get online access for free. If you are having trouble with Scrum, check out our Scrum Clinic. It’s a page we’ve created and are extending to help those who are having trouble with their Scrum implementations. If you are already using Scrum, you may find the section How to Vastly Improve Your Scrum Team in an Hour.