Practical Agile — The productOps Way
productOps is privileged to have an experienced leadership team. Many of them remember when the Agile Manifesto was first published, and it evoked mixed feelings.
It was like someone had written down what they had already been doing for a long time. Seventeen years on, how do the leaders of productOps, who have seen it all, apply the principles behind the Agile Manifesto? Below is an excerpt from “The productOps Way”, an employee and client handbook, by Dean Pfutzenreuter productOps cofounder and CTO.
The productOps approach to agile is simple yet nuanced. Our success lies more in the ethos than any process. Agile is a framework. A set of guidelines to be followed in order to enhance project delivery. What our brand of Agile is may be arguably less important than what it is not. Our Agile is never “in the way”.
productOps Agile IS
- About showing the team’s work constantly with product demos
- Based on bringing the system up quickly and keeping it up and running for stakeholders to see
- A mechanism for the client to collaborate and provide feedback
- A way to get the client to actively participate and own the deliverables
- A method for a team to rapidly respond to change
- A way for the entire team to collaborate and work together
- A way to prioritize the most important work for the client
- A way to eliminate superfluous work items
- A way to start development without knowing everything up front
productOps Agile IS NOT
- An excuse to avoid estimating
- An excuse to ignore milestones (“it will be done when it’s done” is NEVER OK to say to a client)
- An excuse to not plan
- An excuse for “I told you so”
- An excuse for constant feature creep
- A rigid set of “best practices” or “processes” that must always be followed
- An excuse to not document things
- A shield to hide behind failure
What does this mean in practical terms for the way we conduct ourselves from one day to the next?
It means building a durable team, one where the entire team is committed, and most typically in the same location. We engage in daily stand-ups which include each team member’s update on work completed yesterday, work expected to be done today and any roadblocks that need clearing. Biweekly sprints typically include a sprint planning meeting where tickets are assigned to resources and points assigned to those tickets (we use Fibonacci scale) and a commitment from the whole team is garnered. User stories and tasks are monitored in a tracking system (e.g. Pivotal Tracker or JIRA). We use PatternLab as a repository for front end resources and patterns.
We also believe in constant deployment and we always show our work at the end of each sprint. We demo to product owners and stakeholders to both engage them and gather feedback. If they are not available, developers and designers demo to each other. Once something is up and running it remains up and running and available for demo by others. This serves a number of purposes but mainly allows anyone in either the clients organization or at productOps to see and better understand progress and direction.
By using agile as a framework, and not as a crutch, we’ve been able to deliver for our clients while working to tight and seemingly unrealistic timelines.
