Based on my experiences building high performance engineering teams, this presentation focuses on the technical practices required. These practices centers around automation (build, test and deployment) and increased collaboration between Engineering and QA (TDD, exploratory testing, prioritization, feedback cycles).

1. High Performance Engineering Teams
The Technical Practices
Lars Thorup
ZeaLake Software Consulting
October 18, 2011

2. Who is Lars Thorup?
● Managing software
development
● 10 years of agile practices
● 15 years of automated testing
● Introducing agile and
automated testing with clients
● Assessing software projects
and companies
● Founder of 2 agile consulting
companies
● 12+ senior consultants
● 10+ years

3. What is a High Performing Team?
● Short time from getting idea
to going live
● weeks instead of months or
more
● Faster development
● Higher quality
● Lots of experience from
industry how to accomplish
this

4. How to become faster?
● Stop doing non-productive things!
● Manual regression testing
● Bug hunting and debugging
● Implementing more than required
● Out-of-date documentation
● Piling up bug reports
● Rediscovering of knowledge
● Working on stuff not in the value stream

5. How to increase quality?
● Test more thoroughly
● Test more often
● Test cheaper

6. Automate!
● Software companies tell
their clients to automate to
increase productivity and
quality
● This advice also applies to
the software development
itself!

7. Shorten the feedback cycle
● Automate testing
● from weeks to minutes
● Close collaboration between Engineering and QA
● from weeks to hours

8. Don't track bugs - fix them!
● Real bugs are always top priority
● Fix before working on anything on the backlog
● Decide if an issue is a real bug or an (unwanted) feature
● Prioritize (unwanted) features into the backlog
● Purge your backlog

9. Automate the build
● Compile code and installers ● Have a visible dashboard to
show status
● Run tests
● on every commit ● Notify about broken builds
● Top-top priority
● Deploy to internal servers ● "Stop the line"
and production ● How can we prevent this type
● at the push of a button of break in the future?

10. Automate the testing
● Unit tests
● Is the code doing things right?
● Test one piece of code in isolation
● Acceptance tests
● Is the code doing the right things?
● Test the integration of all layers of
code

11. Automated unit testing
● Use a unit testing ● Track coverage for new
framework for each code
programming platform you ● Aim for 75%
use ● ... and more for important code
● Java: JUnit ● Include on the dashboard
● C++: UnitTest++, Google Test
● JavaScript: Jasmine, QUnit
● SQL: Probably JUnit

12. Automated acceptance testing
● Test through the UI if you must
● ...as little as reasonably possible
● Test just below the UI if you can
● Use your existing unit testing framework
● Consider an acceptance testing framework
● like Cucumber

13. Test Driven Development
● Write tests before writing the code to make them pass
● Not a testing technique!
● but a design technique
● Makes it easy to write tests
● keeping coverage high
● Makes the design flexible
● Improves communication between Engineering and QA
● Speeds up development

14. Continuous integration - Continuous delivery
● Each commit to the version control system
● triggers an automated build
● triggers an automated deployment
● Expect developers to commit several times a day

15. Collaboration between Engineering and QA
● QA can test the code as soon as possible
● Before it is written
● TDD collaboration
● Write automated acceptance tests
● Just after it is written (same day)
● Continuous Delivery makes it available
● Exploratory testing
● Scenarios the developer didn't think about
● Make this step part of "done" for stories
● Don't keep a large backlog of untested stories
● Engineering can help QA on testing if required

16. But: what about legacy code?
● Add pinning tests
● special kinds of unit tests for legacy
code
● verifies existing behaviour
● acts as a safety net
● Can be driven by change requests
● Refactor the code to be able to write
unit tests
● Add unit test for the change request
● Track coverage trend for existing
code
● and make sure it grows

17. But: "we can't change the company this much"
● Yes you can! ● It requires
● Enthusiasm
● Others have done it before ● Support
you ● Willingness to invest
● Transparency

18. But: <your question here>

19. References
● "Continuous Delivery: Reliable Software Releases through
Build, Test, and Deployment Automation" by Jez Humble
and David Farley
● Local software companies following these practices with
success
● Wealthfront, Palo Alto
● IMVU, Mountain View
● Salesforce, San Francisco
● Pivotal Labs, San Francisco
● ...