VDubinator Coder

About a year ago, the company I work for adopted the Scaled Agile Framework  (SAFe). It's been a huge undertaking and is something we're still adjusting to and refining for us. Overall, I think it's been a huge improvement over what we were doing before. While SAFe won't work for everyone, here are some of the benefits we've seen from implementing SAFe. 1. Executive Support From the very beginning, our CEO was on board with this. That made the whole process that much easier. Because he was supportive of it, that influenced the other executives to also lend their support. All this support made it much easier for us to successfully and quickly implement SAFe. The consultants we hired said one of the biggest things that hold companies back from successfully changing processes like this is executive buy-in. Because we had that support all along, it made our transition go much more smoothly. 2. New Roles Before SAFe, we didn't have dedicated Scrum Masters. W

It's been a few weeks since I provided an update on this. Activity on the Slack channel died down there for a little while. One reason for it is a number of the participants in that channel got very busy with actual leadership activities. There was a management retreat that a number of individuals had to prepare for and attend so time was pretty restricted there for a few weeks. There were other factors as well. I think I might have been posting too many questions as follow ups to the article(s) I'd post. I'll try cutting that back and see how it goes. We ended up having a conversation about the channel and about why activity has died down. We discovered the above and also decided that we'd like to meet as a group every once in a while. Together we decided that we'd meet once every three months or so (once a Program Increment). We decided to have a facilitated discussion for half of it and then lightning talks related to leadership for the other half. That meeting

I recently met with a mentor to discuss career development. We chatted for a while, but one of the themes of our conversation stood out to me: Leaders have vision . Leaders can see down the road past the current feature or story they're working on. Leaders can see the forest for the trees. While some leaders have the opportunity and/or ability to dive deep into the details of the task at hand, they're also able to take a step back and see the bigger picture. They understand that the lines of code that they're writing or helping to write connect with something bigger and are building the future of the software. Being able to connect the current task to the bigger picture doesn't come naturally to some, but it is a skill that can be developed. I often ask myself, "how does this fit in with the other tasks I know about?" Or, "how are these things related?" Or even, "how does this help our company carry out its vision or meet its goals?" Or

Just quick post on a book I read relatively recently called One Small Step Can Change Your Life: The Kaizen Way . This is a fantastic read. Its one of the few books that has changed my life. I've been thinking about it recently and thought I'd share a few thoughts on how it relates to Software Engineering. The book talks about how small changes are a lot easier to actually do than big changes. Not only that, they can build up to big changes. In Software Engineering, there are a number of best practices we know we should be doing but that we often don't do for one reason or another. Be it better code formatting, TDD, writing tests at all, communicating better with our Product Owner, or whatever it is, there are a number of things that we often struggle with even though we know better. If we were to take one of these items and want to improve them, our natural tendency would be to go all in. 100%. We feel that if we're not 100%, we're failing. Why do it at all if

Recently I had the opportunity to visit a customer with some coworkers. The purpose of the visit was to review their current business situation with our software, address concerns, and provide a look at the way forward. Overall it was a productive meeting and I think the customer got a lot of value out of it. As I was preparing for and participating in the meeting, I couldn't help but think of some things that can be done to ensure a successful client visit. Open Communication It's imperative to communicate openly with all parties involved in the visit. The customer, your coworkers, and anyone else involved. Before the meeting, I was struggling to see my role in it. So, I asked the organizer of the meeting about the purpose of the meeting and how I, as a software engineer, fit into it. It took a few days before I got a response and the response I got didn't really help. So, I asked again and it took a few weeks to get a response that, again, didn't address my concer

Last week I posted a question to the dev.to community. It's a pretty simple question and it honestly wasn't a big deal. There have been about 30 people that have participated in it but it's probably been viewed by a few hundred. In a world of viral images, videos, and news, this was pretty insignificant. But it seemed somewhat big for me. I don't consider myself to have awesome ideas. I follow and work with a lot of people that are very smart. I sometimes make contributions that are as valuable as theirs, but most of the time I try to work hard and do my job as best I can and provide value in that way. As far as someone to cause ripples in the water, I don't consider myself someone that really could be doing that. One day I'd hope to be as smart and as good as someone like that, but I don't think I'm there yet. When I joined the community, I noticed their welcome message which reads, in part: Where programmers share ideas and help each other