Our Agile lifestyle – shipping working software every sprint

Agile – a mindset, lifestyle and methodology

The business world moves fast, so we operate with Lean and Agile approaches to stay ahead. Agile provides a different way to work:

  • No silos; business stakeholders and developers are all on the same team
  • Bite off small pieces, building all needed tech at the same time
  • Deliver a working increment of software every two weeks
  • Stakeholders see their product come to life in near real time

Rather than large up-front requirements documents, we establish a roadmap and then at the beginning of each sprint ask “what is the most important thing, now?”

Mercury teams – self-contained and multi-talented

In addition to being stocked with seasoned professionals, our Agile teams are formed with all the technical disciplines needed to deliver software.  This tactical team structure enables us to deliver working software with short feedback loops.

  • At the end of each sprint the team showcases the sprint’s delivered software in an interactive “Sprint Review” session
  • While presenting the delivered work, the team solicits feedback and/or new ideas and approaches to better solve the business problem at hand
  • With this inspection ceremony, the team is always righting the ship based on prevailing current, winds and destination

We don’t just “meet” – we hold ceremonies

Backlog Refinement

The “What” of an Agile sprint where the team hones in on the next increment of work:

  • Every two weeks Stakeholders, Product Owners and team engineers dive deep into the Product Backlog
  • The players discuss intended outcomes, user behavior, workstreams and set priorities
  • With backlog refinement, all players will always know what’s on-deck and ensure we’re delivering the right things at the right time

Sprint Planning

The “How” of an Agile sprint where the team commits to the next increment of delivered software:

  • Each sprint starts with the team breaking down product features into smaller estimated slivers of work known as user stories
  • Based on the planned sprint the team can define their capacity – the increment of working software they can accomplish over a two-week sprint
  • Based on team bandwidth and the refined sprint, the team commits to a body of work for that sprint