VDubinator Coder

Last year, MasterControl hired some consultants to help us transition to the Scaled Agile Framework (SAFe) . One thing they talked about has been on my mind recently. They taught us to allow the process to break. If something isn't done correctly, allow the error to occur and be highlighted in the system. This counsel isn't meant to shame anyone. The purpose behind it is to highlight the areas of the process that need some more work or focus. If we try to hide the errors or cover up things that aren't going well, we'll just end up creating more work for ourselves and slowing down the system instead of speeding it up. For me, this is difficult to do. In certain situations this can be apparent and it can be easy to follow; however, in a lot more situations, it's not quite as apparent and I normally don't think about it like I should. Let me give an example. There are a lot of times that the Product Owner will come to a team with an item to consider working o

I recently started a new, just-for-fun project. I've always heard of the benefits of having these little side projects but I rarely do anything with them because of how busy my life is right now. Since starting this project, though, I've noticed a few benefits of having a side project that's pertinent to the things I work on at work. Just recently, ThoughtWorks released the latest version of their Technology Radar . Like many others, I enjoy reviewing their radar and seeing some of the current trends in the software landscape. One of the items that caught my attention was  Lightweight Architecture Decision Records . In their description of it, they link to an article describing it and a tool that can be used to generate the records they're referring to. I liked the sound of it and I wanted to try it out. It sounded like my work could benefit from this technique. However, at work we follow a similar approach to the ThoughtWorks technology radar. We like to evaluate