Monki Gras

Last week was Monki Gras, the conference organised by RedMonk, with this year’s theme being “scaling craft”.

We plan to explore Craft that helps scale Technology, or Technology that helps scale Craft. What are the limits of a craft-based approach? Does quality have to suffer as businesses scale? James Governor http://redmonk.com/jgovernor/2013/01/07/scaling-craft-tech-and-beer-monki-gras-conference-2013/

Held over two days in London’s Conway Hall, there was an incredible line-up of speakers, social events and evening activities.

Talks were on a diverse range of topics, from best practices for scaling virtual teams to printing your own steam train. Here are my notes on those I found most interesting (or, more likely, remembered to write something down…).

Rafe Colburn - “Artisan Software Manufacture”

Rafe started his talk by defining characteristics associated with craft and mass production, which are normally held up as polar opposites. Traditionally, craft became a byword for quality, whereas mass production signalled consistency and resilience. Combining aspects from both domains will often lead to the best results.

Consider Apple’s tag line these days, designed in California, produced in China, craft and mass production.

When running an engineering team at Etsy, Rafe detailed the best practices they used to ensure they shipped high quality software.

• Measure and monitor everything - This spans all areas of engineering from user request metrics produced by the site, application errors generated and enormous A/B testing, etc.

• Automate repeatable processes - New developer can be set-up straight away due to their use of VMs, allowing them to start shipping straight away. Continuous integration and automated deployment were core principles of their engineering set-up.

• Growing Craftmanship - Etsy encouraged “craftmanship” as a culture internally through activities such as regular code reviews, annual bootcamps to shift developers between different teams, scheduled “bug rotations” to mix developers together to tackle the bug queue and code reading clubs, where developers review open-source software together.

Finally, spend the time saved on the most important aspect of software development, your employees and keeping them happy.

Phil Gilbert - “Design Thinking at IBM”

IBM’s CEO, Ginni Rometty, recently announced a new division to lead design across the entire company, cutting through the individual brands and products, transforming IBM into a design-led company.

With close to 480,000 employees, this is a herculean task and Phil Gilbert has been put in charge. Phil previously led the effort to consolidate IBM’s BPM portfolio down from nearly twenty products to only four.

His team has developed a new framework to deliver “design-led thinking” throughout IBM, rather than a formulaic set of policies and procedures to enforce design from top-down.

Using the military analogy of Commander’s intent , the goal was to empower product teams within IBM to embrace design-led thinking, rather than appearing as “just another corporate diktat”.

Key building blocks in the framework were…

• Lead Users - Continual and regular engagement with intended consumers straight from the design phase.

• Release Hills - Used to split design and development effort into achievable iterations.

• Metrics - Provide visibility around objective operational data.

• Wiki-based Release BluePrint - Used as source of truth within project, peer-reviewed artifacts, shared between consumers.

Full details about this new initiative can be found on the IBM Design site.

Steve Citron-Pousty - “Ecosystem management brings the science to scaling”

Steve knows a thing or two about “ecosystems”, working as a developer advocate for Red Hat and having a PhD in Ecology.

Drawing on his past experience from academia, Steve talked about using lessons learned from real ecosystem management, specifically Yellowstone Natural Park, to enable more effective developer outreach programmes.

Ecosystems experiments come in different forms, natural (let’s observe the effects of a natural disaster) and planned (let’s introduce a new species), choosing the right experiment type can greatly improve the results.

Add monitoring to your ecosystem experiments, e.g. A/B testing on click-through rates for email marketing, allowing you to perform statistical analysis to quantatively assess the outcomes.

Donnie Berkholz - “What Data Scientist Can Learn From DevOps”

Donnie Berkholz, analyst at Redmonk, was previous a biological researcher working on drug discovery. His talk expanded from this article about how data scientists could benefit from applying “engineering culture”.

The main theme was that traditional statisticians come from a world built with custom scripts using R, hand-written log books and manual analysis. As “data scientists” merge this existing world with better technologies there was an enormous amount of “best practices” from software engineering that could be applied with great success.

Concrete suggestions included source control for artifacts, continuous testing for code and data, online collaboration using wikis and engineering for scale.

Slides for the talk are available here.

Shanley Kane - “Scaling Product Management”

Shanley compared [Dante’s Inferno](http://en.wikipedia.org/wiki/Inferno_(Dante)) to Product Management, using the nine circles of Hell as metaphors for common issues and providing solutions from Paradiso and the spheres of Heaven.

• Fraud - Roadmaps are arbitrary documents with timelines and feature. Premature decision making that encourages death marches. Remove road maps and collaborate on living “working what are working on” document.

• Greed - You can’t do everything you want (within a fixed time period). Shanley’s heuristic says, “take what you want to do, divide it by four, take the original time you think you need and double it”.

• Gluttony - Stop using “all the tools”. Perfect tools don’t exist, lower your expectations and standardise across teams.

• Limbo - Technical debt hinder progress, grows over time. Stop hiding it away, acknowledge it and plan to resolve it.

• Anger - Continually dismissing peoples’ opinions leads to distrust and resentment. Create culture of discussion, including trade-offs and whys. Include other departments apart from engineering.

Tim Webb - “Tips & tricks, and tools from a company that’s never had a headquarters.”

Tim’s talked about scaling remote-working teams and how his company makes it work.

Setting expectations was key to successful collaboration, how available are people supposed to be during core working hours?

Remote working can be successful but you can’t ignore physical distances, having a team with employees in Latin America, United Kingdom and China makes it difficult to even schedule a conference call.

Use tools a variety of tools, from Google Hangouts to Skype, to encourage collaboration. Default to “over-sharing” to ensure everybody stays in touch.

Ted Nyman - “Scaling Happiness”

Github has now grown to over 140 employees but still hasn’t employed a formal manager.

Rather than having a hierarchical organisational, with managers dictating strategy and direction, Github’s engineer’s work on what they find most interesting and progress happens through consensus and discussion.

Ted spoke about “freedom perks”, calling out companies who use excessive benefits, e.g. free food, rather than engaging work to hold onto employees.

Authenticity and autonomy are key to happiness for employees.

Github’s lack of a formal structure creates a culture which embraces disorder, tolerates mistakes and lets teams form naturally. This culture eventually reinforces the original structure.

Slides are available here.

I’m looking forward to next year already…

Finally, thanks to James Governor and the rest of the organisers for putting on a fantastic event. It must have taken an enormous amount of effort to pull off a high-quality event on this scale.