W06 SENG 411 MA3
From Craig
I was not surprised by the fact that nearly every group mixed and matched different elements of Scrum/XP/FDD to suit their needs. Obviously, we cannot work on the project full-time, and we have unique schedules that must be catered to, nearly every group did this by simply cutting back on the frequency of meetings as prescribed by Scrum/XP. I also found that FDD was most prevalent in scheduling the work among the different milestones. Especially due to our inexperience, this is prevalent because features are more tangible goals to acquire than other goals (like use cases or modules of code).
What amazed me was the number of groups that actually found customers, considering our aim is not to complete this project, just a small portion of the functionality. As you mentioned, it seems likely that the customers are considering similar projects and using students as guinae pigs for their own feasability studies. I suppose that's a win/win situation. I also found a large majority of the projects to be ill-defined in terms of scope, largely due to the fact that brainstorming was the biggest source of requirements elicitation. For industry projects, this is usually not the case because a customer will approach you with their own ideas for a project (they will also be ill-defined, but at least give you a base to work off of).
There were several important messages that I picked up as a result of watching the group presentations. The first thing I noticed about the group presentations was that none of the groups were using a single methodology. This is important because it is necessary in a project to realize that the methodologies are not strict guidelines that must be followed for the project to succeed. There is no recipe, no silver bullet, for creating a software project. For the project to succeed, the team must utilize a methodology that applies and works best for the team. It has to be the most effective in terms of getting work done, but the different types of personalities of the members of the team also have an effect on which methodology will work best for the team. Usually, this means that a team will incorporate aspects from several different methodologies into the methodology used by the group. That is what our group did, and what many of the other groups did. They used two or more methodologies, but the groups were not using the entire methodology, they were using the components and aspects of the different methodologies that worked best for their groups, in effect creating a new methodology that is a combination of several other methodologies. By doing this, a group comes up with a methodology that applies to their team, as opposed to a methodology that fits the team in some ways, but does not work in other ways. This is similar to our group, which combined features of the XP methodology, SCRUM, and Feature Driven Development to form the methodology for our group.
As students, our main goal is to pass the course. So we can more or less cooperate with each other. However, some groups show their method of keeping the team’s morale high by having extra activities outside of the project, which helps to build relationship among the group. This is essential for long term team commitment, as we’re not just working with “some other guys”, but rather with “friends” or “buddies”. This helps the team to bond and to stay together during rough times.
The most obvious issue that many groups were faced with that ours was not, was the task of eliciting requirements from a non-existent client. Our group has an actual client that we can work with closely, but many groups had to be their own clients and carry out the elicitation process in a simulated process. I would imagine that this has both positive and negative aspects. The positives might be that the process would not take a lot of time, since scheduling meetings takes minimal effort. In addition, the chances for the interviewer misunderstanding the interviewee are fairly low because they are the same person (there may be some exceptions, but I won't get into that). On the negative side, the developer not only has to figure out how to implement the requirements, but has to generate them as well, which takes much effort. Without actual customer interaction, there may not be as much incentive to carry out a regular demoing schedule because they can see their progress continually as they develop the system. This might cause the system development to stray off-course of their initial goals.
I have attended all presentations and learned some interesting lessons. First, almost all groups had major difficulties with the requirements elicitation, software architecture, and scheduling of their system, which were the same difficulties we encountered and struggled with in Milestones 1 and 2. This was a tangible proof of the complexity of these tasks when carried out in large-scope software projects, which are considered similar to SENG 411 course projects, and a lot of comfort for myself that these components of software projects are indeed difficult to comprehend.
But there were different things too to learn from those presentations, such as the importance of diversity within a team, which in many SENG 411 projects led to wide spectrum of ideas. Also, although we shared similar challenges, each group dealt with their challenges in a unique way that suited their resources and individual experiences, and I think that it is very important to realize this adaptation technique in any software project, especially “death march” projects, to survive them by adapting to each situation and not following certain software practices or methodologies blindly.
The biggest thing I learned from watching the other groups present is the importance of chosing an appropriate estimation method. I took note of this because this was my responsibility for milestone 2 in my group. Even though I simply chose the estimation technique that I understood best, it was clear that certain techniques are more suitable for certain projects. This was most clearly pointed out by the group that did the chess application
