All training classes have a learning objective. At Adaptworks, the objective for the Certified Scrum Developer®
) training is reinforcing Agile principles and teaching Agile techniques for developers who work on Scrum projects.
In general, developers realize better results when learning Agile development techniques than when learning the philosophy of the framework in which they are working, or in learning the execution centered on the beauty of the framework.
The CSD training course was structured in the following way:
On the morning of the first day, I explain what agility is, including some Scrum core concepts. In the afternoon, I focus on explaining the product vision, the requirements, estimates, and test-driven development in the context of Scrum. The second and third days vary from class to class as to the presented techniques. However, we always focus on executing sprints with the goal of generating an e-commerce website. With this structure, the training's Net Promoter Score (NPS) varies between 50 and 100, with an average of 80! For those who are not familiar with this tool, you can believe that this is an impressive score. The NPS score is based on the answer to the question: How likely is it that you would recommend our company/product/service to a friend or colleague?
The tenth CSD training day
On the tenth CSD training day, I discover that the class is made up of 80 percent COBOL developers. It's clear: The CSD is aimed at web development, which is remotely related to mainframe development. I look for people I know who develop using COBOL code to check whether they had already worked with COBOL in Agile projects. I am able to contact three COBOL developers, and none of them have practiced agility with this programming language. In fact, one of them even laughs at me!
I search the Internet and discover a way to develop COBOL for the web (Visual COBOL). After running COBOL code on an Apache Tomcat server, I am back in my comfort zone and think this will be another ordinary training.
First CSD training day
I start the training session by saying that, because of this training, I have written my first COBOL code and that I am very happy to be able to run it on an Apache Tomcat server.
The morning of the first day progresses as usual. However, after lunch I realize that this training is going to demand more than the usual amount of creativity from me. The company's internal rules forbid the use of nonhomologated tools on the users' devices, which means that I cannot use Visual COBOL. After talking to the students, we conclude that it would be possible to complete the programming activities by using the company's development environment. That is, the students will use the mainframe to generate the application screens. In this way, the students assume the responsibility of executing their own training.
While teaching Product Discovery techniques, I realize that the students in this class are so distant from the end user that the concept of the "persona" does not make any sense. After all, most of the time they get a request and make the necessary correction in an application that has existed for more than 20 years. Thus I understand the obvious: The training should focus, more than any other element, on the excellence of the execution of Scrum and on its pace of delivery. I make a few changes in the execution of the training and explain the estimating techniques.
Later I go back to the hotel, asking myself, "What do I explain about development techniques to professionals who started working in IT before I was born?"
At the hotel, I decide to study COBOLUnit to automatize the tests in COBOL. Unfortunately, the COBOL coding with COBOLUnit does not flow, and shortly before I go to sleep, I realize that my role in this class is dedicated to facilitating Scrum execution.
Second CSD training day
The second day starts with the environment setup. COBOLUnit, like Visual COBOL, is not a tool sanctioned by the company, so it cannot be used. This is yet another miss.
To force pair programming in this class, I limit the number of concurrent devices to half the number of people. During sprint days, I have no problems. In addition, on the first day of pair programming, work starts to flow. I finally do something right. One of the teams reaches the goal before the deadline and automatically pulls activities from the backlog. The framework is making sense to them, and I explain that what they are doing is correct.
At sprint review, all teams have reached their goal, which hardly ever occurs in training. In review, every team understands that they were successful in the sprint because they overestimated their estimates. I am forced to change the dynamics of the review, because I normally execute depressive and disruptive dynamics. The high point of this happy review is that they all understand that it is possible to work in pair programming and with shared code, if there is a strong communication link between the team members.
I plan for the second sprint and end the day feeling that the class is going in the right direction.
Third CSD training day
My goal for the third day is to make one of the students say that it is possible to apply Scrum in COBOL projects.
We had agreed that the sprint would start exactly at 9 a.m. However, most students are 20 minutes late. Because of this delay, the teams fail the review. The problem with this failure is that I had trained the teams' ScrumMasters to do the review of this sprint. Knowing how inexperienced the ScrumMasters were, I ask them to leave the review with a written plan to improve the process for the next time, something like a kaizen plan.
The sprint execution goes on without anything out of the ordinary, and in the review, all teams have reached the goal and present screens that address the objectives of the clients (almost personas). In the end, we have another hour of training, and I choose to do some dot voting with the students to decide which topic to explore. They choose to talk about scalability with SAFe and David Anderson's Kanban technique.
Until now, I have responded more to changes than in any other training. However, in this training I have learned that focusing on learning, coupled with the students' motivation for applying the framework, makes the training flow and succeed. I almost forgot to mention that the Net Promoter Score for this training was 82, and I got this feedback from one of the students:
Figure 2. Note from one of the students saying that it is "Really cool to use Scrum for COBOL"