Ways to improve meetings held for conflict / issue resolution

What I write below may seem like common sense, the kind of stuff that you would get if you were to sit back and think about how to do a meeting. This is even more important if you were to read my previous post (Reducing the number of meetings held) about how to make an effort to reduce the number of meetings that are held, which can suck up the time available with the development and testing teams. In addition, with the number of meetings being held being high, the continuous time that the teams need when they are in the middle of something gets interrupted and this can have an incredibly bad effect on productivity.
During the tension and stress of an ongoing software development cycle, teams need to resolve issues fast. As a result, when there is some kind of issue that need resolution, teams forget all the basic concepts of how to setup a meeting, what are the preliminary steps that need to be done before starting a meeting, and the net result is that even though conflicts are resolved or atleast progress made, the teams end up spending a large amount of individual time on these meetings; and we know the impact this has on the team productivity.
So what is to be done in the case of some conflict or issue that needs to be resolved. Even though it may seem logical to quickly call a meeting to get a solution for the issue, this method should be retained only for those issues that are of a show-stopper nature (for example, a defect that is stopping the launching of the application, or something equally similar). In most other cases, if you spent a bit of time, you would realize that an hour or so before the meeting can help make the meeting more productive. What are some of the steps that could be done before the meeting ? In the below steps, there may be multiple people who may need to be consulted depending on the steps (these could be team leads, project manager, development manager, quality manager, etc)
- For the issue, need to identify the people who are most competent in the issue and who would be able to contribute the maximum to this issue
- For these people, need to identify whether they are available or are involved in some other critical issue. If they are so heavily involved that it would not be good to get them out of whatever they are doing, then somebody else who can provide a solution or inputs would be needed to be identified.
- Next, a brief write-up about what the issue is would need to be written up, especially focusing on what the problem and if there are any elements of a possible solution; and this would need to be sent out atleast an hour or more so before the meeting.
- Before sending out these items, the meeting that needs to be setup should also make it clear as to who all is important for the meeting, and who would be optional for the meeting. What this does is to give team members a say in whether they need to come for the meeting or not. In most cases, what would happen is that team members who are on the optional list would evaluate whether they can contribute or not and decide accordingly. This atleast helps in saving time for those who decide not to come, and even those who come for the meeting are more informed, which makes for a quicker meeting and hence more saving of time. 

Ensuring the minimum number of meetings necessary ...

In software companies, if there is one item that is necessary, it is the concept of meetings. Meetings are the life blood of companies, and sometimes, one feels that the number of meetings that are held are excessive. In my experience, I have had developers and testers coming and complaining that the number of meetings that they are being invited to is so excessive that they feel the time involved for work is getting impacted. Even further, when a person is getting into the core of their work - whether it being the design of a new feature, or the solution of a difficult defect, or the execution of a difficult test case, facing a break in between is guaranteed to rankle. And there are numerous meetings where the team members (developers / testers / others) could be called for meetings, where it would seem that they are necessary.
Some of these meetings could be:
- Feature discussion meetings (numerous)
- Schedule planning meetings
- Task definition meetings and estimation
- Issue resolution meetings
- Daily / Periodic status meetings
- Add your own set of meetings here
You get the idea. It can be pretty frustrating. I have seen weeks where there were atleast 4-5 meetings per day, and even though you would think that these meetings are important, they do cause other problems. And at some point, if the people invited for these meetings start feeling that the subject of the meeting is not important for them, then you will start getting resistance in ensuring that these meetings are held.

So what is the solution ? There is no magic bullet, no quick solution I can give that will reduce the number of meetings you need to do. It requires careful planning, discussions between the respective managers (such as the project / program manager, the development manager, and the testing manager). Some of the questions that need to be asked before a meeting is set are the following (and there would be other questions that are not in the list below, it is just an indicator of the thinking that needs to happen):
1. The invitee list for the meeting needs to be evaluated. Is each person really necessary for the meeting. Can some people be marked optional, so that they can determine for themselves whether it is necessary.
2. If there are some minor issues that could be settled in a meeting, but could also be settled through a quick phone call or a quick hallway discussion, then that makes sense. In many issues, one person really needs to make a call, and the others need to just be informed. In such cases, having a meeting is really not necessary.
3. Is the issue really necessary to be discussed urgently ? What this means is, if the meeting is pushed out by a couple of days or a week, would it still be fine ? If so, then an alternate would be to postpone the meeting and see whether the issue can be resolved through phone calls or an email discussion.
4. In some meetings, the discussion is about nobody willing to take a quick call, or because there are no real solutions. In such cases, the meeting in a number of cases will fail or another meeting will need to be held. It would be better to prepare a solution or a note that clarifies issues, and then send that out. In many cases, this would be accepted by most of the people who have the authority to accept it.

Important meetings: Ensuring that agenda and main meeting points are circulated and clear before the meeting - Part 2

The previous post of this series (Ensuring that agenda and main meetings are circulated and clear - Part 1), talked about a meeting where we had a number of people, was an important meeting with a number of items to be discussed, and the meeting was a disaster. Items were discussed, but the meeting did not run on expected lines, most of the items were not discussed, and it turned out to be chaotic to some degree. Since the meeting did not accomplish what we had wanted to get done, and we had got some feedback about the meeting (not positive, certainly not), we set out to see what all we had been doing wrong and wanted to improve things to a great degree.
So, here are some of the things we did to improve the way we ran our meetings:
- We did a listing of the items we had where we needed information (or needed to have a discussion) with the required attendees of the meeting. This included a prioritization of these items; it was something as simple as figuring out the items that we could drop from the discussion list of we were pressed for time.
- Out of the items that we had for discussion, we tried to get a listing of such items that needed information from only one person (rather than a discussion with multiple people) and tried to get that information before the meeting. This ensured that the meeting did not waste time of most of the people who were there for the meeting.
- With the items that we had, we did a round of internal discussion related to the assumptions and the variables involved with each item, and where necessary, we consolidated the information including preparing diagrams and workflows that would help show the current situation, and show the areas where we needed the information. This would help focus the discussion and reach conclusions faster (and also remove the tendency for somebody to start tracing a situation from the beginning).
- For each item, we would have a specific person from our side who was the expert (this ensured that we did not have several people from our side trying to speak on the same issue), and this person was supposed to ensure that they set the pace of the discussion and stopped where it got out of context (see the next point)
- Sometimes conversations would tend to get out of context, and this would waste a lot of time. If you would have seen discussions of meeting, you would have seen somebody come up with the following line: "Folks, if we could get back to the subject on hand". We ensured that for every point, there would be somebody from our side who would do this, evaluating when a subject had been discussed enough or was getting out of context.
- Similar to the above point, we had set aside time for each subject, and had a buffer of 15% extra time. When we reached to around 90% of allocated time for a subject, we would try to consolidate and do a summary of the discussion, and then ensure that we were finishing the subject within the allocated time.
- We sent out an agenda with the current status and the query on which we were hoping for a conclusion, and ensured that everybody had read the agenda before the meeting. We did a call to all the attendees, so that they had read the agenda and also confirmed their attendance to the meeting.
- We sent out clear directions to the location of the meeting, including sending out conference details if the meeting was remote for certain attendees, and also details of any online white board for discussions.
With all these, the next meeting was a fairly decent success; we did not get everything discussed, but a number of items that we had for discussion came up and we got resolution to a number of items, It also ensured that a follow up meeting inspired more confidence among the attendees.

Important meetings: Ensuring that agenda and main meeting points are circulated and clear before the meeting - Part 1

If you are working for a small self-contained team, then this is not a problem that you will probably run into. However, if you are working for a product which is large and complex (consider some of the products made by large companies such as Intuit, Adobe, Microsoft, or Apple), then a typical product will have a lot of complexity. There will be components made by other teams that are critical (for example, if you consider MS Word, the Online Help system would have been prepared by another team, and the team working on Word would have integrated this system rather than try to make it themselves). Another example would be that of the multiple products made by Microsoft and Adobe. The part of the application dealing with serial number, anti-piracy and similar functionality would be common to a company, and individual applications would be just integrating these components. There can be different levels of complexity, and in some cases, this complexity can be pretty high and critical.
As a result of all this, there needs to be regular discussions between a team and the various components on which it is dependent in order to ensure that there is agreement on the inter-dependencies such as features, requirements, and schedule. When all this is going on smoothly, then the project manager can rest easy and not have to worry too much.
However, life is not so simple. There will be often enough times when there is some dependency that is proving to be a problem (the schedule is not working out right, or there are some new requirements that need to be communicated and agreement obtained on getting those implemented, or about the level of quality required, or about who will do the detailed testing, and so on). For all these items, sometimes discussions over email can work, but it can be difficult sometimes, and email can turn out to be more problematic, and it is probably easier to just do a meeting with all the stakeholders.
But, and this is the part that can get tricky, a meeting with multiple stakeholders can get tricky unless it has been planned. In one case, we had people calling into the meeting from 4 different geographical locations, and it was difficult to get the meeting rolling and on course. The discussion was chaotic, with multiple people jumping in, a topic being discussed multiple times, and so on. At the end of the meeting, we got maybe 10% of the required work done, and a lot of feedback about how the meeting really did not work all that well. Due to this kind of situation, not only was progress not made, but it got more difficult to call such a meeting the next time (with people using different reasons for dropping out, and one of them confiding that they felt that this kind of meeting was a waste of time, and could avoid the meeting, so that he can provide the required information later).
We did do the meeting later, but it took a different approach to ensure that the meeting was a success and got everything required from such a meeting done. Also, unfortunately, we had to do a bit of escalation to ensure that everybody did attend the second meeting, but escalation is not something that you can do every time, and if you are not getting things right, it will be very difficult the next time.
I will write more about what we did to change the planning for the next meeting in the next post (Ensuring that agenda and main meeting points are clear before the meeting - Part 2)

What is a scrum process and how does it work?

To implement the scrum development process, it is important to know how it actually works. Most of the errors in the development occur because of the lack of knowledge about the working process of the scrum. 

Scrum works on the principle of iterative and incremental development and it operates with the help of two types of roles namely:

1. Core roles:

(i)                Scrum master

(ii)              Development team

(iii)            Product owner

2. Ancillary roles:

(i)                Stake holders and

(ii)              Managers

What is a scrum process?

- The scrum process deals in terms of sprints which are usually called iterations for the other agile software development processes. 

- In a typical scrum, a sprint may have duration of a week to a month. 

- Scrum is facilitated by various meetings which have been mentioned below:

1. Daily scrum: 

This meeting is held during the sprint and is based up on the project status. Usually the core roles participate in this meeting. This meeting is time boxed to 15 minutes.

2. Story time (back log grooming): 

This process involves the estimation of the existing backlog and the acceptance criteria for the user stories is also refined. These meetings are time boxed to an hour.

3. Scrum of scrums: 

This meeting follows after daily scrum and is somewhat same.

4. Sprint planning meeting: 

This meeting is held before the beginning of every sprint and the tasks that have to be completed within that sprint are selected.

5. Sprint review meeting: 

It reviews the status of the sprint and also the tasks that could not be completed.

Principles on which working of scrum depends

The scrum follows the following three principles throughout its working:

1. Working software is more valuable then the documentation.
2. Response to the changes in requirements is more important than the plan.
3. Team collaboration is important than contract negotiation.

How does a scrum process work?

- Usually the first few weeks of the scrum are spent working out the high level requirements including business needs and system architecture. 

- After this, the team produces the product backlog and sprint backlog. 

- These two backlogs together make the scope of the software project by the end of the week. - All the team member themselves take up the responsibilities and operational activities from each other during the daily meetings. 

- At the end of some sprints, it happens that some of the tasks could not be completed as planned so they have to be included in the next sprint in addition to the other tasks. 

- One of the reasons for such situations is the “scope creep”. 

- However, this does not turns out to be a real issue especially when the team is working closely with the business owners who have good understanding of the development process going on. 

- It should be understood that the scrum is a framework rather than just being a full methodology. 

- A detail of everything that is to be done is not provided by the client since it is decided by the team itself.

- At the end of the sprints the coding, testing, integration of the features is done. 

- In the sprint review, the newly added features to the software are demonstrated to the product owner. 

Reasons why scrum works well

There are several reasons why scrum works and few of them have been mentioned below:

1. Iterative nature.
2. Re assessment of priorities between iterations.
3. The old check points are discarded when the team is doing something new.
4. Availability of the product owner.
5. The development team works on a single project at a time.
6. The team has a chance to co- locate the entire development process.

Formal Technical Review - Fagan's Inspection Method

Fagan's Inspection Method is introduced by Fagon. Apart from checking codes of programs,it is used to check other work products such as technical documents, model elements, data and code design etc. It follows certain procedural rules that each member should follow:
- The time limit for an inspection meeting is for two hours.
- Inspections are led by a trained moderator.
- Inspections are carried out at a number of points in the process of project planning and systems development.
- All classes of defects in documentation and work product are inspected.
- Inspection is carried out by colleagues at all levels of seniority except the big boss.
- Inspectors are assigned specific roles to increase effectiveness.
- Statistics on types of errors are key, and used for reports which are analyzed in a manner similar to financial analysis.

Different activities that are involved in conducting inspections are:
- Planning is very important and in this case the moderator is asked to build up a plan.
- Presentation should be given which gives an overall overview.
- Each inspector is given 1 to 2 hours alone to inspect the workproduct.
- Meeting should be held in which participants of the meeting are the inspectors, moderator and the developer of the work product.
- The defect list is given for repair.
- Follow up with the repair work.
- Casual analysis meeting is held where inspectors are given a chance to express their personal view on errors and improvements.

What are Formal Technical Reviews (FTR)? What is the aim and guidelines for formal technical reviews?

When tasks are performed in software process, the result is a work product. These results contribute to the development of quality software.
A formal technical review (FTR) is a software quality assurance activity performed by software engineers with the following objectives:
- uncover errors in function, logic or implementation of the software.
- verify that the software meets its requirements.
- ensure that the software has been developed according to the standards.
- achieve uniform software.
- make projects manageable.

Each formal technical review is conducted as a meeting and is considered successful only if it is properly planned, controlled and attended.
The purpose of formal technical review serves as a training ground for junior engineers and to promote backup and continuity.
Constraints of formal technical review meeting’s include 3-5 people involvement, advanced preparation not more than 2 hours for each person, the duration of the review meeting should be less than 2 hours and focus on a specific part of a software product.

There are few guidelines while conducting formal technical reviews. They are:
- Work product should be reviewed and not the developer.
- Make a practice to write down notes while conducting reviews.
- Agenda should be planned.
- Minimize the debate and discussions.
- Keep the number of participants to a minimum and insist on preparing for the review.
- The defect areas should be pointed but no solution should be provided.
- A checklist that is to be reviewed is provided.
- Schedule the reviews as part of the software process and ensure that resources are provided for each reviewer
- Check the effectiveness of review.