How we manage our development process at Qandidate.com

At Qandidate.com we tried a lot of different project management tools and techniques. After two years of experimenting I want to share our current process, seen from my role as product owner (PO). One reason for sharing this, is to help you improve your process, but the most important reason is to start a discussion with you based on your experience, to improve our process even more. Our main rule at Qandidate.com is to embrace change. Always be open for changes that may or may not improve your process. If a change improves the process it’s a win. If you didn’t try it you will never know!

Our process

Our process is very simple. We are continuously building and delivering stories. Every two weeks we have a demo, immediately followed by a stakeholders meeting, where we give the stakeholders the opportunity to shift focus. The period from demo to demo we call a sprint. A term we borrowed from Scrum.

The most important element of our process, is that we only decide on the focus of next sprint, but never give a commitment on the amount of work which we’ll conduct. Obviously you’re wondering how we can get away without any commitments:

First of all, we keep our stakeholders very involved. We are fully accountable for the work we did in a sprint and we use the demo to show the stakeholders what we have achieved during the sprint.
We design and build our products in such a way that we can deploy at any time. Sometimes our marketing department wants to bundle new features and have a campaign around it. If so, we toggle features off, using feature toggles and switch them on when the marketing team is ready with the go to market.
We provide the stakeholders an opportunity to respond to changes in the market. They are allowed to turn the focus 180 degrees every two weeks.

Demo and stakeholders meeting

Our group of stakeholders represent the different domains in our organisation, such as marketing, sales and operations. Every two weeks we have a demo directly followed by a stakeholders meeting.

In the demo we just demonstrate the stories we have completed during the two week sprint period. Because we just demonstrate the stories we have completed, we don’t get in dead-line mode the days before the demo. This way we don’t take shortcuts to deliver a promised feature.

The stakeholder meeting is attended by the stakeholder group, the tech lead and the product owner. The meeting has two very important goals:

Give feedback on the Demo.
Decide the focus of the upcoming sprint.

The type of feedback we can receive in this meeting can vary from “I want the font size 1 pixel smaller” to “I love the way you decide to handle the user input validation errors”. All the feedback is discussed and when agreed on transformed into new stories for the upcoming sprint.

This meeting ends with the decision on the (new) focus for the upcoming sprint. The team, chaired by the product owner, receives the new objectives. Important to note is that these objectives are not detailed at all. We just build. Then we use the demo to show what we have came up with. It is a lot easier to discuss about how something should work when you already have something to show.

Stories

We call our units of work a story. When we are running low on stories, the product owner gets back to the initial focus for this sprint and plans an ad-hoc meeting with entire team to break down (new) topics into stories. We often call these meetings piano meetings, because these meetings often take place around our piano.

We write stories in the following format:

“As a recruiter I want to be able to download the CV of a candidate”

In this way it's immediately clear who the actor is, what he wants and what the business value is. Some tasks are hard to describe in a story, do not attempt to force everything in a story. Sometimes it's better to just describe tasks only with keywords. The goal is to getting the work done, not to write stories!

When implementing a story we keep minimal scope in mind. Always try to do the minimal to achieve what the story intents. Of course this does not mean you should not write any tests or “write quick and dirty code”! We test everything - since we use AngularJS even the front-end code is tested. We just don’t want to go in too much detail. We can fine-tune the feature by adding other stories to add more detail, if a feature has proven its value.

Conclusion

Our team is almost self-managing and we have gained a lot of trust from our stakeholders. These are, in my opinion, the most important success factors for the way we work today.. To assure quality, we have split the “building” process in six main phases. I will tell you more about this in my next post when I explain how our Kanban process works on a day to day basis.

For now I hope you’ve enjoyed this blog and hopefully this has given you some thoughts on how you could improve your own process.