Blog.CBojar.net

It's finally happening: your team is finally going Agile, whatever that means. The business has complained for too long. The team has complained for too long. You need to move faster and do more. Word comes down that you're going to try Scrum . This shouldn't be too bad. After all, Scrum can't be that hard to master . Well, turns out that there's a lot to Scrum, and your team can't just switch over in one day! Let's take this slowly, adding in the simple parts and going from there. Timeboxed iterations make sense. Your team already has a weekly meeting, so sprints are a week. That was pretty easy. What's next? Product owner, no; retrospectives, no; story points, no. Aha, stand-ups! Once every day, you stand up and talk about stuff. That's easy enough. Done. You are so Scrummy now! Or not so much. That all-too-common story of Agile Transformation highlights a number of pitfalls that derail real change. The most deceptive practice, though, is the d

As software developers, our job is managing dependencies. We have to carefully construct balanced graphs of classes, objects, libraries, services, and more. Code needs to be encapsulated, reusable, and extensible, all while creating end-user value. We use techniques like composition, inheritance, and dependency injection to separate this from that, knowing that this or that could change in unknown ways at any moment. We don't always get to create the perfect system from the ground up though. Sometimes, we work on software developed long ago that could not anticipate today's needs. It hurts a little more when we see our name on all those commit messages. Regardless, we need to make the necessary adjustments for our system to meet the needs of today and tomorrow. To make code more flexible and adaptable, we often have to break it up into more singular and discrete responsibilities. We have to pull out and encapsulate the pieces that are at different levels of abstraction. We ha