Culture Comes First

Do you have a favorite project you have worked on? Mine was the redesign and re-platform of www.topgear.com. It was a great project because the culture came first. Before Scrum team hiring started, myself and my Product Manager influenced a desired culture based on project constraints, workflows and our profile.

From day one, the intention was to hire Scrum team members that were intelligent, adaptable, energetic and had integrity. The team ultimately creates the culture.. It is a combination of energy, personalities, interests and skills.

To assess candidates, we practised different interview formats. Sometimes open seating areas helped us gauge ability to focus and listen. On another occasion, a digital agency candidate and his boss sat in the same room. It was an awkward setup that proved very valuable to measure candidate’s adaptability. Similarly, we wanted to target personality match to efficiently progress through growth stages and enjoy plenty of informal gatherings.

After 3 months of interviews, the 8 person Scrum team was created. It was a hybrid team composition taking the best skills from a design UXD agency and freelance developers. We assembled the best possible team. Quickly we focused on getting to know each other with the help of lunches or outside gatherings. Above all, we wanted to have fun and learn from each other.

Every day, the best solutions were reached with the help of multiple discussions that challenged different opinions. The goal was always to promote the best solution. Often, we all felt inclusive regardless of our core skills. For example, sometimes I would carry QA functional testing or feed UX advice to manage a variable project scope approach.

Aside from people culture, we also tackled process culture. Early in the project, we had to determine how to deploy the new site based on a desired build-measure-learn feedback loop. Historically, the business culture supported a big bang approach – a single release to the public. We proposed a stepwise Beta approach – multiple short-term releases only accessible to a percentage of our audience – before a final release to the public. Proposal was accepted on the back of a desired evolving new site after final release.

We also integrated external stakeholders into our workflow. The key approach was to win trust first by delivering business value fast. Once trust was achieved, why would stakeholders influence how we work if we are delivering? In order to win trust, we took the pragmatic approach of developing a circle of inclusion between the Scrum team and external stakeholders. We practiced dynamic feedback loops based on project and individual needs:

• Co-location
• End of day progress emails
• Evolving style guide
• Frequent releases
• Page PSDs

With the help of above bullet list and recurrent Sprint ceremonies (standups and Sprint Review), stakeholders stayed on top of daily fast changes and shared insights to be actioned during a Sprint. If feedback to the Scrum team was missed by a given deadline, the Scrum team made an executive decision. Finally, co-location during a Sprint greatly fostered integration and understanding of Scrum team workflows.

As we nurtured our culture, I quickly acknowledged we were being Agile (eg how we communicate) and not doing Agile (eg ceremonies). The following elements deserved our most attention:

• integration
• behavior
• motivation

Integration

Integration evolved around the principle that the Scrum team was always a united front. This principle was lead by myself and my Product Manager when communicating with the Scrum team and stakeholders. For example, often prior to Sprint Review, the Scrum team would discuss the agenda. In addition, the “One Team” theme was repeated endlessly to support a hybrid Scrum team composition and UXD agency stakeholders.

Behavior

Behavior management concentrated on mitigating the downfall of “conversation driven” development in a fast and changing environment. In general, we used little technical documentation because code base was of high quality and well documented. File name consistency across user stories, design and code quickly helped us create a new common language to support fast and short iterations.

Layout and mechanic of Scrum boards evolved. As development of site sections started to overlap in Sprints, we improved clarity of handover between Design and development. User story stickies had color coded markers to convey Design phase. We also posted permanently on walls wireframes to trigger functionality discussions. Site modules across all form factors were also printed and posted on walls to trigger design and branding consistency discussions.

Motivation

Everyone understood what we were trying to achieve and why. This drove motivation because we shared a common goal. It was amazing to realize how our processes and communication constantly evolved across our growth stages. Most importantly, we listened and acted upon how we wanted and needed to change.

When the weather permitted, we would have Sprint retrospectives on the roof terrace. Also, Sprint retrospective formats changed during our progression across growth stages. The first retrospectives were about understanding who we were, followed by how we work, and ended up in a free form format with no agenda.

Do you have culture examples to share?