A Roadmap to TDD adoption

schedule Oct 15th 03:15 - 04:00 PM place Tiered Classroom people 15 Interested

You've heard all about how TDD will solve all your problems on a software project. Your defects go away, your time to market decreases, customer satisfaction goest through the roof. Everything is supposed to be awesome if your team just did TDD. However every time you try to adopt it, the adoption fails. Why? Let's explore why TDD is so hard for teams to adopt and find an alternative approach to either adopting it, or getting its benefits.

 
8 favorite thumb_down thumb_up 4 comments visibility_off  Remove from Watchlist visibility  Add to Watchlist
 

Outline/Structure of the Talk

5 min - Introduction to Test Driven Development (TDD) - We will discuss what TDD is and explain its main benefits

10 min - Discussion - Audience members will discuss to see if they have tried to adopt TDD, why did they chose to adopt it? And how successful was it?

5 min - We’ll explain how organization typically adopt TDD and why the adoption rate is so low.

10 min - We’ll go over the hurdles to overcome in order to be able to adopt TDD. The skill gap, the impact of software design and architecture.

10 min - An alternate adoption pattern will be presented based on my experience at several companies:

  • Focus on design and clean code
  • Learn how to write unit tests
  • Enforce tests in the same commit as production code
  • TDD exercises
  • Complete well suited stories in TDD fashion
  • Switch to TDD

5 min - Q&A

Learning Outcome

The attendees will:

  • Have an understanding of what TDD is (we will not be doing a demonstration)
  • Learn that TDD is more about design than testing
  • Understand the prerequisites to TDD adoption
  • Obtain a roadmap to bringing TDD to their teams.

Target Audience

Developers, IT managers, Scrum Masters

Prerequisites for Attendees

Basic familiarity with how software is written.

schedule Submitted 9 months ago

Public Feedback

comment Suggest improvements to the Speaker
  • George Dinwiddie
    By George Dinwiddie  ~  9 months ago
    reply Reply

    Hi, Ben,

    The outline/structure is the place where you sell your session to the reviewers. Help them recognize that you'll deliver on your abstract. Give them details about the content and the way that you'll present it to convince them that you'll do a good job.

    See also https://threadreaderapp.com/thread/1028714041349263360.html for an independent description of submitting a successful proposal.

    • Ben Scott
      By Ben Scott  ~  9 months ago
      reply Reply

      Thank you for the tip. I've updated the section. 

      • George Dinwiddie
        By George Dinwiddie  ~  9 months ago
        reply Reply

        Why _is_ the adoption rate of TDD so low?

        Does "Enforce tests in the same commit as production code" result in high quality tests? Or just tests?

        • Ben Scott
          By Ben Scott  ~  9 months ago
          reply Reply

          The adoption rate of TDD is low because teams typically try to jump into TDD without spending time on the prerequisites. After seeing all the hurdles to overcome they give up and go back to their old practices. They also tend to miss the whole point of TDD. It's not about test coverage, it's about design.

          This talk isn't about having high quality tests, that's not the point of TDD. Note that I won't be talking about ATDD nor BDD. This talk is more about becoming aware that TDD is all about design. A requirement of good design is that the application is testable. To test effectively the software probably adheres to some form of design patterns such as dependency injections, interface segregation, dependency inversion and the like. This is the real benefit of TDD, the regression suite is a side effect. 

          Now I'm also not advocating for 100% code coverage, I wouldn't test trivial code such as getters and setters . However if you're writing business logic, that code should have tests.


  • 45 Mins
    Talk
    Intermediate

    Despite thinking that organizations are slow to innovate, innovation actually abounds at many companies. Kodak, DEC, and Xerox did not fail due to lack of new, cutting-edge innovation; they failed because their organizations were tuned to their traditional markets, and a failure to change their business models and organizations led to their eventual disruption.

    The key to achieving business agility lies in leadership that transforms organizations. Transformational leaders succeed by changing the system, leading with purpose, and steering from the edges. They own their responsibility and boldly lead their organizations into the future. As leaders, we can accelerate this evolution by enabling true self-management and team-based governance.

    Join Bob and Sanjiv to learn how leaders can transform organizations with a flatter organization structure, work anywhere flexibility, participatory profit sharing, and delegated hiring and firing. Explore the agile leadership journey needed for true business agility.

  • Liked Ben Scott
    keyboard_arrow_down

    Ben Scott / Dennis Sharpe - Business Value Live

    45 Mins
    Talk
    Beginner

    At the beginning of a project, teams will usually spend a lot of time on infrastructure, making it hard to demo anything to the business. There is a constant battle between engineers and product owners on what needs to be built first.

    But you do not need to compromise. Infrastructure can be generated, using an application generator called JHipster that allows scrum teams to focus primarily on delivering business value right at the start of a project.

    In a live demo, we will show you how to first generate a new Angular/Spring Boot application with just a few keystrokes. Then we can quickly deploy that application to the cloud. Lastly, we will create a Jenkins pipeline for automated CI/CD and deploy some changes quickly. The audience members will be also able to interact with the application using their mobile device.

  • Liked Sanjiv Augustine
    keyboard_arrow_down

    Sanjiv Augustine / Audrey Scheere - 7 Transformational Sparks for Business Agility

    45 Mins
    Talk
    Intermediate

    Agile transformations typically fail to deliver true business agility because organizational power structures, norms, and culture remain locked into legacy models that oppose Agile. Similarly, companies fail because their organizations remain tuned to their traditional markets, even as disruption creates new dangers and innovation new opportunities. The failure to change hidebound bureaucracy and rigid organization structures leads to eventual disruption, and often dissolution.

    Agile methods can serve as a foundation for organizational “sparks” that are adaptable and resilient in the face of disruption and relentless change. Those looking to leverage investment in Agile as a business differentiator must heed Conway’s Rule, and adapt organizational elements to support and enable true business agility. Join Sanjiv and Audrey to explore essential organizational sparks for business agility, including Lean Discovery, Agile PMO, Agile Budgeting, Dynamic Strategy, and Portfolio Kanban.