Software developer and agile coach aiming to deliver software with always the most important specification in mind; make it easy maintainable.
Studied higher computer science and started off as an embedded software developer at Philips Research but after spending a couple of years of assembler and C the time was right to dive into the world of OO software, databases and internet connected applications.
Being one of the first 500 Microsoft .Net certified developers at the beginning of 2003 and since then engaged in .Net application development.
In 1998 he started a company specialized in consulting companies regarding Microsoft .Net application development and since 2006 excited with scrum and agile methodologies
At this moment Christian is involved in developing Credit Risk Management software for one of the biggest banks in the Netherlands
Next to software development he is a qualified pilot and passionate flyer of Cessna and Piper airplanes, Padi rescue diver, motorbike rider, windsurfer and off-piste skier.
Talk: The real value of a Definition of Done
This presentation explains how the proper use of a definition of done can help a team to deliver software that really matches the customer needs in the fastest way possible.
The essence of this is to make use of feedback given by the customer, tests and systems. Feedback will help you to improve, learn and reach your goal more effectively. Important is to receive feedback quick and many times, iterative development can facilitate this. When and what you actually get feedback on is defined in the Definition of Done.
The Definition of Done defines all steps necessary to deliver an increment of done with the best quality possible at the end of a sprint. The more you do in your sprint, you more you get feedback on, the more you can improve and learn.
When demonstrating the software for example every week and implementation is done based on the product owners priority, there is a big change the product owner approves the application even before all requested features are implemented.
This presentation explains the exact reasons why to use a definition of done and how to implement it in a software development team. It shows how the planning process will improve and how it will keep the product owner posted on what exactly is going on in the team (and not keeping it fuzzy).
The presentation will talk about how the definition of done will deal with the next issues:
- What can a team accomplish every sprint?
- How can we go to production every sprint?
- How can we let the product owner in complete control of the release planning?
- How can we avoid the bad practice of the so called release – and test sprints needed to go to production?
- How can we make the best usage of burn down charts without letting this chart giving a false indication of progress?
- How can we avoid the so well know risk of the most expensive bugs; the ones that reveal themselves in the production environment?
- How can we measure the maturity and competence of a software development team?
- How can the use of two versions of the definition of done help to mature the team and to make progress of maturity visible every sprint?
- How the use of the definition of done can give the product backlog much more sense and better manageable.
At the end of the presentation the next conclusions are drawn:
A good Definition of Done will help with:
- Getting feedback and improve your product and process
- Better release planning
- Giving burndown charts sense
- Minimizing the delay of risk
- Improving team quality/agility
- Creating transparency to stakeholders