I am a CSP (Certified Scrum Professional) !

I am not a big fan of certifications. But, I was intrigued by CSP for almost a year. I went to CSM training last year just to make my resume attractive. But, I learned a lot in that training. My planned next stop was CSP certification. But, I could not even start to prepare for the exams mainly because reading list for CSP was  too looong! 

I kept procrastinating taking the test until Scrum alliance announced to abolish the test route for CSP. That was a wake up call. I registered for the last available weekend before Scrum alliance pulled the plug on the test. I went in last Saturday and aced the test. I prepared for about 4 weeks. It was very hard. However, I learned some interesting ideas just because I was forced to read up tons of books and materials. 

Many years ago, I took the PMP exam. That was brutal. CSP is even more brutal. I am glad that I passed that test!

Are you a good Scrum Master?

Scrum Master is not supposed to "command and control" the team. The team is supposed to be "self-managing". That is the crux of the scrum process. Lot of new Scrum Masters can't comprehend the fact that team does not need to "obey" their orders. Scrum Master's job is to create a good collaborating environment in which the team members self-organize to create the best product possible. When a person makes a transition from typical Project Manager role to Scrum Master role, it's frustrating for him/her to understand that Scrum Master should not make decisions but only provide guidance. I have seen lot of Project Managers in waterfall environment have demanded "do this because I said so". That will not work in Scrum. 

I have played various roles in my career. I was a Project Manager for many years in waterfall environment. I worked as an Engineering Manager as well. When I made the switch to Scrum Master role, it was hard. I could only guide the process. I could not demand something from the team. At the same time, I was accountable for the success of the project. I was like... "what I got myself into?!". The success of the scrum process lies in the self-organization of the team. If the team needs to be directed by Scrum Master or Engineering Manager, the company will not see the benefits of Scrum. I will discuss more about self-organization in the following posts.

First thing a good Scrum Master needs to do is to drop the ego. It's easier said than done! If the team fails to deliver potentially shippable product at the end of the sprint, Scrum Master can not fire the developer and definitely can not scream at the team. Scrum Master needs to be diplomatic and understand why the team failed to deliver. A good Scrum Master discusses with the team and understand what caused the failure and will correct the root cause in the following sprint. Scrum Master's authority is limited. It takes experience, maturity and empathy to succeed as Scrum Master.

Another thing I want to point out is "Part-time Scrum Master". If your company has part-time Scrum Master, you are not really following Scrum. I have seen Tech Leads and Engineering Managers acting as Scrum Masters. That arrangement always failed because they have no time to manage the scrum process.  If a Tech Lead plays dual role of Tech Lead and Scrum Master, can you guess what will happen if something is broken just before the product launch? Dual avatar will disappear. Tech Lead will be coding aggressively to fix the code. Scrum Master will be missing in the crisis. Ironically, Scrum Master is most needed in a crisis. There is also another problem that happens periodically when Tech Lead acts as Scrum Master. If there is a production issue or some important meeting, daily scrums will not happen because Tech Lead will be busy with other meetings. 

Scrum Master's job is to make sure team is following Scrum process and there are no hurdles that prevent the team from honoring its commitment for the sprint. Scrum Master needs to do whatever it takes to accomplish that.

How to overcome resistance to Agile process

Change is hard. You can expect resistance if you introduce change. Adapting Agile is no exception. You will get resistance from all levels -- developers, business partners, managers and clients. First step in overcoming resistance is to get the buy-in from senior management before even announcing your intention to adapt Agile. If you can't get that buy-in, all bets are off. Do not even try making the transition to Agile. The transition will invariably fail if there is no support from senior management.

Team members will resist the change because of various reasons. It could be due to lack of job security, lack of awareness or just plain old political reasons. If someone is going to lose his/her hold on the team, that person will possibly resist. This is why support from senior management is vital.

We can categorize the people who resist Agile into two categories. Skeptics and Saboteurs. Skeptics are easy to manage. However, Saboteurs will try every day to make sure your transition to Agile fail miserably. One example of Saboteur -- Developer who is afraid that daily scrum will let people find out how slow (and unproductive) he is.

It's better to listen to the arguments from both skeptics and saboteurs. Make sure that their valid concerns are addressed. Training is essential to make sure that there are no misconceptions about Agile or Scrum process. Skeptics may bring some good points to consider. If you are new to the company, Skeptics may point out potential traps. They may discuss why previous attempts to adapt Agile failed. If you listen patiently, you will gain good insights from Skeptics. In case of Saboteurs, you need to be more patient. Try to address their concerns. If Saboteurs continue to make attempts to derail the transition, you have few choices.

1. Take it to senior management and let them deal with Saboteurs.

2. If you work in big organization, transfer Saboteurs to different departments

3. If you work in start-up, make sure that Saboteurs understand they have no option other than following Agile. If all of your efforts fail, fire Saboteurs. 

Once you change or get rid of Saboteurs, convincing Skeptics is easy. Do a pilot project to implement Agile. Success in that project will get everyone on-board. Success in one project will influence the whole company to adapt Agile. When you introduce Agile, you will hear objections like "It may work in Salesforce. But, it won't work here". Once you succeed in pilot project, all those objections will disappear into thin air.

You should also get the help from people who support Agile in your company. Identify the decision makers and influencers in your company and convince them about the benefits of Agile. If you get few key managers to support your cause for Agile, you should be able to easily handle Saboteurs.

The Scrum

Scrum is one of the Agile frameworks. In other words, Scrum is a conceptual structure intended to serve as a guide for implementing Agile. If you search for "Scrum", most of the web articles you get would discuss Agile and Scrum as if both are one and the same. This is mainly because Scrum is the most popular framework of Agile. There are other Agile frameworks such as Extreme Programming, Test Driven Development, etc., You can read more about other Agile frameworks in Wikipedia.

Scrum is popular because of its simplicity and flexibility. Scrum allows us to focus on delivering the highest business value in the shortest time. The business partners set the priorities. Development teams self-organize to determine the best way to deliver the highest priority features. This "self-organization" is the key to succeeding in Scrum. I will discuss more about this in a separate post.

Another beauty of Scrum is that it allows us to rapidly and repeatedly inspect actual working software, every two weeks. If there are any issues in the product we are developing, we will discover it much earlier in the process rather than discovering it two days before the launch. 

What is Agile

Agile is one of the project management methodologies. Agile means "able to move quickly and easily" in plain English. When we follow Agile in project management, we move quickly to any changes and we adapt to the changes instead of resisting. This approach is very different from traditional project management also known as "Waterfall".

Waterfall approach worked ok for many decades. I have used Waterfall when I worked in Bank of America, Wells Fargo and other banking institutions. There is nothing wrong with Waterfall approach. It just doesn't work as effectively as Agile when it comes to software development projects. Software project requirements are always changing due to marketplace conditions and dynamics in the competition landscape.  It's better to adapt to these changes to reduce the time to market. Agile also provides us the capability to release our product in increments. Agile also helps us to reduce software development costs and to increase productivity. This is why all tech companies got Agile fever!