Methodology and Processes are tools to support the project – not the other way around!

We favour lean processes to avoid bureaucracy. Many projects spend considerable time meeting all kinds of formal requirements such as: reports, risk logs (and sometimes precious time is wasted on philosophical discussions about the nature and content of a risk log). Of course some formality is required especially in complex organisational settings, but our philosophy clearly is: less is more.

Also, we are not dogmatic with regards to methodology. In fact we appreciate that agile methods are now well established in the corporate world. Unfortunately, they are often followed dogmatically: is it so important to start every story with ‘The user wants to’? Why have daily stand-ups just because the method says they must be daily? We are only dogmatic about one thing: Formality should support the project and never should projects support formality – at least if you are eager to deliver.

Individuals and interactions over processes and tools.
Working software over comprehensive documentation.
Customer collaboration over contract negotiation.

Agile Development

Our projects are organized in weekly updates called 'iterations'. On a weekly basis, we plan which features should be implemented and which bugs should be fixed during the next phase.

While the development team is implementing and fixing, the business analysts specify new features. Typically, we know one or two weeks in advance which feature should go into implementation next, so these are prioritized.

Agile development demands that there is a working version of the system available at any given time. In the beginning, the system may not do a lot but as it evolves, it always reflects the current state of the application and can be reviewed and tested by analysts and users.

Communication is key

Communication is key: if you do not remember (or can’t even pronounce) the names of your team members, you are already on the road to failure.

We communicate with users, stakeholders and developers as early and often as possible. Good communication helps to avoid misunderstandings.

Thanks to our agile approach, we have something to show users (even if incomplete) from very early on. We show them progress according to reality, not according to our (or their) dreams, and we are prepared to address potential challenges or to discuss workarounds.

We try to respond to developers’ questions quickly and often, it normally doesn't take more time than drinking a cup of coffee to clarify a requirement. Invest 5 minutes to avoid slowing down the development process unnecessarily.

Communication technologies currently available are great, but you have to know the people involved. Yes we use Skype (and web-based communication in general) and we love it, but we regularly meet in person to discuss things face-to-face and to have a beer (or mineral water, if you like) together. Knowing the team members personally is key in order to benefit from each member’s individual strengths and to achieve great team play.