Adapting Agile to the real world
Pick up a book on Agile practices and you might find a wonderful, yet often unrealistic view of a perfect world where everyone buys into Agile practices throughout the business and you glide gracefully down the road to success.
The problem is that for most of us, that perfect environment doesn’t (and will probably never) exist, and that’s OK.
Maybe your team isn’t staffed the way that it needs to be. Maybe the people on your team don’t have the right skillset (yet). Maybe you have to integrate with lots of other systems, so you have to do a lot of up front planning and design so that you can make sure everything gets done on time.
The point is not to implement 100% of Scrum or XP or Kanban or some other methodology. I like to boil Agile down to this:
Do more of what works and less of what doesn’t.
Implementing 100% of XP may not be the best thing for you, or it may not be feasible. That’s not XP’s fault, they’re just giving you a set of best practices to work with that have proven to work well for some people. It’s up to you to make it work for you. Frankly, I don’t think it matters if something you do falls in the category of “Agile”. I just want to find ways to improve the development process, regardless of what you call it.
One practical thing that we all can do (whether we’re in charge of a team or not) is to try to improve our development process every day. Try to find ways to do more of what works and less of what doesn’t, improve processes and communication, and help your team succeed. Set your sights on the end goal and start taking steps in that direction.
To compliment what you’re saying here, I saw a great interview with Mary Poppendieck about how IBM implemented Agile. Knowing anything about human dynamics and huge bureaucracies will tell you that it’s not possible.
Instead of adopting what others call agile she describes how they implemented “Agile at IBM”. It was their own process which focused around doing more of what works and less of what doesn’t.
If you’re interested in process change and Agile, this is 30 minutes of your time well spent: