One of the most important aspects of agile is to notice your problems and solve them. How? A good strategy is to look what others did. In “How To Do Kick-Ass Software Development,” Sven Peters shares his experience with “Kick-Ass Software Development at Atlassian” (slides on slideshare, video on vimeo). Yes, he have the talk wearing the “Kick-Ass Super Hero Costume“.
A short refresher what agile aims to be (slide 12):
- better software
- less overhead
- faster development
- happy customer
- happy developers
This only works when you continuously improve. Legacy teams, can you hear me?
But before we can start: How do we know we build the right thing? Bad example: The Microsoft Kin. Never heard of it? They sunk about $1 billion in the project. Makes you wonder how you could miss it, right? (slide 25)
Better solution: Fake it. IBM made extensive experiments with a state-of-the-art speech-to-text system before starting development. How did they do it? They hired an extremely fast typist who remote-controlled word. Cost? Negligible. Result? Text-to-speech won’t sell – people can’t edit the text fast enough using words, they are hoarse after eight hours and the whole thing really breaks down in an open office space. (slide 27)
Use paper prototypes. Something geeks eventually forget: You can drag a piece of paper over a (wooden) desktop just like a window over a screen. (slide 28)
Quick and easy feedback: Easy to find, simple, fast to submit (slide 32). Customers love it! But remember to protect your developers. Gmail uses the “Sh*t umbrella” (slide 38). But not everyone is Google. Put each developer into a support seat once in a while. Not only can they solve problems much more quickly, they also learn to look at their work from the customer perspective (slide 42).
In most companies, there are way more developers than testers. Atlassian has a ratio of about 13:1. This creates bottlenecks and issues with accountability and scalability (slide 46).
Solutions: Dev X tests features of other devs. (slide 49)
Use “DoTing” – Developers on Test (slides 50 -56):
- Give developers the same training QA receives
- Pair testers with devs
- “Blitz Test” – Once in a while, invite everyone in the company to try the product
- Use test recipes
- Split sessions (1 dev and 1 QA test the same feature independently)
- Bug Hunter (have someone try really hard to break the app)
Remember “Quality is everybody’s responsibility.” (slide 57)
At the Jazoon, the slides about design were skipped due to time constraints.
Again: Department barriers slow you down. Work together as one team! Keep improving! (slide 69, see also: WIKISPEED in “Test First Saves The World”)
The lonesome cowboy coder is a relic but teams always mean trouble. Interesting video of a heavy-traffic crossing without signals on slide 73. “Traffic Rules protect us from accidents” -> “Development Rules are protecting us from making mistakes”. Like we need a concurrency library in our preferred language, we need a “Fast + Simple Workflow For Parallel Coding.” Otherwise we will be slow and some people will enable their “god mode.” (slide 77)
DVCS make this simple. Create a branch for every task (slide 78). They should have short lives (2 days).
“Pull Requests can improve your code quality” (slide 80). This helps to spread knowledge. But keep an eye on the blame game!
Everyone in the same room would be great but it’s not always possible: People travel. You really want to pull some experts two weeks out of his family? (slide 85) Ask yourself: “Where do I work best?” The answer often is: It depends (slide 86). Make sure people can stay in the zone when they have to.
Make sure you can communicate effectively (slide 87). Emails look great (slide 88) but they cause problems (slide 90). Try chat. Invent your own Portal Device.
Most importantly: Remove friction!
Developers automate everything for everyone else. Spend some time each week to automate a menial/manual task for them (slide 101).
4 steps to tame monster builds (slide 104-110):
- Instead of having everyone build everything, pass the artifact
- Run your tests in parallel. They are independent of each other as they should be, right?
- Have a build strategy. How often do you build what part?
- Make your stats visible. Use wallboards, information rediators.
Automatically disable flacky tests (113). Use SonarQube and similar tools to detect problematic code. Use Freud to find your own anti-patterns (115).
Remember managers are also humans (123).
Share stories of success and failure (124).
Remember: To be awesome, you have to step out of your comfort zone (126)