Today I will be blogging about a main challenge that we face as a group. One of the main challenges that we face is floundering - To move forward with difficulty[1]
Floundering on Back of Horse in Water[2]
Floundering within our group has in fact affected the overall team’s working pace and the quality of work being delivered. During the first few group meetings, we have been trying to figure out the work and the roles that we will be good in. We rarely came down to a common team understanding of problems but rather were individualistic in understanding of problems within the group. Due to this, we experienced many false starts and circular discussions. Thus this led to some discussions being postponed / repeated.
During our first few meet-ups, we had to understand the project at hand and have to agree on a common understanding of the project requirements. We were quiet as we were new to each other. We rarely clarified the points as we did not understand on how the other person would react or was afraid if our clarification was ‘silly’. Thus we made individual assumptions on our common understanding of the project.
Due to this, when we met for another meeting, we had to work on the continuation of the previous discussion. However, we had various understanding of the project. We started clarifying them as a group. Due to this, we wasted valuable meeting time and repeated the discussions in subsequent discussions. [Circular Discussions].
We came up with a solution to this along the way.
Solution
In order for all to understand any problem at hand, we only move forward if and only if everyone agrees / understands them. Only then we will move onwards to the next phase of the discussion.
For example, we try to say
- Here's my understanding of how the program works... Do we all agree?
- Before we move forward, let's hear everyone's suggestions about improvements or better ideas on this problem.
Problem arising from above solution
This solution only worked to a certain extent. OP2’s Q&A was a very good test for this problem that we had. It clearly showed us that we still did not have a common understanding of the entire project.
Solution
We had an impromptu urgent meeting just to identify on what actually went wrong as a group. We realized was that we did not have a common medium to refer to when we felt lost and thus made individual assumptions once again. We had to reanalyse the entire project as the next phase was implementing it. However, for this meeting we started taking down detailed minutes. Kim Li jotted down notes on our discussion on how entire program will work. The change that we made was that she will post the minutes online so that everyone can refer to it when we feel confused about the project and not come up with individual understandings. Previously we only did minutes for the first meeting as it was a requirement for CS2101. Now we realise the importance of minutes.
We certainly do hope that this will be the last circular discussion that we will be having.
We also experienced false starts at the beginning. We made lots of assumptions at the start of the project. We carried on our discussions with these assumptions which actually led to ‘extra’ work and solutions that we out of scope.
Thankfully, we avoided this pitfall as we always stayed back after CS2103T lecture to clarify the doubts we had with Dr Bimlesh.
One good example was that we always assumed that for our CS2103T project, our GUI should be top-notch as it’s supposed to look like an official software. After clarifying with Dr Bimlesh, we were told that GUI is the last thing she would like to see as this course is leaning more towards the understanding of software engineering. This has in fact saved us LOTS of time in the upcoming weeks to come.
Floundering as infact made our team’s progress to slow down to a crawl at the beginning. However, the situation has improved and we have made up most of the valuable team time being wasted on circular discussions!
References:
[1] The free dictionary's defintion of floundering - http://www.thefreedictionary.com/floundering
[1] The free dictionary's defintion of floundering - http://www.thefreedictionary.com/floundering
It is good that we have realized that we have been doing circular discussions. I do feel that documenting down the ideas discussed is a good way of confirming the ideas. It also allows us to refer to it when we have a doubt. Also, the questions you mentioned is another good way to ensure that everyone is on the same page. We can also get the team member who is unsure to explain to the team what he understands and from there, team members can correct him. Though this will take up some time, I find that it is very beneficial to the team.
ReplyDeleteYeah, our group has lots of circular discussions in several past meetings. It is very time-consuming for us. We have to spend more meeting time than other groups to make up the progress. The solution you raised is very effective. Before we are going to have the meeting, we can review the minutes taken down in the past. When we come to the meeting, we will be prepared for all the important points we already discussed. That will save a lot of time.
ReplyDeleteHowever, some or a few circular discussions are needed. For example, after a discussion about a topic, someone may be inspired by something and has come out a more sophisticated solution. Then he or she can inform us and hold the discussion again. Although we spend some time on the same topic, we will get some improvements. But, we should remember that circular discussions are so costly that we should have them as few as possible.
I feel that one of the main reasons we do not have a common understanding of the project (leads to floundering) is related to the division of tasks. Usually, the tasks will be divided equally among members, and there is some kind of “un-communicated rule” that prohibits us from interfering with the job of others. As a result, each member only takes ownership of particular aspect of the product and not the entire product.
ReplyDeleteThis is a problem that can be partially resolved without much intervention. Since there are many dependencies between different parts of software (e.g. budget and items), we will have to communicate and work together to ensure that our programming code works together smoothly. On the other hand, to tackle this problem completely, we have to gain more interest in the work of other members and seek clarifications when necessary.