Maybe you've read our bio and raves and are still wondering what the Fearless Agility difference is. Maybe you're thinking, What's in it for me? What can Fearless Agility offer me that other Scrum training can't? Well, look no further! Find the answer in this short video taken from a real life Fearless Agility event.

The alchemists at Fearless Agility labs are getting ready to put on a couple great sessions at #SGMSP. Just because it's nerdy doesn't mean it has to be boring...

With the Scrum Gathering fast approaching (don’t forget to check out my two talks) I was recently asked by Dave Prior (The Drunken PM) at ProjectManagement.com to participate once again in his podcast. It reminded me of the interview I did with him at last year’s gathering on my own path from PM to Agility.

When development organizations first consider adopting Scrum, an agile project management approach with clearly-defined roles and processes, there is often confusion about where the use of Scrum is appropriate and where it's not. Jimi Fosdick dispels two pervasive myths regarding where Scrum cannot be used, considers what kind of work is appropriate for Scrum, and describes the keys to Scrum success.

When making the jump from project manager to ScrumMaster, behaviors and techniques that worked well before may work against you in the new paradigm. Here, two experienced project managers and Scrum trainers share their experiences and insights on navigating this challenging transition.

Someone recently asked: "Management is demanding release dates a year out, but Scrum says not to do that because of the rapidly changing environment that is software development."

My first response is simple, if unsatisfying (and possibly pedantic): Scrum doesn’t say what you think it says. Scrum does not say not to plan releases a year out.

When we are introducing Scrum to a new environment, we often get into debates, sometimes heated, with people who question the validity, truth and/or value of a particular agile or Scrum principle. My general feeling is that any time spent having a philosophical argument with a client/Product Owner is time not spent adding value.

One of the principle practices in Scrum (and in fact most, if not all, agile methods) is the use of “cross-functional” teams. Somewhat surprisingly, there is often resistance at the team level to creating these cross-functional teams, but sometimes this is a result of misunderstanding what we mean when we say that a team is cross-functional.

One of the main myths of traditional project management relates to measurement precision. Traditional project managers have numerous statistical tools in their arsenal. Such measures as earned value or cost performance indicators etc. are touted as providing a precise scientific measure of how we’re doing.

An interesting discussion that frequently crops up when introducing Scrum to certain organizations and individuals is the argument that they don’t have time for backlog grooming because they have “work” to do. I get this argument a lot during coaching engagements when I tell team members they need to spend five percent of their time grooming the backlog.

One of the things we advocate in Scrum (and really most agile proponents do as well) is small cross-functional teams. I discussed what we meant by cross-functional and some of the reasons why in a previous entry. Now I’d like to look at why we recommend small teams.