Trying Vs. Seeking Permission

Sometimes back, I facilitated a team with the objective to eliminate a couple of bottlenecks in the process to ensure early delivery.

To begin with, I proposed several directives for all of us to own. Upon completion of second sprint and observing only ordinary benefits, one of the team members asked, “Can we alter directive #3 so that we can get…”

He got an uncomfortable reply from me: “Trying is much better than asking for permission when you’re part of an agile project.”

The team tried it, altered the directive #3 and within couple more iterations they observed better results.

“Try and fail, but don't fail to try.” ~ Stephen Kaggwa

It was a learning experience for the team members. They learned that getting out of their comfort zone, doing what is right and being responsible for what you they done is much better than asking permissions.

It could have been failed as well. But that’s not much of a point here.

Point is to get out of your comfort zone and take actions. Over the course of a few sprints, team would figure out what would work and what wouldn’t.

Constraints such as directive #3, even though listed, may not always apply to a particular situation. Don’t assume that it will.

When you’re part of a true agile project, you’re limited only by your self-imposed constraints. Work on that part and organize yourself to do what is right without being afraid.

Perhaps that’s why Agile Manifesto values Individuals and Interactions more than Processes and Tools.

Now, that’s something so basic but important like hell to execute Agile Projects well.

Why ScrumMasters Should Say “No” to Multiple Projects at a Time?

“The shortest way to do many things is to do only one thing at a time.” ~ Richard Cech

Few days ago, I wrote an article for The article is about the  Seven Things I Wish I’d Known When I Started out as a ScrumMaster.

One of the things I mentioned there was to work on one (and only one) project.

In the article, I explained why it is important for a ScrumMaster to work on one project at a time. The explanation was simple: Working on one project at a time brings-in required focus to do your best.

I got many comments there. Out of them one of the comment was about the above point. The commentator mentioned that if the organization has gained required maturity about Agile and Scrum, then they can use a ScrumMaster to do “more” jobs.

I had to respectfully disagree.


Being an effective ScrumMaster is a full-time job. Period.

Unfortunately many organizations that do not have right understanding of Scrum sometimes fail to recognize that a great ScrumMaster has NOT to work on multiple projects at a time.

For example, consider if a ScrumMaster is working on two projects and in order to resolve an impediment in one project, he has to spend several days.

Obviously the other project will have to suffer. At his best, the ScrumMaster will be able to devote 50% of his time to each project, isn’t it?

Also, when impediments are not resolved in timely manner, it frustrates the team members and produces not-so-positive outcomes.

I have seen that organizations that get maximum benefits of Scrum prefer that a ScrumMaster is working on one project.

Then the commentator called me to ask: “Is it a rule in Scrum that a ScrumMaster cannot work on two or more projects?”

No, it’s not a rule. It’s about choosing the right thing to do. Sure, a ScrumMaster can work on multiple projects but most probably with mediocre results. That’s why effective ones do the opposite.

And, the greatest gift an organization can give to a Scrum Team is the gift of an Undivided ScrumMaster.