Colleague and friends

Here are the blogs from my colleague's that I like to read.

• Nocturn Vision: .Net best practices in today's agile world, clean and to the point.  You'll love reading here articles :)
• Jelle Bens: Jelle is so keen on agile methodologies and read all books about it, I wonder when he'll be writing his own...

Scrum during maintance?

A few years ago, I was hired to help a customer that had legacy software in need for replacement. We  started applying the Scrum methodology that was effective and we kind of made our deadline with the project. Once in UAT (User Acceptance Testing), bugs started to come in. When show stoppers arrived, UAT was "stuck" and the Scrum dev teams had to bend to fix these during their sprint.

We started to reserve "bug budget" to accommodate UAT bugs.  UAT was actually coordinated by another department and we wanted to offer full support and be good and helpful IT guys. The immediate nature of bugs and their priority can be quite disrupting for developers that believe they are protected by the scrum sprint cocoon. At the end we struggled through all of this, but it never felt smooth and ironed out.

When the software went into production we all took a deep breath from the final dev weeks (you probably know these nearly deadline periods). In the first weeks after the release a few more bugs came in while we were already doing the next sprints for additional features. More and more we got into small arguments with the business that they had to wait until the end of the sprint to fix pending issues. People did not understand that money making (or losing) issues had to wait for weeks. Some were really getting annoyed with the Scrum principle we held on to.

This of course asked for other ways and other tools. Scrum was our friend for quite some time, but it was letting us down more and more. Searching for new ways to assist, we found out that Scrum had a brother in the Agile family called Kanban. Checking around, it was exactly what we were looking for in our situation. It kind of removed the rather large sprint planning meetings and the time boxed aspects of Scrum. It allowed us to fix hot issues much quicker while still keeping a structured approach. Kanban is not only for bug fixes, it can also be used for new features, however, it was a better fit in context of our maintenance period where the odd new feature or change request came in.

At the end of the day we were convinced that Kanban and Scrum both come from a great family, it's just a matter of mixing the right methodology for the right purpose. Basically, Scrum worked out when building new applications or new major releases, while Kanban worked perfectly for maintenance and minor releases.

Back to blog

After several years I'm back to the blogging scene.

The first blog I created was in 2003 based on textpad that I hosted and extended myself. This time I'll blog using wordpress, no hastle, plain and simple. As before I'll use this blog to share my experiences, things that work and things that doesn't. At the time of writing I'm working as an IT architect so most of my articles will come from this angle.

Hope I can help you out as many other blogs have helped me in my carreer already.