How much training does each unit need? Nobody knows. This isn’t a recipe. But a survey of all the software development teams would hardly find two out of 100 who consider training a priority. They see ceremonies and charts and lists as priorities.
I hope you love to train… and drill. I love it and so do all the successful software development units.
According to the definition of “self-organizing teams,” the answer comes from each individual in the unit. They say how much training they need. They define the type and urgency. And when they say they need to train, the mission either goes to another unit or waits for this unit to train.
Urgency to demonstrate progress leads to early failure. But this industry bathes in failure. I wonder if they like it.
Training or Drill
Should the unit train, or should they drill?
Training introduces knowledge or techniques that the unit (or some individuals) doesn’t yet know. One of the items often ignored for software developer training covers the business model. For instance, when asked to provide solutions in a financial or banking system, the software development unit should have training provided by a domain expert – a financial and account manager or someone similar. In the same way, if the software development unit does not yet understand warehousing and the solution involves shipment and receipts, a similar business domain expert could provide training to the entire software development unit.
The place to start is where you’re at. (Bad grammar; good concept.)
If a new member does not know about TDD, individual training should be provided on an individual basis. Different needs require different approaches to training.
When the software development unit knows a topic (like S.O.L.I.D.), they should still get periodic reminders. Drill can involve Katas, or exercises, or other repeatable tools. These “skills-polishing” exercises can even be accomplished individually, so long as flexibility exists within the iteration for software developers to “break away” from coding and design for these exercises. Exercises, again, can even be automated.
| Training | When a new project introduces new ideas, technologies, or business domains, training provides a whole-unit approach so everyone knows the necessary minimum (or more). |
| Drilling | A constant effort to stay proficient at the technical or domain-related skills and knowledge necessary to excel at software development. |
Where to Start
The place to start is where you’re at. (Bad grammar; good concept.)
Get the software development unit together and find out where each member of the unit thinks they need either training or drill. Do this as a unit and do everything possible as a unit from now on. Open up. Start the trust with the first meeting.
Then start the plan of how to get better. Plan training sessions and define the first three. Decide when and how often to have training.
Start drills. The easiest way to drill is by Pairing. If no one is comfortable with pairing, there’s a training session. Some people do pairing well. Some do it poorly. Find someone who enjoys pairing and has no ego. Train the rest of the unit based on that person/pair’s experiences.
Introduce Katas. Provide code that could benefit from refactoring and refactor in a pair. Then do it individually. There’s no lack of code that needs refactoring. Make each exercise a lesson in one of the principles of good code: patterns, SOLID, DRY, clean code, readable code, self-documenting code, and on and on and on.
Take pride in the Unit
Let the unit grow in knowledge and respect and professional security by training and drilling.
We Haven’t Got the Time
Then you’ve got the plan to fail.
Previous: Training Schedules