I recently started filling out a form which included a question regarding the training I’ve done. As I filled it out I realized that in the past 15 months I have trained or given presentations to over 1,000 people. I’m sure some of those were counted two or more times for attending different events, but even if that occurred 25% of the time I’ve still trained over 750 people over the past 15 months. I mention this because of those 750 people, about 700 of them are working in an agile environment or want to work in one. Meanwhile…
… about 50 of them want to work in an agile environment and inevitably say to me “We can’t be agile because <fill-in-the-blank>.” I’ve heard all sorts of things in the blank of that sentence. I’ve heard our team is too big, our project is too big, our culture won’t allow it, we work on government contracts so it isn’t allowed, no one else would support agile, there aren’t any training dollars to get started, blah, blah, blah. I get a headache just thinking about all of the different excuses I’ve heard.
I started this blog entry thinking I would go over each reason and why it wouldn’t matter in the end. While writing the last paragraph I realized I didn’t want to type a 10 page, extremely boring blog entry. So instead I want to give some advice to anyone who is tempted to start a sentence with “We can’t be agile because…”
Don’t worry about what you can’t do
figure out things you CAN do!
For example, can you:
- Prioritize work into a product backlog so the highest value items get completed first rather than the easiest items being cherry-picked?
- Stop every 2 weeks and give a demo of current functionality to determine if any changes need to be made?
- Meet for 15 minutes each morning to ascertain how things are going and if any help can be provided by one team member to another?
If you are still stuck, then another piece of advice is often useful:
What can the team do on their own?
(without changing things for others)
You don’t necessarily have to do ALL of a particular agile process or all of the agile related engineering practices in order to improve your results! As your results improve the organization will notice. When the organization notices, one of two things will happen: a) they leave you alone and say keep doing what you are doing, or b) they will try to do the same thing on a larger scale in the rest of organization. I’ve never seen a reasonable organization shut down a team using agile where it wasn’t really “allowed” (although I have seen it done when the organization was not “reasonable”). Instead most of them try to figure out how to allow it without hurting other parts of the organizations. Every once in a while, and happening with more frequency now, they decide to take a plunge into the deep end of the agile pool and see what happens. If this should occur in your organization, let me know – we have statistics that can show ridiculously high ROI for agile training and coaching within a year for most teams (data based on results from various surveys and standard training/coaching costs).
If you truly believe your company, division or team can’t be agile for some reason, post a comment. Let the rest of us try to help you figure out how to get there in spite of the major impediment you have!
Until next time I’ll be helping people remember to concentrate on the agile things they CAN do, so slowly but surely they will be Making Agile a Reality™ for their organization.