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.

How to make transition from Waterfall to Agile

Waterfall to Agile transition is the hardest one. If you are starting a company with young programmers who are not exposed to any processes, it's easier to get the entire team to adapt Agile. If you are introducing Agile in a company that followed Waterfall for 20 years, you will most probably fail if you are not prepared well.

First step: Get the buy-in from senior management. If the senior management is not willing to approve Agile publicly, you will most certainly fail in your efforts to implement Agile. Support for Agile should come from your CIO, CTO or someone in that level. If they are not willing to support you, it's better to stick with Waterfall.

If you get the buy-in from senior management for Agile, start small. Take one development project and start implementing Agile Scrum in that project. Train entire scrum team (developers, product owners and any other stakeholders) in Agile practices. It's a good idea to conduct 90 minute Webinar or Power point presentation to entire scrum team before the start of the project. Do not expect the team to follow the process from day one. There will be tons of resistance from developer to product owner. Be prepared to address their concerns. Some of their concerns are related to uncertainty and some are political. Deal with each concern diplomatically. If you start implementing Agile Scrum across all divisions of the company at the same time, it will be overwhelming to educate and adapt at the same time. Salesforce has done that successfully; however, I think that is the rare case. See Salesforce case study for more details. 

I am amazed by the way Salesforce implemented Agile across all divisions of the company and succeeded in that. For the rest of us, following steps would make more sense to make the transition from Waterfall to Agile.

1. Start small. 
2. Take one development project with less than 10 developers. 
3. Train the team and product owners in Agile practices. 
4. Conduct all required sprint meetings. 
5. Make sure the team attend daily scrum. 
6. Try to do 2 week sprints. Keep the sprint duration consistent.
7. Conduct Sprint retrospective meeting after every sprint
8. Evaluate performance metrics after every sprint. 
9. Make sure team creates potentially shippable product after every sprint.
10. Listen to the team and make sure that scrum is getting the best out of the team and not placing additional hurdles.

If you follow the above steps sincerely, you should be able to produce concrete results after 4 sprints and be able to convince senior managers about increase in productivity and speed to market.

JIRA or NO JIRA?

What is the best way to track scrum projects? For your first scrum project, it's better to stick with the post-it notes on the wall to track the progress. There are so many software tools available to track scrum projects. All of them are going to do more harm than good for the team that is just starting with their very first scrum project.

I am using JIRA/Greenhopper to track our scrum projects. JIRA is basically a bug tracking system. Greenhopper plugin can be added to JIRA to track agile/scrum projects. Greenhopper helps us to build product backlog, create scrum/kanban boards, create burndown charts and so forth. However, for the team that is new to the scrum, JIRA/Greenhopper is intimidating. Team has to learn Scrum and Greenhopper at the same time. This will basically demotivate lot of developers. Moreover, there is a psychological benefit in physically moving the post-it notes from "In-progress" column to "Done" column. You will not get that in any software product.

I am not against JIRA/Greenhopper. It serves the purpose although there are some hiccups along the way especially when it comes to creating burndown charts. However, when you introduce scrum for the first time, try it low-tech.... Just post-it notes (4" x 6" or bigger) on the conference room's wall.

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!

Introduction

Hello and Welcome! My name is Ram. I have been managing software projects for 14+ years. I worked in various technical platforms and used different project management methodologies. I have used Six Sigma, CMM, Waterfall and Agile Scrum. I love to spread agile gospel. This blog is one of the channels I use to spread agile.

I am an agile practitioner. You will not see any academic style writings here. This is all practical stuff you can use it in your projects. I hope that lessons learned in my battlefield would benefit others.

Go Agile!