Is Pair Programming For Your Organisation?

There are several questions asked when trying to adopt pair programming within a organisation. The most frequently asked question is, is pair programming more productive than a single programmer working on a piece of software. Firstly, before your organisation can adopt this technique they need to be working in a agile environment as this type of programming is a type of agile software development technique. In this blog, we will discuss the benefits and drawbacks of pair programming; thus, provoking the thoughts as to whether pair programming is suitable for your current working environment.

Firstly, let’s discuss what exactly is pair programming. This type of programming is an agile software development technique as mention above. This involves two programming working at a single workstation. One programmer “drives” writing the code while the other “navigates” reviewing the code while providing suggestions. Also, they pick up useful programming techniques along the way. The pair regularly trade roles so work can be equally distributed.

Now there’s a understanding of what pair programming is here are the pros and cons.


  • Having two heads working on a piece of software means if one developer get stuck with a patch of code then the other can assist as they’ll be looking from a different point of view.
  • Silly programming mistakes and defects can be eradicated at a earlier stage. This reduces the time spent debugging which leads to faster development time.
  • It’s a good way of spreading knowledge across the development team. Likewise, if one developer is out of office then this doesn’t cause an impact to development as coding can still be continued by the other developer.
  • It’s a good chance for new team members to get up to the required level as they can work with developers who have a greater understanding of the product.
  • There won’t be a need for thorougher code reviews as the navigator will be reviewing the code in real time.


    • There could be a disparity in skills which could potentially be a problem as one programmer would be doing most of the work as well as as wasting time constantly tutoring the other. The only time this acceptable is when a new member has joined; However, there shouldn’t be any mentoring.
    • When programmers have a rapport these pair programming sessions can easily turn into a social session which means no development actually gets done leading to a decrease in productivity.
    • More experienced programmers can try impose their ideas and views which can leads to more time being spent trying to settle disputes.

Enter your email address to follow this blog and receive notifications of new posts by email.


How To Do Requirement Elicitation – Part 1

This blog will look at two useful elicitation techniques that Business Analysts (BAs) use to obtain information and most importantly how to do it properly. Requirement Elicitation is an active effort to extract information from stakeholders and subject matter experts (SME).


When setting up a Brainstorming session ensure there is a time limit. This should be a visual excercise where the partcipants use something such as post it notes to write their ideas and place them on a white board. The size of these meetings should be from (6-8) people. Ensure there are clear ground rules; a way to rate ideas and limit the amount of evaluation going on in these meetings as Brainstorming is about highlighting and then categotising those ideas in order of prority.

It is important that you;

              “Encourage the partcipants to

                write down as many ideas as

                they can.”


When interviewing ask questions geared towards uncovering information. Formal or informal type questions can be used. Open ended questions should be used to find information and gaps while close ended questions should confirm and validate.  A successful interview will be so because the interviewer has conducted proper research around the interviewee(s). The interviewee needs to also feel relaxed in order to provide the information you want therefore, as the interviewer there is no harm in asking whether the interviewee would like some water or coffee etc.

Enter your email address to follow this blog and receive notifications of new posts by email.

Developer And Business Analyst Communication Part 2

This blog will go into more detail around techniques and tools that Business Analysts can use to ensure they are being understood amongst developers. This especially holds true for situations where there are various journey flows that need to be considered which generally means it can be a complex piece of work.

Process Flow Diagrams

One of the ways Business Analysts can explain processess to developers is via the use of process flow diagrams. This is very effective because via accurate; start points, end points and explanations of each step with clearly detailed decision points, this breaks down the whole experience from start to finish. This enables the developers to understand if there are any gaps that need to be filled or other factors such as error state messages that may need to be considered.

Use Case Diagrams 

This is another good visual aid that can be used to communicate the interaction that can take place in relation to a particular software/application. This diagram consists of a; system boundary, a set number of users and various lines being attached to a particular interaction with the software/application within the system boundary. This is used to understand how the user interacts and help the developers understand what the software is able to do. These use case diagrams tend to be drawn step by step because this is alot easier for the developers to follow in comparison to combing these steps together.

Developer And Business Analyst Communication Part 1

In most IT organisations there are teams that comprise of Business Analyst and developers, the communication between these two sets of groups is very key. When a Developers (Dev) understands the business context and the Business Analyst (BA) understands the technical difficulties the implementation for the application/software will be appropriate; thus producing quality software with the aid of software engineering principles. Undoubtedly, there will be issues that are not foreseen but if BAs and Devs are constantly communicating then these issues can be taken care of relatively quickly. From a Developer’s standpoint there are a few ways in which you can improve your communication with BAs.

Appropriate Terminology

As a developer we often forget that most BAs aren’t as technical as developers. So, expressing your views using technical terms can lead to BAs continually asking questions as they didn’t understand first time round. This can waste time as meetings need to be booked to go through what should have been understood in previous meetings.

As a Dev the first way in which you can fill this gap and prevent time from being wasted is by using more business friendly terms. However, if this isn’t possible it’s good to use analogies as there’ll be a common denominator which brings clarification between both parties.


Presenting demos to BAs is a very important form of communication, as these demos show a working software in which the BA can see whether the acceptance criteria has been met. Off the back of these demos improvement can be found which can steer the direction of the next feature.

Over a period of time as the team matures BAs and Devs communication will start to be smoother and there will not be a need to explain things as thorougher. Developers will be able to use these technical terms as BAs will have analogies to put to them. In short, BAs and Dev can conclude that the piece of working software produced will be of quality as understanding of the product is clear.

What Questions Should A Business Analyst Be Asking Stakeholders

This blog will look at the sort of questions that a Business Analyst (BA) should be asking when speaking to stakeholders. It is very important that a BA asks the right sort of questions to obtain accurate information.

1. What are the biggest challenges in your role? 

This enables the BA to be able to understand what the difficulties are and why this potential project being proposed will add value. Asking a question such as this also allows you to identify organisation type problems and enables you to handle them effectively when working on a new project.

2. What changes are happening internally and externally that could effect the project? 

It is important to ask stakeholders that actually understand what could effect a project in the organisation from the; legal, technological, and political side in order to ensure projects run smoothly and reduces the chances of the project being pulled. Many projects run the risk of collapsing because they run in silos and fail to appreciate the importance of being able to adapt to other project pressures.

3. Describe how the process currently works?/What is your opinion on the current process? 

It is important to obtain as much information as you can from the subject matter experts because the more as the BA you can understand, the more insight you will have on how to do things better. It also helps to ask them what they feel of the current process because they may have really good ideas that may just need refining or ideas that you did not think about that could also add value to the new project.

Why Kanban Works In The Software Development Industry

In this blog the topic will discuss the benefits of using Kanban principles in an Agile environment. Kanban has been used for decades in other industries such as the car industry and has now been simplified to work in the IT industry as well.

Why use kanban? 

Kanban is used because it enables the development team to not over estimate on their ability to complete work. Kanban matches its work in progress (WIP) to its teams capacity. Kanban uses a; to do, in progress and a completed board concept. Kanban can use virtual boards or physical boards with post it notes to show the work across a particular sprint or even across a whole project of work. .

The key advantages of Kanban 

Kanban is useful because by managing the work in progress to team capacity this enables the team to have; flexible planning options, faster output, clearer focus, and transparency throughout the development cycle.

Three Skills Critical To Be A Good BA In 2017

This blog will highlight three important skills that a BA must have to be able to  add value to a new or an existing project.

1. Understand the basics 

In order for a BA to be resourceful in whatever project they are assigned to they need to be; good communicators, be able to think critically, and need to be able to ask the right questions to obtain the information needed to progress an epic or a feature within a project.

2. Grow their use of tools 

There are never enough tools that a BA can understand and a good BA will be able to use the best placed tool for the business objective/meeting that they are working on. A good BA can also advise if meetings can be done in a more effective way and techniques to obtain the most necessary information from a meeting.

3. Resourceful 

A good BA even if they do not know the answer will find out through good communication the people in the business they need to speak to. A good BA will ensure they know the current templates and the business goal of the business and from there build their own work templates around that.