Signature of Trust

One of the first few steps that a BA or the PM does on the project is to get a process in place, which shall be followed by the team (s)he is a part of. As part of the process it is important to identify the meetings that would be a part of it. Usually, team members that are required to be part of those meetings are identfied up front so that these people understand their importance and where they fall in the critical path of achieving the business value. Recently, I was reviewing such a process flow with a client team where I started observing a pattern. Some of the client representatives started to point out that I was missing their role reprsentation in some of the meetings. It was not a mistake. I had deliberately left them out of those meeting out of respect for their time and considering the stretch they were already in. It came as a little surprise to me that this didn't deter these people to point out their ommission from some other meeting. At the end of the it all, I observed that almost every one is involved in almost every meeting, which defeated the purpose of the exercise in the first place and also raised concerns about how this will eventually end up playing out. This prompted me to ponder on why they want to be part of these meeting despite their already busy schedule. From some of the questions that I raised to understand the rationale behind client's demand to be present in every meeting, I got the hint that they didn't belive in our abilities or were not comfortable enough with me making the decisions that they rather make. It is a matter of Trust. No doubts about it. It was quite clear that there was a lack of faith that decisions can be made by outsiders without the presence of client. My process right now lacks the signature of trust that I have utilized in the past to save the client a lot of pain and effort and anguish that is typically a part and parcel of a lot of meetings. I have come to belive that as this trust increases people feel more comfortable distancing themselves from distractions that prevent them from being effective somewhere else - meetings is one of those.

Fair Representation in Team Retrospectives

Joe: Yes, we have had problems and still have them. Jane: What problems does your team have? Joe: There are many - I can tell you my problems. Jane: Alright, so what works well for your team? Joe: Again, I can tell you what works well for me, not sure what works well for others on my team. Does this conversation sound familiar? It happens almost on every project in some form or other. One of the other forms of this debate is what a lot of team members have with themselves. Some of these are again very usual questions - Is it just me who has these problems or do others have these as well? I am not being able to achieve this objective due to this obstacle, is it an obstacle for others too? This practice does not have any benefits for me, how do I convey this to other team members? To address these questions a lot of teams have a retrospective. In agile teams that work in short intervals or iterations, as they are called, an iteration retrospective is held. Retrospective is a forum where teams members discuss what went well and what didn't go well. The idea is to get the issues out in public and then to vote on them. Then the team picks the top items and takes some corrective issues to weed those problems out of the team. One pattern that I have observed is that due to very obvious reasons only the top three or four of these are chosen and assigned to people. The rest, which are supposedly not that important, don't usually get acted upon unless they become detrimental. So far, so good. The problem, however, is that if a typical team has 20 developers, 2 QAs, and 4 Developers the issues that are BA or QA related will never have enough votes so that they can be acted upon. There are two solutions that I see for it:
  1. Have a separate retrospective for each group.
  2. Divide the issues into group and have people vote on them. Choose the top 3-4 issues from each group and solve them out.
An obvious demerit of the first issue is that problems surface up but are discussed and resolved in silos. This is not good in long run as the other team members will never get to learn the issues that others typically face. This is bad for learning, growth and maturity of the team. The second approach is not free of demerits. It is a typical reaction that people think they are wasting their time if the issue is not related to them. In my opinion the second approach is the best if the team members have to grow and the overall maturity of the team is to be increased.