Search This Blog

What’s the value of Agile out of the box?

I often meet peers who ask what Agile practices Pathfinder utilizes. From the outside we pretty much use all of XP’s practices. However, if you take a deeper look we do some things a little differently (especially how to use and calculate velocity). For Agile purists, one might question if we are really doing Agile. They would claim changing practices is slippery slope. For example, a team will start altering Agile practices to create a “home grown” version only to find they are using only some practices and not seeing the benefits they hoped for. I feel questioning if we are really doing Agile based on exactly what practices one uses shows how familiar and mature one is with Agile principals. A better question would be to ask why we changed them. Agile is not meant to be a methodology, but a set of principals. In my opinion, using things like Velocity to estimate whether a team will finish a project within a certain time frame is a hack at best. This always was hard to explain to customers. While I was reading Leading Lean Software Development I discovered something that helps. The Poppendieck’s point out that the engineering practices of Agile (TDD, collective code ownership, etc…) are solid and not likely to change. But, the project management practices implement a system on top of another system - a hack.

Once you have sufficient experience managing projects with Agile practices you should feel comfortable adapting those practices to your own teams and projects. As long as you are still following Agile principals this is okay. In general, this is what’s going on in smaller companies. Having coached a number of large organizations transitioning to Agile I can say this isn’t how they look at things. The problems start when you adapt the practices, but try to deliver all projects in an identical manner. This makes sense for waterfall-like delivery methods. But, when an organization comes up with its own version of “Agile” it can only work for the subset of projects it is tested on. Rolling this out to the entire organization as “the way” to deliver projects from them on is a failure pattern. The principals are lost and so is the adaptability of the organization. The time spent to move over to agile is immediately wasted.

Popular posts from this blog

This is from a product I use daily. Who wrote this code and thought they were done? Who approved these two button styles next to one another?

I have this vision of a developer choosing a library that made their development life easier. I picture this code going straight into production use without review. Next, I picture the designer who works there rolling their eyes, checking out, and heading to LinkedIn to see what other opportunities exist.

I'm being unfairly harsh, but it makes me wonder what other sloppiness is happening inside this product.

Originally posted on ForeverCar Blog: https://blog.forevercar.com/an-easier-way-to-decide You probably have far more important priorities than taking the time to research vehicle service protection plans. That’s where we come in. When we set out to create the latest innovation to our consumer shopping platform, we vowed to keep it simple. If you are not shopping for vehicle service protection at forevercar.com, you are likely sitting across the desk from a loan officer at a bank or a finance manager at a dealership. There are a couple problems we've identified with this scenario: It’s bad timing. You are typically involved in a larger, more complex loan transaction involving your vehicle. Taking the necessary time to research the offering is impractical and highly unlikely to happen in that moment. That’s why most people pass on vehicle protection at the bank or dealership. Wrong amount of detail. There’s a lot to this. A service contract is full of important coverage details, financ…