The first non keynote session I attended was a case study of failing a TDD rollout by Chris Edwards.
Learning Outcomes:
- Pitfalls of a top-down approach to changing technical practices
- Basic concepts of Lean-Change
- How to grow technical skills across a larger group without micromanaging
Background, Chris was working at a company that was brand new to agile.
- They had approximately 50 Dev and QA’s
- Wrote software in C++.
- Had no culture of unit testing.
Their release cycle was.
- 3 Month release cycle
- 2 Months of development
- 1 week feature freeze (bug fixes only) 1 month code freeze (critical fixes only)
They began to implement scrum and went to…
- 2 week sprints
- Testing part of Definition of Done
- Faced Cultural resistance to eliminating 1 month code- freeze
The decision they made was to automate manual tests with automated GUI tests and put their entire focus automating the backlog. This is what resulted…
- At that current pace it would take 2.5 years to fully automated the backlog with UI tests.
- QA spent 50-75% of their time maintaining the current automated test cases.
- The rate of escaped defects had not gone down at All and the rate of crashes was trending up
They had created the ice cream cone of testing ANTI PATTERN!
They decided to introduce TDD to the company through training and setting up a community of practice.
Six months later the adoption rate was only 10%. They had a minimal defect rate change and still a 1 month code freeze before release. They analyzed why the adoption rate was so low and came up with these challenges…
“We don’thave time to learn”
'We don’t have to to do TDD in our sprints"
“The business will never agree to this”
“Works great for new code but we work in legacy code”
So Chris came up with a theory that TDD has a steep learning curve and that the benefits of TDD won’t be seen for a while. People need to give it an honest chance to see the benefits so lets ask everyone to do it!
In comes the mandate: EVERYONE MUST DO TDD!
In reality what was actually mandated: EVERYONE MUST WRITE ONE UNIT TESTS PER STORY OR BUG.
For those of you how are familiar with TDD you know that is NOT TDD but that is what was mandated.
So what happened?
People started to write unit tests that did absolutely nothing.
A Civil war started to break out between the dogmatists and the pragmatists.
So what happened?
FAILURE!
Here is how they fixed it…
- Hired an expert to come sit with the teams and code with them teaching them how to do real TDD including refactoring skills.
- Focused on SOLID design principles and used those as guidelines for refactoring. http://butunclebob.com/ArticleS.UncleBob.PrinciplesOfOod
- Allocated time for learning in every sprint mandatory.
Guess what happened?
- The teams ended up being much more productive
- Defect rate and code quality was measurably improved.
- TDD adoption rate went WAY up across the organization over time. This was helped by dynamic re-teaming of people who were getting good at TDD.
Remember TDD IS NOT THE GOAL! (Neither is Agile for that matter)
To get in touch with the speaker here is his info…
