If you search LinkedIn for groups related to Scrum, you get almost 700 results as of this writing. Many of these are fantastic groups, with great people offering advice from the trenches. If you use Agile, particularly Scrum, you should follow these groups. Just beware that there is a problem there: sometimes you find yourself staring into the wide eyes of the converted. It's particularly bad if you're staring in a mirror.
From time to time people in various Scrum groups ask "What are the weakness of Scrum?" And, I kid you not, more than once I have seen the reply "none, Scrum is perfect." Those respondents are the people who won't change their mind and won't change the subject and I very much want to gently shove them into a meeting full of their fellow converted and go back to getting work done. Out of deference to their disability, I will set a goal for the meeting, time-box it at eight hours, and when the participants email me the action items, I will print out that email and burn it. It will be a good day.
Or, as a fellow Agile trainer wrote to me "some of my clients are dumping Scrum just to get away from the zealots."
Lord, save me from your followers.
Fortunately, those who believe that Scrum (or XP, or Kanban, or Scrumban, or, or, or ...) is perfect, are in the minority. They're the obvious crackpots that we greet with a fixed smile and back away from slowly, but there are the less obvious crackpots who are far more dangerous because they sound so reasonable.
These are the ones who believe with a fiery passion that everything should be Agile. These people are going to hurt your company.
To understand this, we need to remember what Agile is. Agile development is simply a set of practices designed to better cope with uncertainty and change. That's all. A key indicator of when to use Agile is when you're developing a new technology and saying "wow, look at all the possibilities!" When you're breaking new ground, when you're pushing change rather than following the herd, then Agile is a great approach.
But what if you don't have a rapidly changing environment? What if quality and reproducibility are more important considerations? Janitors don't need product owners. They don't create "who/what/why" story cards. They don't have sprints. If your janitorial staff are struggling with a chaotic, uncertain environment, you have bigger problems on your hands. Mind you, there are janitors who have to deal with rapidly changing environments and uncertainty. We call them SEAL teams.
OK, so maybe you've outsourced your janitorial staff and are thinking everything else can be Agile. Let's head over to your accounting department. Forget about your prejudices for a moment and look at what accounting does. Ask yourself one question "do I want them using a project management system that's optimized for uncertainty and change, or quality and reproducibility?" Remember, your answer not only has financial implications, but legal ones as well.
When it's phrased in those terms, the answer is fairly clear. Even the most ardent Agile proponents would have to agree that an accounting team may need to be run differently from a software development team. There is no "one size fits all" suit for project management and if you're trying to cram everything in your organization into the same system, you're begging for trouble.
As a rule of thumb, for every department ask yourself how "new" their product is. The newer it is, the more likely it's being born in an uncertain environment and Agile is a good approach. If it's an older, mature, stable environment, consider PRINCE2, TQM, or other related project management solutions. Lean solutions fit somewhere in the middle of those two extremes.
Don't let yourself get caught up in the hype. Agile solutions are excellent, but don't go out in pairs, knocking on doors and preaching to the masses. Different problems require different solutions and we need to give up our ever present quest to find the One True Way.
If you'd like to know more, you might want to read when to choose agile