We run agile and work in iterative cycles. We prioritise building a long term stable software and make sure to include technical debt, and testing into our workflow.
Our work cycles can vary between a fortnightly sprint and daily sprint. Each sprint ends in a demonstration.
Make People Awesome
Deliver Value Continuousl
Experiment and Learn Rapidly
Make Safety a Priority
Extreme programming (XP) is a software development methodology which is intended to improve software quality and responsiveness to changing customer requirements. As a type of agile software development, it advocates frequent "releases" in short development cycles, which is intended to improve productivity and introduce checkpoints at which new customer requirements can be adopted. - Extreme Programming Wiki
Programming in pairs or doing extensive code review, unit testing of all code.
Avoiding programming of features until they are actually needed.
Have flat management structure.
Code should be simple and clear.
Expect changes in the customer's requirements as time passes and the problem is better understood.
Have frequent communication with the customer and among programmers.
Every morning, we get together as a team for 10 minutes at 10 AM.
We say what we did yesterday, what we're going to do today, and if anything is blocking us. We immediately resolve blockers or help the person after standup.
We do this in order to:
See each other face-to-face.
Learn what others are doing so you can help them.
Build accountability and trust.
Tools like Slack, GitHub, and Trello have made remote work much easier over the years, and we designed our company to have remote-first set-up.
Remote work is possible, but raises the degree of difficulty. One of the few requirements of Extreme Programming is that the customer is always available.
Ideally, that means face-to-face, on-site as much as possible for client relationships and internally within the team. Nothing beats in-person communication.
We use a lot of post-its. We found that that a physical Kanban board to be the most effective process for our team. Communication over tickets can occur inside github.
The kanban is reviewed every standup, retro, and planning session. Tickets are color coded, and labeled. We also manage tickets electronically using Zenhub and Github.
Find-out more about our kanban process and history here:
We use ProdPad to plan for the future. This is where epics can defined and prioritised into three columns. Highest priority sits at the top of each column and decreases vertically.
Well Specced and Designed epics
Well Specced and Designed epics.
Low Spec and Low Designed Epics
Epics are linked to Outcomes and are prioritized by value add and dependency hierarchy of the features involved.
Three-Amigos meetings are sometimes referred to as “Specification Workshops.” It is a meeting where the Designer presents requirements, designs, and test scenarios that make up a Feature Epic to the QA tester and developer. A three parties discuss the Epic and bring their different unique perspectives to the conversation.
All epics and features that are in current and near-term in our roadmap get designed and mocked-up based on research with domain experts. Designs get reviewed and then are approved. Once approved they are added to Zeplin. Designs that are located in Zeplin are reviewed during the Three-Amigos Meeting. It is our preference that tickets that are added to the Kanban are created from designed epics with a Three-Amigo's meeting that pulls a Designer, Developer, and Tester into the room.
We have retrospective meetings regularly to discuss what went well, what didn't go well, and what we can do differently over the next period.
Sometimes we hold these sessions fortnightly to mark the end of a fortnightly sprint. As our processes are always changing and growing, our retrospectives have also changed.
We now replace our Monday stand-up with a short 30 minute to 1 hour retrospective. This helps us guide the product planning meeting that follows the retro. The retro is an opportunity for the entire team to discuss achievements, hurdles, and concerns with the goal of everyone leaving excited and empowered for the week of work to come.
The facilitator runs this meeting.
Understand how the team feels about last week's progress and what's to come. Ask each team member from both internally and externally (the client), "How did you feel about last week? How do you feel coming into this week?" This is less a recap of the completed work (a better place being during daily standup) and more a pulse of how each person feels. Take notes.
Have each member of the team voice any risks or concerns; after everyone has had the opportunity to bring these up, work together as a group to mitigate these concerns. Encourage everyone to voice the same concerns even if they've already been mentioned; it helps prioritize what the team is most concerned about and should spend the most time fixing.
This is an opportunity to discuss how to improve the process and product we're building together. Note who had which concerns and track how we'll be addressing these concerns.
Celebrate success. Review the work that shipped last week, showing the actual product, and congratulate those who made it happen.
After the retro is done, share the notes with the team and ensure anything actionable from the retro is captured. This allows teammates to view progress, understand how feelings on the project change over time, and accomplish anything we set out to do given the outcomes of the retro. this also includes selecting a 'Build Boss' for the week.
Being able to ship code often is a large component of extreme programming and agile development. Our development operations and infrastructure supports regular release cycles of ~1 week. To do this we elect a person in the team to take responsibility for managing the release:
The 'build boss' is selected every week from within the team. They are responsible for QA cycle and releasing to staging for that week. This is a rotating role, build boss's are chose at random by pulling names out of a hat.