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!

Project Manager, Servant Of The Team

One fair day, one of our clients asked me over a coffee, what is your competitive advantage? Several answers started in my mind as a slideshow; Project Management, Requirement Analysis, bla bla bla… All jargons! But none of them could delight me, so I asked myself “Really???” and I got “Absolutely Not!” as a kickback. Then after self-examination, it finally alarmed in my mind that “It’s your team moron!”

Yes it’s my team, and without them I can’t succeed and as a project manager, it’s my duty to serve them. Every PM must understand that your team is human at last; they have emotions, aspirations, weaknesses, strengths, attitudes and so on. So while managing project, understand that you need to manage people too. 

More than a project manager perform like facilitator! Try to diagnose and expel all obstacles for your team e.g. Understanding requirements, explaining flows, any infrastructural issues that is hampering productivity of your team, avoiding unwanted long meetings where people are struggling to be concentrated. Do all possible things which will increase velocity of your team and automatically of your project. Serve their all valid demands or problems because your project’s success is built upon them rather than any Gantt Chart!

As people’s manager one should:

• Understand team very closely. Ask them for their ideas, issues etc. Note their inputs and operate on them
•  Understand their career aspirations. Become mentor rather than boss!
• Always give them unclouded views about entire project, vision behind the same
• Motivate them by providing proper appreciations. Performance of people increased when we started performer of the week awards!
• Always be keen about what is affecting productivity of the team
• Handle egos in team well

Nowadays, Agile project management approach gives you more resultant tools and techniques to handle your project, learn them! One of the KRA for project manager is to increase team’s efficiency and create healthy team environment in organization

"The strength of the team is each individual member. The strength of each member is the team" --Phil Jackson

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

Improve Your Software Development: Involve Client ASAP

Historical software development methodology was typically as 

1. Get Requirements
2. Code It
3. Test It
4. Deploy It

In this typical approach (AKA Big Bang Approach or Waterfall model of software development methodology), once requirement gathering is done, coders used to disappear for coding, and clients wouldn't understand what they are actually doing! After lots of sleepless nights coder might think “Whoa! That was hard work! I was working like crazy!” and hence expecting that while showing working piece of software, we will get “WOW! Amazing!” from audience (Clients). However too frequently the reaction was “Yeah this is fine, you did lot of work but what I really expecting or wanted was…..” and from this point all disappointments and project delays start. All rework (Recode, Retest, and Reintegrate!) then starts hampering your timelines and those cost of changes become increasingly high.

Big bang approach usually ends up with big mess. There is an unwritten rule that “If your customer is unhappy, you have built wrong software!” (No matter how great you think it is) and in such cases don’t waste your time in trying to tell them how they are wrong. But then how to find out what customer really wants from you…….simple, “Involve them ASAP”

Secret of great software development is iteration; hence involve client/user during all iterations (Agile Methodology for Software Development) So once you make significant progress you can check it with them and then refine if required or move ahead. As you are getting customer feedback frequently, he is also well aware of the current stage of the software.

Iteration is a frequent check-up of your software! In big bang approach, probably your software gets ready at the end and its utterly wrong time to realize that something went tremendously wrong. With iteration you can immediately come to know that probably you are going wrong.

Consider your each iteration as project in itself or rather a mini project which should involve requirement, design, code, test and feedback. But while doing iterations you should meticulously follow these things  

1. Estimate the new features
2.  Let your customer decide priority for new features
3. Revisit your iteration plan
4. Check timelines

I’m sure that involving customers early into project really helps a lot! Try it! (If you are still following big bang approach)

Good Software Development Delivers What Is Needed On Time and On Budget

Coloured sticky notes, replacement to Gantt Charts

As we discussed about velocity charts in my last post, which helps you for project progress tracking. Tracking will come into the picture, if you plan and schedule your project well. Well scheduled project can be well tracked! Yes so let’s talk about planning phase in this document.

As many of us knows that, Gantt chart is famous tool for project scheduling. Wiki definition says “It’s a bar chart developed by Mr. Henry Grantt in 1910, which illustrates project schedule (Ref: http://en.wikipedia.org/wiki/Gantt_chart). Gantt chart gives you a pictorial view of complete project schedule. Each bar represents a time for particular task and hence help to track them.

We, tried to achieve this simply using quickly available colored sticky notes. Following is the simplest recipe which helps us to track schedule of the projects based on deliveries/Milestones.

Ingredients:

1. White board. If not, any plane paper sheet. 
2. Sticky notes. Better if colored
3.  White board markers

Process

1. Firstly, decide project milestones or deliverable
2. Draw vertical lines equal to count of deliverable/milestones
3. Give short names to each vertical line (e.g. M1, M2… etc.)
4. You can add delivery dates at the bottom of each vertical line (This process is optional, but helps to track the deliveries)
5. Now write each task on sticky notes
6. Now Paste them according to proper milestones. (Between 2 appropriate vertical lines). Pictures below will explain it better.
7. You can even go further and add time to each sticky note i.e. time for each task

Above image will give you a quick illustration of sticky notes based schedule. If you don’t want to use more sticky notes you can use following simple way to track/plan your project.

Above image will show how we managed a time bound project using same technique.

Now,

1.  You can draw arrows between dependent tasks to display proper flow of tasks
2.  Once task is done, you can either put tick mark against it or you can remove sticky note
3.  Involve team in this exercise. Advantage is whole team can get a complete view and sequence of the tasks so if any one has any query, just look at the white board

This colorful schedule tool may help in motivation of your team as it does in mine!

Happy Management!

Software Project Development: How velocity chart helps to track project progress

What is “velocity”? As we all know, it’s the speed of something in given direction. Right? If you are driving a car, we says that it’s running e.g. 60 Km/h towards north. What it means? That means your car has specific speed and specific direction, yes it has velocity.

Similar fundamentals applies to software projects too. Each project must have some speed and some direction which exactly means that each project must run with some velocity. While saying this, velocity means project team must work towards requirements within pre-decided schedule.

Project completion is the function of accuracy of original estimation and progress you have made! Measuring only schedule progress is not enough. If you are running feature based project, best method to calculate progress is how many features are there in the project, how many features your team has implemented, quality of the implemented features, and how many features pending.

But how to measure progress? Big question. For features based project, Velocity Chart is the best indicator. Velocity chart gives you an idea about how much progress is made till now and how much work has left.

If you observe above figure, which is a velocity chart, it is very simple to understand. Following is the process to create velocity chart:

1. X- axis is number of features
2. Y-axis is date (Can be milestone dates/ delivery dates etc.)
3. Now you can add up number of features against expected date as your total features of project
4. As and when team completes a feature, you can increase 1 number in graph against completed. In a similar way you can remove one from pending.(This can be optional)
5. If you want to add more features during the project, you can do the same
6. Ultimate aim is completed features = total number of features or pending features = 0

Velocity charts, measures three things requirements, completed work and duration. It is based on agile methodology, as people can track team’s progress for sprints. In a way, Velocity Chart is your friend! Use it!