I am tasked to conduct a training for an upcoming team of 20 Java developers for a new project. The project owner wants us to use state of the art development techniques like TDD and CI. The developers are skilled Java developers but have minor to no experience with unit testing, and most likely only superficial experience in refactoring. So the overall project manager scheduled a 3 day training for all developers, and some project managers, to learn the "new" techniques, get everybody in a shared mindset and get started.

So I have 3 days (aka 20 hours) to teach them

  • Software Craftsmanship deleted due to answer
  • Unit Testing
  • Refactoring
  • Static Code Analysis
  • CI

Obviously I can't teach them everything. So my questions is

  • how to distribute the available time on these (and other) topics,
  • what to focus on and what do omit,
  • and how to best conduct a training session based on these topics?
  • Although specific to Rails, and it isn't a course they offer anymore, the Pragmatic Studio's TDD with Rails course description has a good outline for a TDD workshop that I've personally rejiggered and used internally. Might be useful for a scope check on that one part, for you.
    – jcmeloni
    May 2 '12 at 13:54
  • @jcmeloni thanks, the outline of the course gives me an idea how they did it. May 2 '12 at 15:43

Software Craftsmanship

Comes with experience. I'd exclude this from training.

TDD/BDD & Unit Testing

I would run these together and I would spend 2 days just on that. There is an awful lot to cover here. You have to demonstrate how you can guide design by tests (unit tests, integration tests and functional tests). You would also have explain how to configure/use mocking frameworks and custom matching frameworks such as nHamcrest


You can teach some re-factoring techniques, code smells, but I don't think that you can teach how to separate concerns. This comes with experience.

Static Code Analysis

Few hours to state its importance in CI process, how to run the analysis and how to interpret its feedback.


I'd spend few hours explaining importance of CI in medium and large size organizations, but there is only so much you can teach. We have different people working on different aspects of CI and they have been doing it for many years. I don't think that you can "train" it in such a short period of time.

  • 1
    I used ideas from all answers, but this answer most influenced me. Accepted. Jun 24 '12 at 20:34

Day one:

Refactoring is at the core of all this, so I would start there. Explain about code entropy and how you can use refactoring to fight that. Introduce DRY.

From refactoring, the next natural step would be to explain about unit tests, because you certainly need a safety net when doing refactoring.

Day two:

Training sessions. Form small teams and then give them some hairy code which they are asked to refactor. Then let the team compare results and discuss their findings. Or you can run a coding dojo to get some hands on experience with basic TDD. One quick way to set this up is with cyber-dojo online.

This day can be wrapped up with a discussion about software craftsmanship: when do we know that refactoring is complete? What is code quality? What is YAGNI?

Day three:

Talk about development feedback loops and how CI helps. Explain about automated builds and CI (which in essence, is just another feedback loop).

Don't forget to tie all it together with some overarching business helpers: being able to respond to change quickly and always working on the most important thing right now.

  • 1
    Excellent answer. for Day 2, you might want to look at my answer to the question How to convince teammates to use TDD, where I describe my experience of running a cyber-dojo for my colleagues.
    – Mark Booth
    May 2 '12 at 17:20
  • @MarkBooth Thanks for the hint about cyber-dojo, I've updated my answer. May 2 '12 at 19:06
  • I like the idea of doing some coding during the session, e.g. kata or dojo is an excellent idea. May 2 '12 at 19:38

That seems like a colossal amount to cover in 3 days. Barely enough time to overview the basics, and no time to cover specific tools nor the application of these techniques by your team on their projects. Moreover, a three day training session will take a lot of preparation by the presenter.

Have you considered following the training (or perhaps replacing it) with a series of regular lunch-hour (brown-bag) workshops to focus on practical details and practice?

1-hour workshops/seminars composed of a short presentation, a demo, and time for discussion are a really effective way to share knowledge. They are also much easier for the presenter to prepare!

  • 1
    It's a distributed team and all team members will be brought in for the training sessions. I like your idea but I am not sure if regular lunch workshops would work out being remote. Still a nice idea. Thank you. May 2 '12 at 19:37

Not the answer you're looking for? Browse other questions tagged or ask your own question.