background

Approach

Some notes on the approach to building ShowMS

Key to the success of ShowMS and the Freeform Digital Platform project has been an approach that empowered us to focus on building out the product with a high degree of momentum.

General Guiding Principles:

  • User focused design
  • Operational Efficiency
  • Opinionated
  • Holistic
  • Momentum is Key

From the start everyone involved in the project took a holistic view, consistently referencing not only what the front-end user experience would be but also the wider context of what it would take to manage and maintain the platform. This fed into several areas, including building out features to support marketing and other internal stakeholders.

At the heart of the ability to deliver has been the use of small, cross-functional teams with enough autonomy to self-organize and take ownership of the process – from product definition, UX and design right through development, deployment and operation.

A key to the success of the autonomous team model was combining it with oversight from a smaller core of experts with the power, knowledge, available bandwidth and experience to make important product and technical decisions quickly and efficiently, feeding them into the teams model.

The goal of the expert core was not to control and restrict but rather to ensure that key product directions were made available to the teams. An additional role of this group was to identify potential rabbit holes, dependencies or blockers and deal with them as efficiently as possible, before they could impact the project teams.

Teams Guiding Principle:

  • Small < 8 people
  • Cross-functional
  • Autonomous
  • Empowered
  • Self-organizing
  • Specialists available when required
  • Ability to make local decisions

From a project planning and development perspective we focused on an Agile methodology, although critically for us being Agile is much more important than an adherence to any singular flavor. While there are elements of Scrum we employed, we consistently asked whether the various rituals and processes were helping, or if they were getting in the way, and adjusted accordingly.

Agile Guiding Principles:

  • Principles > Practice
  • Being Agile > Scrum
  • Async communication by default
  • Limit meetings
  • Avoid rabbit holes

For us holding true to the Principles of Agile:

  • Individuals and interactions over processes and tools
  • Working software over comprehensive documentation
  • Customer collaboration over contract negotiation
  • Responding to change over following a plan

Are far more important than any particular practice. To that we’d add a relentless focus and awareness of momentum with regards to shaping, building, shipping and maintaining a quality product.

Moving beyond planning and development we ensured that the team had full exposure to the DevOps cycle:

image

Ensuring that they had the autonomy to take ownership of areas that are frequently silo-ed, in our experiece often becoming significant blockers and drags on project momentum.

Permissions and Access

  • Cloud Infrastructure - the team had access to, and could leverage as they required, Cloud Services and Infrastructure
  • Quality Assurance - QA was not an external function but rather an integrated part of the project teams
  • Release Management - All team members had full access to Continuous Integration and Deployment functions for non Production environments, and read-only access to Production
  • Monitoring - Monitoring via Azure, NewRelic and various other services was available to the project team meaning they could proactively responds to data, as well as see the impact (and feel the pain!) of bugs and issues more clearly
  • Access to Analytics - Behavioral analytics were available to the full team, allowing them to make decisions based on data rather than having to ask for research

Some other DevOps related notes:

  • Git – Code repository per main component
  • GitFlow – Source control strategy
  • Build and Testing – Build scripts and automated tests run on every commit across all components
  • CI/CD – Leverage Continuous Integration and Continuous Deployment
  • Environments – Dev, Staging, QA and Prod
  • QA – team has internal QA to support Release Management
  • Monitoring – Monitoring of Prod environment to proactively identify issues and be aware of any outages
  • Sustainment – Team and process in place to support long term
  • Messaging and Support – Internal documentation highlighting new releases and providing guidance on use