Proposal-led Development for Driving Innovation

Our processes at Unruly are frequently in flux — changing to suit the needs of the Product Development team, or re-aligning to fit the current aims of the business. This affords us great power to apply our resources where they are most needed, but requires careful thought and reflection on whether an approach is effective.

Regardless of approach, we always aim to support developer ownership of pieces of work, for reasons of personal development and engagement.

One such approach we’ve trialled, to success, is driving innovation through proposals — one of the team has an idea (a response to a problem, or an opportunity), and is encouraged to formalise it as a proposal to the rest of the team, outlining the idea and pros/cons.

Below is an example, where one of my team proposed a method for improving our test-coverage of shell scripts. These proposals don’t have a strict template, but are encouraged to include several standard points.

  • A brief statement of a problem or opportunity.
Our current chosen tool for testing Bash scripts is BATS (the Bash Automated Testing System) which is being used in a few places. It’s OK but leaves a lot to be desired compared to the mature testing tools we’re familiar with in the Java and Javascript ecosystems, for example.
  • The proposal of work that could be done.
These could all be packaged into a single RPM, hosted on Artifactory, and installed across all workstations, providing a consistent, full-featured set of tools for developers to test their Bash scripts.
Supporting documentation (on our wiki, for example) would also be needed for those new to BATS to get started and understand what features are available.
  • How it tackles the problem or takes advantage of the opportunity
Dependencies can be mocked out and their behaviour verified by tests, making it easier to retrofit a test suite onto an existing Bash script. With that in place, the script can be safely refactored to make it easier to test and make changes.
Having this full-featured set of tools for Bash testing available on all workstations, with supporting documentation of how to use it, greatly lowers the barrier to entry of developers wanting to test their Bash scripts.

These proposals can be circulated within the team, discussed, fine-tuned and finally proposed as stories to work on. The above example has been turned into a story and is in our queue of tactical work right now.

We’re finding this approach successful at developing our team, sharing knowledge, encouraging ownership and pride in the products we’re creating.

And of course, we are hiring. :)