Iteration Retrospective

Retrospective is an agile process which allows the team to stop and look at what they have been doing and ways to improve.

There are many types of retrospective depending upon when it is done; if you do a retrospective at the end of the iteration it is called iteration retrospective.

The main goal of the retrospective is to discuss with the team what went wrong, why and how can we prevent it in the future. The outcome of the retrospective may change the way you execute the next iterations.

There are 3 fundamental questions which the team should be asking

• What went well in the iteration, which we should continue doing?
• What should we stop doing?
• What should we start doing?

Please note the order of the question it is very important for the team morale to talk about success first before discussing the bag things.

By discussing the problem and suggestion the team can change the way they run the next iteration and eventually grow and be more responsive and productive. A retrospective should be plan for about 30-40 minutes, ensure the time and location used is convenient for every team member to attend, this meeting should not be optional. Shareholder, Business Unit, SME, BA, Developer, QA in fact anyone and everyone who was involved in the iteration should be attending the meeting, you may invite customer in the meeting depending upon their involvement.

Retrospective should not be a blame and shame session, it is not about who did wrong, it should be all about how can the team improve based on the team experiences. Team members should not be scared to speak up and admit the things which were done wrong.

Get feedback from the team members about the retrospective to make the retrospective better for them and finally don’t forget to thank the team to be open and honest.

Critical Appraisal

Critical appraisal is the done at the end of designing phase, the main purpose of this task is to do a final check between proposed solution and physical design, this task along with solution walkthrough gives the stakeholder and the team a common understanding and also the opportunity to identify any missing requirement and most importantly to validate the proposed solution.

The following people (or group) should be attending this meetings

• Business Analysts
• Stakeholders and SMEs
• Business Users
• Development Team

Some of the advantages of this process are

• Confirming the Business Requirement.
• Confirming the physical design.
• Improve stakeholder’s confidence in the project.
• Identify any people or organization problems.
• Identify any function or data problems.
• Identify any performance or workflow issues.

The main topic in this process is to match logical and physical design, if there are data models created, make sure the domain is complete, there are no duplication or redundant data, identify any relationship problems.

The final question BA should ask the team is ‘Does the proposed system meet the organization goals?’. Always remember it is easier to change the design and solution on paper than to change few hundred lines of code.

Preparing Business Case

Developing a new product or functionality involves ensuring the money is spent wisely and that there is proper ROI (Returns on the investment). A business case is a detailed report used by the stakeholder/sponsor to justify the need of the project. The report should provide all the relevant information in an easy to understand format. In some companies business case is a must to receive funding and go-ahead for the project.

A business case is used to support a particular course of action when there may be several different options; the most important aspect of the business case is the cost-benefit analysis.

Identify your audience early in the process; you will have to address each audience's need, concern, expectation and level of understanding in the document.

Cost Benefit Analysis should be broken down into two categories, 'Direct Costs' and 'Indirect Costs', list all the topics under each category. With my experience sponsor loves valuing in dollars, try to work out each of the cost and benefits in dollars.

Although there is no official format or one that works for everyone, I can suggest you to structure the document in the following section

• Background
• Effect/Risk of the problem
• Costs and Benefits
• Proposal
• Impact
• Conclusion/Recommendation

Other factors which should be considered in the business case are

• Financial (expense and revenue)
• Corporate commitment
• Quality
• Customer pressure/satisfaction
• Industry pressure
• Legal compliance

Finally these are some of the questions which should be answered in the business case document

• Why are we doing this project?
• What is the problem this project is trying to address?
• Are there any workarounds or alternates?
• What are business benefits?
• How are we going to solve the problem?
• How much it is going to cost and how long will it take?
• If we do this project, what are the risks?
• If we don’t do this project, what are the risks?
• If we need to measure success how will be measure it?

Try to answer the questions above in the document to create a good business case proposal. In the end of the document make sure you summarise the problem, costs and benefits of the proposed solution, the document should be structured to highlight that the benefits outweighs cost.

See you next time.

Crash Party

I know what springs to mind when you hear 'Crash Party', but I am not talking about gate crashing or going to a party you haven't been invited. I am talking about Crash party before the release of the software, so let me start by explaining what is a crash party and why there is a need for one?

Testing plays a crucial role in the successful delivery of today’s complex, heterogeneous, business-critical software systems, as software get more and more complicated, there is a need to improve quality which poses challenge to the QA team, crash party is yet another way to improve quality.

Crash party is another form of collaborative group testing when a group of people (Developers, BA, QA, Support) gets together for a limited amount of time and test the functionality of the product with the intention to find as many defects as possible, it works on a very simple principle that when multiple people are using the system in a non predictable way, they are bound to find workflows (along with defects) which hasn't been thought, documented and/or tested before. Some Crash party may use a predefined script (e.g. UAT ) for the testing. Crash party can also be used for load and stress testing.

Crash party is an excellent way to bring team members up to speed, get them familiar with the area they haven’t work before, and the most important thing is to make them feel a part of the entire product.

Each team member participating in the crash party may be given an area of the product to test. Give cards or paper to each team member to record the defects and the steps to reproduce it, I would highly recommend you to not introduce any electronic bug recording system during this process, the reason being it is easier to write it on a piece of paper and expand that later once the crash party is over.

One of key things to ensure in a crash party is to make sure that the test cases and/or areas are evenly distributed among the team members and to avoid repeated test steps. Also make sure you are not executing any steps which have already been tested by automated tools and regression testing. Always tell the team member the goal is to find what we haven’t found before, 'we don't know what we don't know'.

After the Crash Party is completed, compile a list of defects found during the process, there may be some defects reported due to incorrect data entry or workflow, make sure you discuss that with the BA to ensure the defect is still relevant. The next and the most important step is to prioritise the defects to be fixed before the release; the ones which can’t be fixed in the current release will be flagged for the next release.

Finally software testing is an art, testing practices have not changed since last few years, but the tools and techniques have, complete testing is infeasible, so try to implement quality at every stage of development.

Agile Vs Waterfall

I am pretty sure this topic has been discussed many times and is there a clear winner ... I guess not.
I have been working with waterfall methods all my life and more recently with agile, if I have to summarise they both have their advantages and disadvantages.

I thoroughly enjoyed doing analysis in a water fall method, partly because you were given the opportunity to think and discuss solution upfront, so more time was spend doing the requirements gathering this works really well where project has limited resource (time or money) and clear objective.

On the other hand the disadvantage with the waterfall method (more so in the current era) is that it is not as versatile as agile. Business are growing (and some of them are shrinking), as day goes by there are new competition in the market, new legislations and other factors which affect the company and needs to be responded immediately, in this type of environment agile allows quick and timely changes.
Agile also allows team to delivery solution to the QA team and possible to the customer quicker than the waterfall method.

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.