How we do agile software development
We follow an agile software development process that has been refined over more than 17 years of delivering enterprise projects. This article describes how we work, from initial planning through to production deployment.
Stories and bug fixes
The business, usually through a single product manager, is primarily responsible for writing new stories. The content should be enough for the author to remember what they were talking about when asked for details later. Once a story comes up in the work cycle, the delivery team works with the relevant stakeholders to ask questions, work through concrete examples, and produce a design if needed. These conversations highlight the reason for the feature and serve as a strong motivator for the delivery team.
Prioritization
The product manager owns the backlog and sets priorities. The delivery team provides effort estimates to inform those decisions, but the product manager decides what gets built next. This keeps the team focused on business value rather than technical preference.
Iterations
We work in two-week sprints. At the start of each sprint the team reviews the top items in the backlog, confirms the scope, and commits to a set of stories for that iteration. At the end of each sprint we demonstrate working software to stakeholders. There are no surprises at the end of a long project because stakeholders see progress every two weeks.
Tracking work
We use a Kanban-style board to track stories through their stages: ready, in progress, in review, done. Stories do not move to done until they have passed code review and automated testing. This keeps the definition of done consistent and prevents half-finished work from accumulating.
Code review
Every change goes through peer code review before it is merged. Code review is not about catching bugs, though it does that. It is about knowledge sharing, maintaining consistency across the codebase, and catching design problems before they are expensive to fix.
Automated testing
We write automated tests for business logic and integration points. The goal is not 100% coverage for its own sake. The goal is a test suite that gives the team confidence to make changes quickly without breaking existing behavior.
Deployment
We use CI-CD pipelines so that every merge to the main branch triggers an automated build and deployment to the development environment. Releases to production are a deliberate decision, not a manual process. This reduces deployment risk and keeps environments consistent.
What this means for you
You see working software at the end of every two-week sprint. You can change priorities between sprints. You know exactly what was delivered and what it cost. There are no long periods of silence followed by a big reveal.
Contact us to learn more about how we work, or see our agile DevOps automations service for how we apply these practices to DevOps and pipeline work.
