We like transparency. That’s why we shared with you what made us pick the technology we use. And that’s why we want to share as much of our workflow as possible. We base it on Agile development practices: Scrum, Kanban and Extreme programming, blended together, enhanced with ISO/IEC:25000 SQuaRE (Software Quality Requirements and Evaluation) and adjusted to our needs, team size and abilities. We were able to lower some requirements and keep the process smooth, because we are team in which all members are on equal rights and share common goal, thus we are self-motivated bunch.
We are big fans of iterative design and design by prototype. We work in short, time-constrained iterations, each starting with Iteration Meeting. In addition to single Product Manager role that does not change for whole project, at each meeting we elect Iteration Manager that takes care of given stage. During meeting whole team decides on the Iteration’s target and duration. It is Iteration Manager responsibility to make sure the team delivers a working product at end of iteration – whether it is prototype, final or maintenance release. We try to perform meetings in real life, but virtual conferences works just as well for us. We also hold weekly Process Meetings, where we sum up what obstacles we hit and discuss how to avoid them. The moment given project becomes public, we will inform all our users about our current iteration’s goal, duration and manager on Twitter. We do so even if project isn’t open source, because we believe our clients deserve to know what we are up to.
The Board proudly stand at hearth of our workflow. Each project has its own board with categories: Product Backlog, Iteration Backlog, Research, Development, Evaluation and Done. Each task is represented by card placed in given category, the higher it is, the higher priority. For the first two-thirds of iteration duration, we use classical Kanban pull based method, where we freely migrate cards between categories – with single aim in mind, to deliver all required features in time. Like always for Kanban, the only limitation is on number of cards in each category, which we adjust for each iteration on our meetings based on experience from finished iteration. After two-thirds of duration we perform triage, we evaluate each card we work or planned to work on if it is viable for current iteration, or should be postponed for future iteration and moved to Product Backlog. From this point we are at Feature Freeze, trying to get rid of all cards in Iteration Backlog. We use a great tool called Trello. Some team members even uses this for other, personal, more real-life-oriented planning. We can really recommend it (by the way, if you sign up using this link, we get nothing more than ability to give more treats to husky Taco, the Trello mascot that actually IS real – we want to feed Taco some treats, so we encourage you to give it a try)!
We also try to adopt as many ideas from Extreme programming as we can. We are especially concentrating on applying test driven development. While it is easy to apply ten of twelve Extreme programming rules, we had to make exceptions for two. Instead of pair programming, we use obligatory code review. Also, instead of having client constantly available for contact with team, we contact with consultants selected from target audience in between every two iterations. This is because we are small team, that is scattered. We do not work in single office, nor at same hours. This forced on us some modifications to the process, so it could be performed in more distributed manner. Bitbucket helps a lot with all of this.