One Step at a Time Towards One Bug a Month

Added to Process

Our latest experience report is by Patkós Csaba from Syneto, a Romanian company known for its Storage OS System. Patkós tells about their four-year journey from a traditional development process to an agile one. One thing I like about this story was the gradual yet steady introduction of new ideas and practices. There wasn’t a big bang agile adoption. They read books and tried new ways of doing things; his manager seemed a master at introducing agile techniques without fanfare. After they achieved a regular, predictable cadence to their work, they began streamlining their process even more. Backend developers paired with UI experts and team members’ skills broadened. The UI designers are still skilled at designing the UI, but backend developers now work comfortably in the UI layer making bug fixes and pairing with a UI expert. They took the bold step of removing comments in their source code—believing that any unnecessary comment was waste (after all you have to read both the code and the comment to understand the code), while at the same time refactoring their code to be more expressive.

They enforced a rule that they would write an automated test for every detected bug that would run as part of their CI process. In Patkós’ words, they “managed to transform the perception of ‘a new release means more bugs’ into a perception that ‘a new release means fewer bugs’.” That’s huge.

Yet not every change is an improvement. That’s important to remember. When they first introduced a Jira planning board, it slowed them down—because people stopped having a visible indicator of progress (they were too lazy to open up Jira on their computers). So they went back to a physical planning board and things returned to "normal", until that became too unwieldy. Their current planning board solution is to use Jira and have a monitor which prominently displays real-time progress in their team room.

To keep moving forward, you need to reflect on what’s working and what’s not. You need to try new things. When something stops working, you need to make another change. And, you may need to adjust again. Syneto is a learning organization and that’s what keeps them agile.

If you’d like to share with others what you’ve learned on your agile journey, I encourage write an experience report. The Agile Experiences Program is interested in hearing your ideas and helping you tell your story. Or, if you have questions, feel free to contact me, the program director, Rebecca Wirfs-Brock at experiences at agilealliance dot org for more information.

About the Author

Rebecca is President of Wirfs-Brock Associates. She helps organizations and individuals hone their design and architecture skills, improve system quality and manage technical debt. In addition to coaching and mentoring she conducts workshops on agile architecture, design and pragmatic TDD. She invented the set of design practices known as Responsibility-Driven Design (RDD) and by accident started the x-DD meme. Rebecca is Director of the Experience Reports Program and Experience Report Track Chair. She is on the Board of the Hillside Group and writes patterns about sustainable architecture, agile QA, and adaptive systems. If you want to share experiences or wisdom in pattern form, Rebecca can help you turn your itch for writing into the written word. Read her blog at www.wirfs-brock.com/blog and find articles and patterns on her resources page, www.wirfs-brock.com/Resources.html


This is an Agile Alliance community blog post. Opinions represented are personal and belong solely to the author. They do not represent opinion or policy of Agile Alliance.