We practice a certain flavor of Agile known as Agile XP.

We advocate frequent release of working software. Sometimes the hardest thing to put into practice for larger companies is pushing code continuously. We use continuous integration, do test driven development, and try to deliver something that has business value to actual customers as often as possible. We have weekly iteration planning meetings, where developers, product managers, designers, and the project owner (usually from the client’s side) come together to plan the work for the week. It’s an open, collaborative discussion to identify what the highest value work is and estimate each unit of work. We’re pragmatic about pair programming and leave it up to individuals to decide. Most of the people here have had 8+ years of experience in the industry, so we trust each other to reach out for a pair when needed. Some people pair all the time, some less than that, but everyone pairs some of the time. At the end of the week, we do a demo as well as a retrospective (with everyone from our team and from the client) to go over what went well and what didn’t go well this last week.

Our engineering practice uses a type of Agile software development called Extreme Programming (XP).

XP means we practice pairing and test-driven development while incorporating daily project standups and regular retrospectives to gauge project process. We find that XP is most effective given the nature of our client work, and we value close partnerships with our clients as well.

We use Trello as our Kanban board.

We work in sprints and a sprint of work for our developers typically lasts between 1 and 2 weeks. With our larger projects, we have a daily call with the customer which acts as an opportunity to raise any concerns or issues. With smaller projects we prefer a call or meeting with the customer at the start of the sprint and only arrange other calls as required.

We understand that software development projects are often difficult to specify in their entirety at the outset. Our agile software development processes accommodate the unknown, providing flexibility without sacrificing speed and quality of delivery. We work with customers from the outset to define the high level vision for their development project, and what they hope to achieve. We then perform multiple sprints of development – making changes to requirements following each sprint as required.

Our customers love the transparency and control this provides them.

We’re a small but mighty team.

For the first half of our existence we only had five or six engineers. In fact, we were only three engineers when we built version 1.0 of our software. We literally had to function in an agile way or we wouldn’t have survived, and that remains true today. It’s important that we pick problems, and quickly deploy software to test our hypotheses. This is partially due to the fact that executive buy-in and stakeholder feedback inherently requires agile functioning. We’re a fraction of the size of other teams building electronic health records (EHRs) and that’s only possible because we embrace the idea that perfect should never be the enemy of good. We’re deliberate about the problems we work on and iterate efficiently.

Every team decides whether to use use Kanban or Scrum when given a new project.

We have Agile coaches who facilitate bi-weekly retrospectives and planning, and teams have a daily stand-up with the product owner. Every project starts with a minimum of two developers and ~90% of work is done with pair programming. We sit down together as a team regularly for code reviews. People show each other code that was complicated to write and discuss any code that the authors are unsure of or have questions about. The team provides feedback, which the authors can later incorporate in improving their solution.

Project teams usually decide on their own which development and management strategies they want to use for their current project.

This also depends a bit on the customer. In some projects, the customer is part of the scrum team, in some projects we use agile processes internally, but do not expose them to the client. We have never followed scrum or kanban practices by the book, but mostly adapted those ideas to match our needs (and company size).