Resolving Conflicts

As a BA you are constantly in a position where there are conflict whether the conflict is in requirement, conflict in design, conflict in implementation or just conflict in management, they are just everywhere, to be a successful BA, you will have to master the art of resolving conflict.

Conflict resolution can sometime take up 10-15% of my BA time but I find it very challenging and most of the time I am happy with the results after the conflict is resolved. Most of people think conflict is bad, unproductive and unhealthy in an organization, I would like to take a different approach, I believe conflict is natural and healthy it means people are thinking, as long as conflict are resolved on time, it can help make changes for good.

Everyone has to deal with difficult people from time to time, they want to be heard, and with the right strategy it is possible to reach an agreement with them. I will go through some of the strategies which I have used in past whenever I am in a conflict situation.

Stay calm no matter how heated the discussion gets, how angry the person gets, you should never lose your temper, try to stay calm and collected.

Let the other person do most of the talking, sometime all they want is to speak up and get it out, do not interrupt them or try to correct them when they are talking, after they finish acknowledge that you have heard what they have to say by saying something like “I see your point, if I understand it correctly what you are asking is ...”.

In a conflict situation people tend to bring in past experience, and imaginative facts and figures, do not try to defend and correct them, just think of them as red hearing and move on. Do not be the judge or try to take side, try to look for the cause of the conflict and not the symptoms of the conflict.

Silence is a very important strategy for reacting to conflicts. Acknowledge the possibility that you could be at fault even if you don’t think you are, on the other hand if you think you are at fault try to ask yourself as to where you are at fault.

Pay extra attention on your body language, you body gives messages when you think they are wrong or you don’t like what they are saying, relax your body and face.

If for whatever reason, the argument becomes verbally abusive, just calmly terminate the discussion and let them know that they are very angry and we will have to continue this discussion later, gracefully excuse yourself from the meeting .

I always believe that every conflict I came across provided me a means to learn and has made me more mature, conflict resolution is a skill you must learn for your own good, it is very crucial to become a successful BA (and as a person). That reminds me a quote from Carl Gustav “The greatest and most important problems of life are all fundamentally insoluble. They can never be solved but only outgrown.”. So true!

The Art Of Negotiation

While doing my Business Analysis I have found that negotiation skills are very important and very crucial part of your role. As a BA you need to master the art of negotiation, you will have to use that skill at various stage of the project, you negotiate with the sponsor with the scope and delivery dates of the project, you negotiate with the project manager to get appropriate resource and on time, you negotiate with the development team with the features to be development and if you are lucky to get this far, you now negotiate with the QA team to ship software with least number of defects.

One thing you have to learn and believe as a BA is that nothing is set in rock, you can and you should negotiate at every possible stage of the project to achieve the best outcome possible.

Some people are natural at negotiation whereas other people need to improve on it, most people see negotiation as negative and tend to avoid it, but it is not about doing the least possible or being difficult, it is about making sure all the party involve are happy, and everyone gets something out of it.

You should be very careful when negotiating, your body language, your tone and your approach is very important. Try to put yourself in other person's shoe that will help you to understand the other person's view, treat everyone as you would like to be treated.

Before you start negotiation sit down and list of following things

• Make a list of every single topic to be negotiated.
• Make a list of topics which should be avoided during the negotiation.
• What are your needs (and not your wants)?
• What is the minimum you want to settle for?
• How far are you prepared to go?
• What is available or possible?

Knowledge is power so make sure you know as much as possible about the thing you are about to negotiate, ask around if anyone else has done it before and what was the outcome, don’t let the other party blind you with technical details, stay focused.

Always remember 'Relationship before task', spend some time with other party to understand their need, always empathise with their problem, avoid and deal with conflict as soon as possible. Always explain to other party why and what are you negotiation for.

Negotiation is not about 'YOU' or 'ME', it is about 'US', be flexible, do not try to drive too hard, make everyone involved feel like a winner.

How do you know that your negotiation was successful?

Well there is no great answer for this but if both parties seem happy with the outcome, which fits into the project goals, I will say that’s good.

In the end don’t forget, negotiation is truly an art and not science, negotiation skill can be improved even in your day to day life activity (some time you are doing it without realising it) like negotiating for a mortgage, car or even insurance. All the best.

Being ScrumMaster (Daily Scrum)

This week I was ScrumMaster, so that makes an interesting topic for me to talk about, one of the ScrumMaster's main job is to facilitate the daily scrum meeting, don’t forget ScrumMaster is also a member of the scrum team.

As a ScrumMaster make sure that the venue where Scrum meeting are held is consistent, changing venue can cause unnecessary delay, also do not change the time of daily Scrum, no matter what happens around in the company, daily scrum should happen at the same place, same time (it is ScrumMaster's job to ensure that everyone attends the daily scrum).

Ensure each scrum member answers the following questions in the daily scrum

• What did they work on since last scrum meeting?
• What are they planning to work until next scrum meeting?
• Are there any issues they would like to highlight?

Try to have daily scrum next to a while board, record what team members are working on today and not what they did yesterday, ask them status about tasks they were working on since last scrum meeting. Make sure that the burn down graph of the sprint is updated, if there are any other status (e.g. Build Status, Regression Test or Bugs reported) update them on the white board for everyone to see.

To be a successful ScrumMaster please ensure the following

• Resolve conflict between team members as soon as possible.
• Ensure everyone is heard and has opportunity to respond.
• Ensure people do not get too much in to the details.
• Daily scrum is to report progress and raise problem (not to solve them in the meeting).
• If the sponsor is attending the meeting they are only listening (they are not allowed to talk).
• The only people allowed to talk are the one who are working in the sprint.
• Normal meeting etiquette is observed.

The most important thing for the ScrumMaster in the daily scrum is to keep track of time, there is no rule (at least that I am aware of) as to how long the daily scrum should last, at our place we have about 12-15 team member and the scrum lasts about 15 minutes, so I would recommend about 1.5-2 minute per person.

Some of things you should watch out and address during daily scrum

• Team member are providing status to the ScrumMaster rather than team.
• Team member don’t look motivated.

Team will not feel passionate to attend the meeting if they feel that ScrumMaster is not interested to listen to them, with that thought I will take your leave until next time... bye for now.

Technical details in a requirements document

The thought of writing about how much technical information should contain in a BRD (Business Requirements Document) came to me yesterday when I was working on a requirements for a new feature for our product.

I come from a technical background, but not all business analysts comes from programming or technical background, I feel both categories of BA have advantages and disadvantages, especially when you are working for a software company.

Let me stick to the topic and focus on BA with technical background, I feel when you start the requirements document it should be entirely based on business outcome and you should not think about the solution or any other technical details, this ensures that your document covers all the business needs and is not compromised by technical limitations.

If your company promotes and allows JAD (Joint Application Development), then you will have to talk to the technical team, I found it very handy if you are able to talk the technical language, but getting too much technical could risk the business focus. On the other hand based on my experience technical team are a bit reluctant to document technical details in that case documenting technical information can be very handy (QA team will thank you for that).

Personally I would rather focus on defining requirements clearly and free from ambiguity then worry about technical details, but BA needs to understand the design concept, in past I have experimented with semi technical document by adding Workflows, UI, Data Modelling and sometime ERD diagrams, that has worked in some cases some and some cases it did not, you will have to use your judgement as to how far you need to go on the technical side, it may also depend upon your audience, too much technical details makes it difficult for a business user to review,understand and verify the requirements.

There is also some overlapping between functional and technical, what is technical to BA is functional to the development team, BA usually have to write functional and non functional requirements so sometime there is no way out but to write technical details.

So in short depending on the willingness, skills and experience, BAs can choose to be more on the technical side or stay focused on the business side, a balance of both side is what I will recommend.

Managing release day

Typically in a software company there is a dedicate 'Release Manager' - a person who manages all the projects and make sure they all come together in the software and that the software gets shipped on the release day, but does the buck stop at s/he ?
I think companies should have release team where there is more than one person to manage the release cycle (now of course that depends upon how big is the release cycle and how often it is done).

Software release can be very complex, may involve many small projects, to coordinate, scope of the project can change based on available resource and customer priorities, the main role of the release team is to ensure that the software being released meets customer requirement, all small project are included, and the most important thing is to release on time with highest quality possible.

The software release team should be decided earlier on the project and each person should have a clear responsibility within the release cycle. Often QA team leader or project manager is the best person to be the team leader of software release team. Software release team leader should be expert on interdependencies and various integration issues, s/he should be very familiar with the product to be able to analyse the impact of release on each and every customer, this information is very crucial when the software has to be released with known bugs (I know no one accepts this but it has been the fact of software release)

Some of the role/things to be managed by the release team are as follows

• Who is the Build Master (ideally there should be one complete build every day)?
• Who is responsible for the installer?
• Who is responsible for releasing the software and ensuring the software is delivered to the customers?
• Who is in charge of the release/installation document?

If all (or most of the above) is planned and executed there may not be any surprises on the release dates.

Quality Of Software

Many placed I have worked in past, software quality is often talked about but in reality it is always compromised mainly for cost and time reason. The usual explanation is that since the turnaround time to fix the bugs are not that high, there is no need to spend more time on testing. Market research has shown that organization, who invests heavily in testing procedure and tools, reduces cost long term since they are not constantly going backwards and fixing things over and over again.

Even in an organization where this is a QA team, often quality starts and finishes with them, I feel quality is responsibility of the entire team, which includes management and BAs, and of course developers. Try looking at your development cost and chances are that 60% of the development resource is spent on identifying and fixing defects. By not introducing defects in the system and implementing proper tools and procedure to identify them earlier on, development cost can be reduced and eventually increases team productivity.

Quality should be enforced right from the beginning of the project (yes even in requirement gathering phase), project leader should focus more on quality rather than quick delivery.

To conclude this blog, there are various level of quality required for software, some mission critical software needs to have close to 0% defect, where as some software can handle more. Quality is an ongoing process, which should be built in to the SDLC, quality should not be looked as burden and requires commitment right from the top level management. Any testing tool can identify the defect but only the ones which falls under the testing criteria, most software are so complex (at least the ones I have worked with) that there is no way you can test the complete software, in this scenario implementing good quality business process (along with testing tool) is the way to go.

Shorter Release Cycle

Quality of software can be improved over a period of time by introducing shorter release cycle (I am experiencing it first hand at my current workplace). It is a known fact that software has defects, there could be many reason for that, bad requirement, poor coding and not enough testing, fortunately over the last decade or so people are so use to defect they have started accepting it in some form or another.

Defects which are left in the software too long becomes an undocumented feature and when it is fixed you are bound to upset some of the customers.

Introducing shorter release cycles ensure that software gets out of door more often and chances of identifying defect increased, which in turn means more (and timely) opportunity to fix them. This also means that no defect is left long enough to become a feature.

Shorter release cycle also means more excitement to the development team, users and market, it enables team to release new feature in a controlled fashion to get a feel from the market before you invest heavily in any given functionality. It also give you more opportunity to catch up with your competitors.

Releasing web based software could be much easier, fix has to be deployed only once, and is available to everyone instantaneously, but there is also a downside one defect introduced and everyone is affected immediately, frequent release can also upset web users as no one likes to put up with changes every day, but it gives you an excellent platform to change user habit slowly over a period of time.

Releasing software more often can also pose some challenges to the internal team as well as customer, since customer has to upgrade more often it also creates a sense of uncertainty (as they say 'known enemy is better than unknown friend’), but over a period of time team and customer will get use to the release cycle and will start seeing the value. The key is to release software timely without compromising innovation and stability.

On the final note regularity = reliability = happy customers.