Agile Mind-Set

I was one of the out at elbows victim of traditional approaches of Project Management. Howsoever I tried my best; every single time I failed due to some or the other reason like poor estimations or unrealistic schedules or hard technical issues etc. etc…. Many such enemies out there!

Out of the curiosity (Frankly, out of the need) I came across Agile and SCRUM. I started going through many interesting books, articles, web courses etc… loads of material!

Feeling awesome! Good stuff and very useful. But now it’s a time to actually implement it!

2 simple (at-least appearing simple at the very start) questions in front of me;

1. Where to start?
2. How to start?

This called an interaction with few of my contacts and friends who were already using SCRUM in their organization. I created a list of them (Some SCRUM Masters, Product Owners and some are part of Dev. Team) and started conducting informal discussions over the coffee(s).  Here are some of interesting conversations to my question:

Me: Hey hi! I am aware that you guys use Agile in your organization for software development. I am excited to use the same in ours. So could you please help me to understand it and how to start? What to do?

Mr. A: Oh man! Please don’t go for it. It’s a myth. We always landed in following traditional approach some or the other way! ( Shocking!!!!)

Mr. B: Nothing great to do extra for a start… Rather I would say just start it! (Paradox??)

Mr.C : Oh good that you are going Agile. Create Sprints, Maintain Velocity, Deliver! (Wow! First relevant answer I felt. :)) but make sure you don’t waste your time in retrospective etc. Keep it minimum, it’s a waste of time!!! ( Big Shock! Same guy saying this???)

I was really down after meeting these guys and started re-thinking like, did I understand SCRUM correctly? Or are these guys doing something messy under the name of SCRUM? Then I met my previous mentor and asked the same question. He counter attacked! (Check below)

Me: Hello, Nice to see you after so long. Actually I am interested in implementing SCRUM in our organization but I am very much confused about from where to start. I met few (so called) experts, but they could not gratify me so that I can buy it.

Mentor: Oh good that you are planning to go Agile. (Worried here! Same start as Mr.C) Does your organization and stakeholders wants the same? (Oh man, never thought of this!!)

Me: Umm… I am not sure. I mean they would love to because ultimately this will give them better results. Right?

Mentor: You can’t assume it. You must understand their mind-set first and you need to sell the Agile if they are not ready to buy; and believe me, it’s not really tough to sell!

Amazing! I never thought of this. Now the job is bit tougher to first extract the mind set of organization and people involved. Whether they want to do it or not?

Fine day while sipping a coffee, I initiated a topic with my manager that “I think we should try SCRUM instead of our traditional approach”. He glanced at me like someone has added pinch of salt instead of sugar cubes in his coffee!

Manager: Why do you want to do so?

Me: Look, anyways our current method is not giving us glorious results, so why can’t we try something which will reduce context switching, will give us good pace, and continues integration and better quality deliverable. Moreover we will work as a team so success or failure whatever it is, it’s a team’s responsibility not only Project Manager’s (Saw shinning in his eyes. Probably a first win!)

Manager: Hmm… I have heard of Agile many times but never thought of trying it. Still this doesn’t allow you to start it. How can we convince business stakeholders?

Me: Good question. If I say this approach will bring more transparency, early risk mitigation, continues improvement and last but not the least that change will be now embraced instead of negotiations and disputes, don’t you think they will allow us to buy it?

Manager: What about team? They are so used to our method; will they accept this new method?

Me: Very first, it’s not a method, its framework.  A framework, which holds certain practices and methods inside it. We can shape it as per requirement without disturbing core concepts and as we are working as a team and everyone is responsible so they will get rid of dictators like us ;) instead we need to work as their servant. Will this not astound them? No longer “Us vs. Them” in any sense as even client will be involved truly with us.

Manager: Cool! Seems interesting. I am still not sure but we can try it out. Let’s see how organization and team feels about it. I will also research about it more and will see where I can help here to make this possible.

Me: Thanks man! This calls for one more coffee? 

This story demonstrates that it is very important if you want to follow agile, everyone should be ready for the same. It cannot succeed if only you are excited about it, everyone else must! Even you also should not go for its just because it’s a buzz word or a trend but try to find out real values of it and try to follow it from the bottom of heart.

As said by Mike Cohn, “SCRUM is an Agile framework that allows us to focus on delivering the highest business value in shortest time”

As I understand, SCRUM is very light-weight, simple to understand but extremely difficult to master unless you have people with you who are ready to share equally. You must try that everyone will believe in it. How?

• Explain underlying values to each and every one. Agile has set of values so make sure you will tell them in what they are really interested and what they really want to listen. (Categorize those values and deliver based on set of people)
• Help them to understand that change takes time! It does not happen overnight!
• Talk about engineering practices involved

Anyone should use SCRUM when it is really appropriate and must use it correctly else you will be in double mess!

I spent almost 3 weeks with stakeholders and the team to explain them these scenarios, benefits etc.(rather was changing their mind set) and they got convinced and really ready to help me as a team to whatever extent possible!

Believe me…. SCRUM is not tough to sell… Try it! Do it for all… Do it together… It’s good for all!

Let Your Software Development Happen With Minimum Meetings

How many of you have ever faced situation like you are doing something productive and manager calls for meeting. “Let’s have a meeting” is an often response for any situation in many organizations. Although scheduling meeting may be a right solution in many cases but not best fit always!

It has been observed that person takes about 15-20 minutes to get back from interruption and focus again. This means unnecessary meeting for 15 minutes will waste developer’s 30 minutes actually and this may create stress and frustration. As a project manager it’s your duty to avoid unnecessary meetings if possible & for that you need to decide whether the meeting is really necessary or not. I generally use following simple flow chart to decide whether meeting is needed or not.

Following should be quick pointers for meetings

• Check Availability: Always check availability of people, room etc. well in advance before meeting to avoid wastage of time.
• Avoid Informal Communications: Generally try to avoid informal communications during the meeting period. You can have them prior or after meeting. 
• Don’t discuss solutions: Even though meeting is the place to point out problems and issues, generally don’t spend time in finding and discussing solutions in meeting. Let concern people sit together and create solutions later. 
• Don’t go off the topic: Many times it happens the people start diverting meeting topics to something else (knowingly or unknowingly), as a facilitator it’s your job to avoid such scenarios and get back on the road
• Time: Don’t let your meetings run out of time! We all have fixed deadlines for all tasks and hence don’t let your meeting hamper them.

Understand, many times people may not want to attend meeting, just because they might be really deep into something really important e.g. some piece of code, some architectural flow design, some analysis etc. Keep in mind meetings never write code!

As explained in Agile Methodology of software development, try to conduct daily SCRUMs. 15 minutes stand-up meeting is usually enough for planning a day. You should ask 3 questions to team:

1. What happened from last daily SCRUM?
2. Are there any impediments?
3. What the team is going to handle till next daily SCRUM?

So if you are meeting oriented software project manager, it’s not bad but try to limit your meetings where they are really necessary