With all of the choices available to software developers, it's easy to become overwhelmed not only by a problem but also by its many possible solutions. One approach that can help you and your team stay on track is to divide and conquer.
One good thing about software development today is that we have so many choices. There are so many platforms, operating systems, programming languages, frameworks, and tools. However, that can also be a bad thing. It’s easy to be overwhelmed by all the alternative solutions to a given problem.
Let’s say your team has decided to try what’s known variously as Accpetance Test-driven Development (ATTD), Specification by Example, Quadrant 2 tests, Behavior-driven Development (BDD), or other names. In other words, creating executable tests to help guide development based on customer examples of desired and undesired behavior. What’s the best approach? What tools or frameworks might you need? Should you do this at the API or service level? Can you do it at the GUI level? Efforts such as this generate so many questions that it’s easy to get that deer-in-the-headlights feeling and just give up before you start. The larger your team is, the harder it can be to make choices. I’ve been in many long meetings where several people held forth on different—and equally passionate—points of view.
When your team needs to solve a problem, it often works best to use a “divide-and-conquer” approach. Split into sub-teams, and have each small team try out its preferred solution for a set period of time. At the end of the time-box, each small team presents its approach. The whole team can discuss pros and cons of each sub-team’s approach and choose the solution it thinks will work best. Or, the whole team may decide to narrow down the selection to the best two or three choices, have each sub-team create a proof of concept, and have a “bake-off” to decide the “winner.”
Let’s say testing is getting squeezed to the end of each release. (Nobody has that problem, right?) You decide to have team members pair up for twenty minutes to brainstorm ways to prevent this. Each pair presents its ideas. One team proposes having each programmer pair up with a tester to do some acceptance testing before check-in. Another pair suggests limiting work-in-progress so that the team focuses on finishing one feature or user story at a time. A third pair recommends writing more acceptance tests before coding, so that the developers understand the feature better and delivered stories aren’t rejected so often.
This approach is similar to set-based development, a lean development method used by Toyota. Multiple teams work independently on design solutions, and these designs are evaluated and narrowed down over time until the final design emerges. It’s counterintuitive to have multiple teams work independently to solve the same problem, but this investment enables the best-possible solution in a given period of time. Choosing the wrong solution by trying to rush the selection process would result in much more waste in the long run.
Earlier this year, my team wanted to improve the user experience on our company’s website, and this involved creating more code on the client side of the browser. The GUI test tool we’d used for years couldn’t access events on the client side, and we didn’t want to release code that our automated regression tests didn’t support. We decided to use Selenium WebDriver to drive our tests through the browser, since it handled our Javascript code well. We wanted to write our test scripts using the Page Object pattern, but we had a hard time deciding which framework to use. We invested time over several months, during which various team members paired up to spike different frameworks, including a homegrown one. Each proof of concept took a few weeks, but that information was invaluable to finding a framework that was best for our needs. Choosing the right framework meant that we were able to quickly write efficient, easy-to-maintain test scripts.
That’s just one example of how a team can solve any problem with a divide-and-conquer approach. Any obstacle your team identifies in a retrospective is a candidate for having sub-teams dream up individual solutions and propose those solutions to the whole team, and then having the whole team try out the two or three solutions that seem best. You might even decide to try all of the good ideas that come out of your small-group brainstorming sessions!
