Instructor: Gil Broza

Gil Broza

Gil Broza helps software organizations that want to adopt Agile or that find their current use of it is not delivering on its promise. He guides them in implementing a reliable, sustainable methodology so they truly delight their customers and make a positive impact. He is an “all-rounder”, working at all organizational levels and coaching people in technical, managerial and leadership behaviours.

Gil’s book, The Human Side of Agile”, is the definitive practical guide to leading Agile teams to outstanding performance. His new book, The Agile Mind-Set, examines the most misunderstood part of creating a new mode of working in a world of increased complexity and opportunity. Gil is a regular contributor to, a leading PMI publication. He is a three-time track chair for the Agile 20xx series of conferences, a sought-after speaker for other industry events and groups, and a host of numerous public webinars about Agility. Get a taste of Gil’s approach here.

What Others Are Saying...

  • “Thank you for teaching the Agile Engineering Course. I’m glad I took it and it certainly opened my mind to the “smells” of bad code and how to detect them... Your course gave just enough information and motivation to get started. You taught by convincing us on why Agile/XP and TDD is important with real world examples, instead of lecturing from a book.” — Senthuran Sivananthan, Architect, Architech Solutions

  • “I recently attended Gil’s Agile Engineering course as part of ongoing training to move towards more Agile development processes. He provided an engaging two days of training that highlighted major areas of interest while allowing ample time to drill into topics and explore them in depth. I appreciated his focus on adapting processes to work with our culture and highlighting areas that should be re-examined.” — David Collie, Software Developer, Desire2Learn

  • “Gil is able to get people to try new things, even if they are a little uneasy about moving in the new direction... People know that they’ll have an out if they don’t like the results and that Gil will support them in trying the new approach.” — Bob Fischer, Vice President, Fidelity Investments

  • “Gil provided a 3 day training course for my Engineering and QA staff in TDD (Test Driven Development). The course content was excellent and tailored to our needs, which made it both relevant and timely. The people being trained were unanimously enthusiastic for both the information delivered and the nature of the course. Being primarily based on code samples and exercises it was a chance for in-context and practical learning that I have already seen being applied in our code. The last part of the course was done using our own code instead of artificial samples, something I highly recommend for this sort of training, and Gil was happy to provide this highly valuable addition to us. Gil is a very personable coach who clearly has a deep knowledge of his subject, both technically and philosophically. He conducts himself and his business very professionally and is a pleasure to work with. I have no hesitation recommending Gil and am likely to use his services in the future.” — Simon Palmer, CTO, Empathica

  • “I enjoyed attending Gil Broza’s course... Gil has vast experience in software development, coaching and mentoring Agile teams. He is very knowledgeable on relevant tools in the different development technologies. His strategy is to continuously innovate and leverage ideas for the best practices in different situations for the customer’s benefit.” — Shady Shehata, Senior Research Scientist, Desire2Learn

  • “Gil provided a great training on Test Driven Development (TDD) in my work place. The course was very helpful to understand the TDD concepts, and it was extremely well organized. The course started from basics and in three days we get to see and practice advanced topics in TDD. The lab assignments that we did during the training were well designed to understand and practice TDD.” — Ashkan Aazami, Software Engineer, Empathica

  • “Gil’s technical confidence earns him credence and respect from the developers. I have observed Gil handle difficult software engineer personalities without being dismissive or patronizing.” — Ivan Basch, Senior Manager, VFA, Boston

  • “Gil has been instrumental in raising the bar on the quality of the deliverables of our agile team. The code refactoring exercises, on real/live code, doubled as delivery of new features and as significant increase on the developers’ skills.” — Horia Balog, Senior Architect, Architech

  • “Gil has given several developer training sessions on Agile Development and Test Driven Design at my company, Autodesk, over the years. He is a very clear and knowledgeable educator who draws upon a large body of experience to answer any question. His most recent 2-day course was enjoyable and challenging.” — David MacDonald, Software Developer, Autodesk Media & Entertainment

  • “Even after almost a year our developers continue to make reference to various things Gil had said during the training, which I think is an excellent tribute to his effectiveness. His experience enabled him to handle any question we had, and he was able to quickly show us how to apply many of the training topics (code smells, microtesting, refactoring) to our own code.” — David Day, Manager, Cincinnati

  • “The training Gil gave exceeded my expectations. He answered all my burning questions, such as, ‘When to do Refactoring?’, ‘How to sell refactoring to Management and your team mates?’, ‘How to design and architect in Agile way?’ and more. The workshop gave me skills and knowledge on microtesting, how to fix or add features correctly in an Agile way, and what not to do while in the code. The skills I learned from the workshop will help my Agile team not to create fast and crap instant legacy code.” — Phyo Pine, Senior Software Developer, MonkeyMedia Software

  • “Throughout the course Gil showed us ways to approach complicated architectural changes without ever leaving the code in a broken state. The idea, that any change can be made in safe incremental steps all validated by TDD, opened my mind to new possibilities and a different way to think about developing software. I would highly recommend Gil’s Agile Engineering course to any aspiring developer.” — Scott MacLellan, Senior Developer, Desire2Learn

Is your Agile team producing “instant” legacy code?

Your Scrum/Agile team probably avoids such traditional practices as Big Design Up Front, detailed design documents, manual test plan execution, and code freezes. But what do they do instead in order to be effective in a fast-paced, iterative environment? Demos, code reviews, and a Definition of Done are not enough to avoid creating instant legacy code. In fact, an Agile project management framework without suitable technical discipline is a great way to guarantee failure.

It’s easy to know whether you’re racking up technical debt. Here are some “tells”:

  • Your team practices demo-driven development: all iteration work is guided by passing the demo safely.
  • You hear, “We don’t have time to clean the code or improve its design.”
  • Iteration planning yields surprisingly high estimates for easy-looking features.
  • When asking folks about coding, testing, or fixing something simple, you hear “It’s not that simple.”
  • Team members think, and sometimes even say, “To do this story right, we’d need to double our estimate.”
  • The Definition of Done mentions automated tests and refactoring, but there is no clarity regarding their scope and quality.
  • Mandated test coverage metrics somehow don’t yield higher quality.

Are you aware of the long-term costs?

Regardless of why you do Agile, building software with insufficient technical Agility will compromise your success. The costs over a year or more include:

  • Progress slows down
  • Variability in task duration becomes risky
  • Motivation and engagement go down
  • Over-reliance on experts/silos increases, becoming risky and expensive
  • It gets harder to maintain teamwork and collaboration

All these translate to quantifiable losses of productivity and quality. You cannot remain a leader. Your ability to innovate and respond will fall behind.

Just expecting your team to write unit tests and refactor their code is not enough.

Most Agile developers know about writing unit tests, refactoring their code, continuous integration, and measuring test coverage. But look carefully into what they actually do and you’ll likely discover:

  • Their tests are just not good enough. They don’t meaningfully shorten the development feedback loop (which is the foundation of Agility);
  • The programmers do not refactor their code regularly or frequently. And when they do, they mostly make superficial changes, not meaningful design changes that keep today’s code useful tomorrow;
  • There’s an unsustainable imbalance between code-level tests and UI tests;
  • The developers don’t like the widening gap between the impression their features make at the demo and the quality of their construction.

Developers love to write well-crafted code, so why don’t they write it?

Nobody likes to do subpar work, and definitely not on a regular basis. But somehow, many developers end up caught on a hamster wheel of iterations. They feel pressed to show working code. They feel that there’s less time to do things right, and that even if they did things right under the hood, it wouldn’t be appreciated. Because the demo and the next iteration planning are just around the corner, they find themselves cutting corners.

Programmers need the right knowledge, approaches, and habits to become effective in an Agile life cycle. Is your team adopting them? Many teams and managers, especially if they start with Scrum, presume they'd materialize through “continuous improvement”. Sorry to tell you, but that rarely happens. This sizable undertaking requires commitment, investment, and patience. And almost always, it starts with the team’s management, not with the team.

This course: both techniques and mind-set

Experience has shown that few Agile teams ever become technically Agile just from reading books and experimenting. It’s just that hard. Agile Engineering is quite possibly the hardest topic to implement effectively in all of Agiledom. You have to start with education and motivation.

In Gil Broza’s Agile Engineering course, programmers learn to think and act as Agile developers. They learn reliable, sustainable, and enjoyable software development practices which they can immediately put to use. These techniques, first popularized in Extreme Programming (XP), have been proven, refined and extended for more than 15 years. By using them, attendees will produce working code faster, increase its quality, and reduce technical debt — the demon that snarls later development.

Our promise to students (not mere learning objectives)

Having had almost 300 developers take this course in Canada, the US, and Israel, we can safely promise that our students will be able to:

checkmark Develop simple, clear, tested code faster than ever

checkmark Apply modern techniques such as test-driven development and refactoring correctly

checkmark Evolve object-oriented software with tests’ guidance

checkmark Unit-test the tough cases with ease

checkmark Take on legacy code confidently

Syllabus / Curriculum / Agenda

Code smells. Just as programmers can leverage design patterns and good Object Oriented (OO) practice to produce excellent code, they can know what sort of code to avoid. This knowledge has been catalogued and codified as a few dozen anti-patterns called “code smells”. Methods so long as to require scrolling, classes that have too many disparate responsibilities, and primitives that carry meanings are but three examples of code smells.

We will study more than a dozen common smells that occur within methods or classes. By studying these anti-patterns you’ll get a better feel for clean code, and develop your “nose” for finding low-level design defects so that you can more easily remove them from your code. This is crucial, because code smells often hide bugs.

Refactoring. Even if the code you write today is 100% correct, you will still have to touch it in a month or a year: Extract some reusable pieces, reorganize it for clarity, replace some logic with calls to shared functionality, simplify it, etc. Preserving behavior while improving implementation and design is called “refactoring”, and it is quite distinct from “rewriting”. In this course we will study two levels of refactoring:

  • Low-level refactorings, such as Extract Method and Compose Method. These refactorings alter a few lines of code often in the context of one or two methods. They are quite mechanical in nature, to the extent that modern tools like Eclipse have automated them almost entirely.

  • High-level strategies, such as Gradual Cutover and Parallel Change, which combine several low-level refactorings to make refactoring safe and reliable. If you’ve ever had to make medium- to large design changes, perhaps some of your unit tests began to fail, or the code didn’t even compile for a few hours; these strategies will help you avoid this scary zone.

Microtesting. Commonly called “unit testing”, this is the art and science of writing focused, quick, extremely low-level tests against your code to prove that it does what you think it ought to do. By writing many of these microtests against your code, you will be able to develop it predictably, introduce far fewer defects, and spend a lot less time debugging now and later.

Many programmers automate their unit tests these days, and often fall into the trap of the brittle tests — tests that are difficult to change and sensitive to production code changes. You will learn how to write proper, robust, valuable microtests and how to keep them that way.

Test-driven development (TDD). The TDD process is a great approach to low-risk, fast development of new code, be it small or large. TDD combines microtesting, small code increments or changes, and merciless refactoring to have you write great code without fear. Remember when you would write a few dozen (or a hundred?) lines of code, start testing them, then fix the bugs you found? And remember that it was impossible to estimate (guess) how long finding and fixing the bugs would take? That is a thing of the past with TDD.

Having studied basic application of code smells, refactoring, microtesting and TDD, we will work on “big code problems”:

Dependencies. Most objects in most systems don’t work in isolation; they depend on other objects. Sometimes these dependencies (a.k.a. collaborations, interactions) make testing difficult, unreliable, slow, or ineffectual. Still, that’s no reason to avoid microtesting and just do slow end-to-end testing! You’ll learn how to ensure the speed and fidelity of your microtests when dependencies are present. You will study techniques like faking, stubbing, mocking, and dependency injection. You will practice keeping your tests sharp while testing the contents and process of the interactions themselves.

Test smells. Just as production code manifests patterns of ill-design (code smells), so do microtests. As more tests and production code get written, tests become more brittle, erratic, slow, harder to follow or reuse, and rife with duplication. We will study known patterns in which this trouble unfolds, and discuss ways to nip it in the bud early and often (hint: this has to do with refactoring...)

Throughout the course, we will see how the newly acquired techniques and strategies fit seamlessly in a development life cycle comprised of tasks, stories, and iterations.

Actually applying this knowledge. We will candidly discuss the topics that seem to be on every student’s mind:

  • How do I get my team and management to buy into this, and commit to practicing what we learn here? We’ll lay out the many popular strategies and tactics that don’t work, and examine what you need to do that will succeed in getting others on board.

  • How do we get started? Admittedly, two days of practice are not enough, and we’ll examine how you can started the next day on your own code.

  • Assuming we start strong, how do we prevent backsliding? We’ll see what it takes to keep up the good habits in the face of business pressure.

  • Which metrics are useful? We’ll move beyond ineffective metrics such as "at least N new unit tests per developer per sprint" and "70% code coverage" to metrics that provide useful feedback and drive helpful behavior.

Really? Is this course enough to get us started?

This is not one of those “TDD workshops” focused on technique and process. Becoming technically Agile is a matter of embracing change, which means that proper posture and technique are not enough. Since most students come in with a skewed interpretation of unit testing and refactoring, naturally we’ll teach them proper technique; however, this course focuses on understanding, motivation, and mind-set. We want developers to emerge from this course thinking as Agile developers and feeling confident about Agile technical execution.

Previous participants have said:

“Gil did a much better job of explaining the context/purpose of these practices than other presenters I’ve seen.”
“I can honestly say this was one of the best seminars I’ve ever been to.”
“The instructor-student engagement was great.”
“Pleasant flow, good humour, fun exercises, good pace.”
“Gil made complexity accessible! Extremely well thought out.”
“Everything we learned is immediately implementable in the real world.”
“I couldn’t get this level of knowledge just from reading about Agile development.”

Immersive Experience — No Boring Lecture

You must have been around software enough to know the two best ways to learn such skills: watch the expert, and practice on your own. If you’re thinking of participating, expect this:

You will spend at least 50% of the course’s time in labs practicing your new skills.

  • You’ll work in frequently-changing pairs, which will allow you to test your understanding and learn additional insights. (Almost universally, attendees report that this pairing model is delightful and a great learning enhancer.)
  • Each lab is either a small task or a series of graded small tasks.
  • Each lab is accompanied by the instructor’s solution.

You will also watch video demonstrations of the instructor applying some of the harder techniques. The rest of the time, you will be engaged in an interactive presentation with the instructor.

Curious? Watch one of the demonstration videos (opens in a new tab).

You’ll do the labs in the language of your choice: Java, C#, PHP, or JavaScript. However, this course is all about principles, thinking, and technique — not language or tool specifics. The techniques and strategies you’ll learn are fully and immediately transferable across modern programming languages and technologies. Even if your native language is not Java/C#/JavaScript but you’re comfortable with OO, this course would be perfect for you.

Previous participants said:

“The labs were relevant and engaging. Real-world examples helped to put things in context.”
“Good labs. Small enough but not too small.”
“Outstanding exercises. Gil was extremely clear.”
“Good mix of theory and practice.”
“I took a 1-day course in TDD a little over a month ago. I got more out of this seminar even without knowing Eclipse & being rusty at Java.”
“The lab assignments that we did during the training were well designed to understand and practice TDD.”