LeSS in Action: Developers Practices

TBD
Singapore
Сінгапур

Description :

Organizational Agility is constrained by Technical Agility.

The 5-day development practice course is 70% hands-on and 30% lecture and has three main focuses: Large-Scale Scrumtechnical practices, and authentic team dynamics. It covers Scrum practices such as cross-team Sprint Planning, Backlog Refinement, working as a team, and many technical practices such as Test-Driven DevelopmentContinuous IntegrationAcceptance Test-Driven Development, and Refactoring. It also covers how to apply these practices in a legacy codebase situation.

Who is this class for:

We don't expect participants to have prior knowledge of the tech stack listed below, including the programming languages or domain. People are welcome to the class as long as they are fluent software developers.

We also allow 1~2 non-current developers (e.g., a ScrumMaster or PO) in each class, as long as they have some development experience and promise to work as a developer in a team in the class. So far, their feedback is even better than the developers:-) It's probably due to the opportunity to observe a team from within and the others doing their job.

What did people say about my course:

Testimonial from Bastiaan van Hamersveld (CEO of the LeSS Company) https://www.linkedin.com/posts/konstantin-ribel_lessworks-technicalexcellence-tdd-activity-7121106565994024961-0h2K?utm_source=share&utm_medium=member_desktop

From Oleksii Khodakivskyi:

Current Tech Stack:

We chose a particular stack so that people do real work in the class, but the specific stack doesn't matter so much for participation. Our current stack is:

  • a web service (https://doughnut.odd-e.com)
  • VueJS 3 on the frontend using TypeScript
  • Spring Boot backend using Java and MySQL
  • various external service dependencies
  • Cypress for end-to-end testing
  • Github Action for CI/CD
  • Google Cloud for production

The source code is here: https://github.com/nerds-odd-e/doughnut

Agenda :

Monday:

  • Requirement workshop / A-TDD
  • Definition of Done
  • Cucumber and Friends
  • Sprint Plannings

Tuesday:

  • Test-Driven Development
  • Collaboration (Working in teams, SCM, Build Automation and other tools, Pair Programming, Continuous Integration and CI Systems, Collective Code Ownership)

Wednesday:

  • Code Smells & Refactoring
  • Thinking about test and test automation (Testing Pyramid, Mocking, Unit testing in other languages: JavaScript, Python, etc., Good Unit Testing

Thursday:

  • Thinking about Design
  • Feature Team Revisit

Friday:

  • Working with Legacy Code 
  • Craftsmanship
  • Retrospective

Details :

Product Backlog Refinement Workshop

In Large-Scale Scrum, the PBR workshop is one of the most critical activities. By doing the workshop in the sprint with multiple teams, we will cover the three essential aspects of this workshop: splitting big items, detailing the items, and estimating. Some optional techniques we might cover based on the situation include: impact mapping, storying mapping, specification by example, estimation ceremonies, etc.

 

Definition of Done

What is the purpose of the Definition of Done? We will also talk about what it is about, how to use it, and who should ensure it. 

 

Sprint Plannings

(Cross-team) Sprint Planning Part One is mainly covered by the PBR workshop since there's only one sprint. Sprint Planning Part Two will be explained and practiced in detail.

 

Acceptance Test-Driven Development with Cucumber and Friends

This part explains how to drive the iteration with the examples derived from the PBR workshop. We will discuss the detailed technical approaches, good practices, and conventions.

The actual teaching or lecture is usually delayed to the next couple of days until the participants have real experience struggling with the tools and process. Most of the learning should be from the practices and on-time coaching from the course instructors. Same as all the other technical practices

 

Test-Driven Development

From day 2, all the code needs to be written by TDD. Same as described above, We will explain the philosophy very quickly with a simple exercise. Most of the learning should come from hands-on coaching and practicing.

 

Collaboration 

This part explains the fundamental techniques and practices that enable teams to collaborate in a Large-Scale Scrum situation. Including:

  • Working in teams 
  • SCM, Build Automation, and other tools
  • Pair Programming
  • Continuous Integration and CI Systems
  • Collective Code Ownership

The above is getting the participant ready to understand why things are happening in the way they are in Large-Scale Scrum.

 

Code Refactoring

This part covers the why, what, and how of code refactoring. We'll train people to have the nose to smell bad code and the techniques to remove the bad smells.

 

More on Test Automation

With both the automated acceptance test and unit test covered in the course, in this part, we go deeper into (automated) testing. Including:

  • Real testing/exploratory testing
  • Product-wise testing strategies
  • Good automated testing
  • Unit testing other programming languages

Thinking about Design

Here we discuss the difference between emergent design and the traditional design style that often happens in a waterfall process.

On top of that, we also talk about the design principles and paradigms.

Thinking about "real testing", again

Feature Teams

With all gained knowledge from the first four days, we will finally explore this organizational structure topic again and see the links between the technical practices and team approaching and feature teams.

 

Legacy Code

Based on the book by Michael Feathers, Working Effectively With Legacy Code, we discuss the way of working when the code is without good test coverage, and the knowledge about how the code works is lost.

 

Craftsmanship

We will discuss the alternative metaphor for software practitioners to map their careers and guide them.

 

Retrospectives

The training is over, the teams created in the course won't continue (usually). We will try to give people an experience of a good retrospective, learn to identify bad smells in a retrospective, and learn good techniques for running a retrospective. We will also cover how large organizations do retrospectives.

 

It's hard to document what we do in the course precisely. Because every time the teams will be working on different product backlog items and continue the product left by the previous class, many contents will be emergent.

Price: 3 500 SGD

Early Bird Price: 3 000 SGD (End Date: 2025-01-17)