Is Scrum Master the toughest role of Agile?

For past 2 weeks I am in Boston on a business trip. And on a lonely evening I was just thinking about the change of role that I am experiencing from what I was 5 years back and what I am today.

5 years back, most of me was a Project Manager - busy with managing project, assigning tasks, running behind teams, writing status reports, convincing customers, fighting with management, yada yada yada ... the list just goes on. I dont fully remember how satisfying the days were, but don't even think I had any peaceful days.

Today, most of me is a Scrum Master and let me say "I like it this way". No team to run behind, no customers to fight with, no management disagreement (well, most of the time) and most importanly, I don't have a responsibility ..... wait .. let me take that last one back. "No Responsibility" ... that does not sound right.

And this is the exact thought that struck my mind. Being Scrum Master has eased my day to day life, but has it made me less productive, is it any easy compared to being a Project Manager, has it taken the challenge out of my job ... and many such questions. There as no direct answer, so I had to rewind the 5 years and start from where I had left. A One-on-One comparison of what challenges I had then ... and what challenges I have today. And after a good hour on the thought, the picture was very much clear.

Being Project Manager was easier than being a Scrum Master.

• It was easier to ask a team to do something and push them forward. Believe me, it is very difficult to convince someone to do the right things.
• It was easier to prepare my project plan with my estimates and assign the resources. Believe me, it is very difficult to have every team member get their Sprint Backlogs ready before start of the Sprint.
• It was easier to demand I want it by today evening (max by tomorrow morning). Believe me, it is very difficult to say Alright, do it by tomorrow morning, but ensure it is done.
• It was easier to get the status from team members and present it in the Green Zone to customer. Believe me, it is very difficult see the team exposing the real status on daily basis.
• It was easier to take the project decisions and own them. Believe me, it is very difficult to coach a team to be empowered to take the decisions and respect it, fight with management for protecting the team decisions.
• It was easier to prepare a 6 months /1 year / or longer plans and blame everything on Change Requests. Believe me, it is very difficult to say, changes? so what?
• And many more things .... but the most difficult is to create this fun loving environment, a healthy and faith based work culture with customer and letting it go so that team can manage it. It is just difficult to see stuff not happening the way you like. And it is very difficult to say "team did a great job" knowing that you probably would have done the same way.

So seriously, it was easier to be a Project Manager than a Scrum Master. But not necessarily Satisfying. I realize, being a Scrum Master today I do have challenges of empowering the team and coaching a customer. But at the end of the day, I am satisifed to see customers gets what they really want, teams are happy and are committed to the work.

No big deal that I am not in control. All that matters is "Things are still going fine!!"

User Stories or Use Cases

This seems to be the question of the month. I got it quite sometime in last few weeks. So thought of penning some of the discussions, thoughts and research I did on it.


As Dr. Cockburn said it, besides the first three letters, there is nothing common between Use Cases and User Stories.


Use Cases are favorite of the technical world when it comes to capturing the functional requirements. It allows you to capture many details including the functionality, alternate flows, exception conditions, and other things associated with the requirement. And it asks for more detailed analysis and brings a more formal way of capturing the requirements. But a major draw back of Use Cases is it requires you to capture too many details right up front and calls for a good amount of documentation.


User Stories, on the other hand are a very "informal" way of capturing the requirements. It focuses more on the discussion between Developers and Users. It allows you to capture these details without any formality and with clear focus on understanding the requirement as the user will like to see it implemented. To add to the informality associated with user stories, let me mention that many teams use the Story Cards - a complete non-electronic way of capturing the user stories. The beauty of the user stories is it is depicted the way user understands it.


I remember I read it somewhere - the three "C"s of user stories - The Card, The Conversation and the Confirmation.


The CARD is the medium. It is small big enough to write a user story and small enough to keep it short that a developer can implement.


The CONVERSATION is the key aspect of a user story. The story on the card is only the notion and expects the developers that the story is not complete without a Conversation with the user. So get into discussion and get the details you want, only when you are ready to start implementing.


The CONFIRMATION is an agreement between the developer and the user on how the story will be implemented or let us say 'when is it complete'. It is the acceptance criteria or the 'definition of done' for the story on the other side of the card.


Well, the real question still remains - What shall one choose ... User Stories or the Use Cases? What is the criteria?


I think the answer lies in what you need. If your customer expects the very well defined formal documentation, guess your choice is Use Cases. But if you have an opportunity to discuss and work with customers closely and if you are not very keen on very formal documentation, well go for Use Cases. But let me tell you that Agile as such does not stop you from or even recommends against creating Use Cases.

Certified Scrum Master

Yooohoooooooooo! That’s how I feel after earning my very own Certified ScrumMaster (CSM) certificate.

While working on Agile Scrum for almost 5+ years now, I always wanted to get myself this certification. And it simply feels great to complete it with a commanding score of 96%. Sad part is the 4% I missed on one question is something I always talk about in my Agile trainings and coaching. It was a comfortable exam with some of the tricky ones. But the end is sweet sweat.

After returning to Mumbai, I searched for the CSM courses and to my surprise, there were no courses conducted in Mumbai. So contacted Pete about the same. Couple of months later, received the course invite happening right here in Mumbai. So got registered, got the real good insight into Pete’s knowledge base, his easy ways of making you understanding and very impressive skills to communicate. 16 hours later it was a great feeling to realize that most of what Pete taught is something I was practicing already. And many new things I learned are very effective. The knowledge from training was immediately useful on the project I was working on.

But that last action was still on me. To go and take the online assessment. Waited for it for 2+ months. Not that I was scared but just that I just could not devote time to take it. Finally just yesterday committed myself to the cause and complete it. A whopping 96% felt really good. And I am officially the Certified Scrum Master now. Visit the link here to check my profile on ScrumAlliance.

Now my eyes are on becoming a Certified Scrum Trainer. I hear that it is a 2-3 year journey after becoming the CSM. Well, who is in a hurry? Do it slow but do it right!