Background.
This 5-day development practice course is 70% hands-on and 30% lecture and has three main focuses: Large-Scale Scrum, Technical Practices and Real Team Dynamics. It covers Scrum practices such as Cross-Team Sprint Planning, Backlog Refinement, working as a team and a lot of technical practices such as Test-Driven Development, Continuous Integration, Acceptance Test-Driven Development and Refactoring. It also covers how to apply these practices in a legacy codebase situation. This class will not tell you what to do or which framework to pick, rather, it will tell you how to think about transforming your organization.
The Training.
Format.
Day 1
Requirement workshop / A-TDD
Definition of Done
Cucumber and Friends
Sprint Plannings
Day 2
Test-Driven Development
Collaboration (Working in teams, SCM, Build Automation and other tools, Pair Programming, Continuous Integration and CI Systems, Collective Code Ownership)
Day 3
Code Smells & Refactoring
Thinking about test and test automation (Testing Pyramid, Mocking, Unit testing in other languages: JavaScript, Python, etc., Good Unit Testing
Day 4
Thinking about Design
Feature Team Revisit
Day 5
Working with Legacy Code
Craftsmanship
Retrospective
Further Details.
Product Backlog Refinement Workshop
In Large-Scale Scrum, the PBR workshop is one of the most important activities. By actually doing the workshop for our 1 week sprint with multiple teams, we will cover the 3 important aspects of this workshop: splitting big items, detailing the items and estimation. Some optional techniques we might cover based on the situation include: impact mapping, storying mapping, specification by example, estimation ceremonies, etc.
Sprint Planning
(Cross-team) Sprint Planning Part One is mostly 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
Explores how to drive the iteration with the examples derived from the PBR workshop. Detailed technical approach, good practices and conventions are discussed here.
The actual teaching or lecture is usually delayed to the next a couple of days until the participants had some 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 need to be written by TDD. Same as described above, the philosophy will be explained very quickly, most of the learning should come from hands-on coaching and practicing.
Collaboration
Explores the fundamental techniques and practices that enable teams to collaboration 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
This is getting ready for the participant to really understand why things are happening in the way they are in Large-Scale Scrum.
Code Refactoring
Explores the why, what and how of code refactoring. We’ll train people to have the nose to smell bad code and also 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
Explore the difference between emergent design and the traditional style of design that happens often in a waterfall process.
On top of that, we also talk about the design principles and paradigms.
Feature Teams
With all gained knowledge from the first 4 days, we 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 not maintained with good test coverage and the knowledge about how the code works is lost.
Craftsmanship
During this one of the final part where we discuss the alternative metaphor for software practitioners to map to their career and guide them.