Keys for success when working in a team

               I think that when working with a team or within a team, it is really important, first of all is to respect each other. Mutual respect among the team member can solve and prevent a lot of issues even before they arise. In the Hands on Hearts team, we manage to accomplish this mutual respect from the first meeting we had, among us the developers and with Dana, out client.

               Regarding the red lines, in my experience in working with teams and within a team, the red line is usually related to the level of knowledge a person has and they are usually being pretty sensitive about somebody else’s criticizing them. For example, if my teammates are expert in C language, and I know Python and C also, but not very well, I would not go and start telling them that this approach was wrong or they should have used different style of code. Also, another red line that I think that should not be crossed is that every person idea is a good idea. It would be disrespectful if one team member will suggest an idea, and another team member will come up and say that this idea is no good, that can create a situation where people from the group will start to feel uncomfortable to suggest ideas, and maybe one of those ideas that they wanted to bring up but were too afraid to, will actually solve a major bug or a defect.

               The key to success of leading without being a leader is to just come up with original ideas and to know how to present them in a way the whole team will agree and understand. So far, in the Hands on Hearts team, I think that Frank has stepped up and in the last two sprints, he has been leading us with giving good ideas on how to proceed and a good interaction with Dana. It seems like she understands him and he understands exactly what she wants, which is really helpful, and also is helping us in the development process.

               One way to do the job done without one person doing the job for everyone is to create specific tasks that every member of the team agrees with. If the tasks will get distributed among the team members, but one member is not feeling comfortable with his task for any reason, he won’t do it, and he will create a situation where somebody else in the team will have to do this task. So the key here, is to make sure that every team member gets a task that he or she is the most comfortable with.

Client and team difficulties.

Actually our client is a programming savvy so I don't think that there is any situation where we don't understand her or she doesn't understand us. I think that the issue at the beginning was that our client thought that we have knowledge in creating high level mobile application. I think that our team's problem was with the technology, which is we don't have much experience in the outside world in creating functional programs that can be used in the industry. Expect from doing school assignments that are more useful in testing knowledge but not functionality. We did manage to come up with a different idea that our client agreed upon and thought that this will be a good start, and something that our client thinks that can be used as a good and functional substitution to the original idea. Agile was never a problem for us to understand and so is our client who actually showed a pretty knowledgeable details about agile and how a sprint is supposed to be handled, that for sure helped us a lot in managing our time and our stories. Also, I think that we are pretty much in the right truck regarding the team structure, each one of us knows his role and what he or she is supposed to do. Regarding the backlogs, I think that the problem here is that what we, as a team, came with the substitute idea for the original idea, we still not exactly sure what is the technology limits or our time limit. We are trying to avoid a situation where we will say that we will do some sort of a feature in the product but we would not be able to deliver that because our knowledge is limit or the time we have is limit; I’m pretty sure that our client is well aware of that issue and it looks like our client and we are managing to reach the middle ground. As I mention before, our client knows pretty much a lot when it comes to programming and to computer science, and she was using Agile back in the days, so I think that she knows all the policies, procedures, and the limits that the technology has, but not the limits that we, as students and programmers have.