reflection.tex

\chapter{Reflection}
\label{reflection}
This chapter contains the team's reflection around the project as a whole. It start by describing the different aspects of using the \gls{LSU} methodology in combination with a customer-driven development project in section \ref{lean-in-customer-project}. The chapter goes on to describing how the workload was during the project in section \ref{workload}. It also includes how the students have worked together as a team in section \ref{group-dynamics}. In the final section the team discuss what the future customer-driven course students should know about the course.

\section{Using the Lean Startup in a customer driven development project}
\label{lean-in-customer-project}
During this project the team used the \gls{LSU} methodology as a basis for the development process. Features of the specialized development methodology used in this project is described in chapter \ref{chap:LeanStartup} where an example of an iteration or version is described in section \ref{generic-example}.

In the twelve weeks the project has lasted the team have learned a great deal about the philosophy of the \gls{LSU}. Throughout this time the team has experienced many positive aspects of the methodology and some maybe not so positive aspects regarding the use in a customer driven project. These different aspects will now be discussed.

\subsection{Flexibility in development}
Working with the \gls{LSU} provides the team with flexibility in developing an application. In this project the team appreciated not having to develop functionality that was not necessary in addition to the low effort required to fix minor flaws in the software. Not developing unnecessary functionality meant that all new features were features the team thought the users of the application would appreciate and this increased the motivation of developing the application. It also gave the team a feeling that the purpose for developing the application was meaningful in the sense that it was features that the users had indicated they needed. 

\subsection{Difficulties}
However using the \gls{LSU} did not always fit perfectly with the purpose of this project. There are three main aspects that made the use of this methodology a little difficult in the case of this project, namely the lack of marketing skills, not knowing all the technical aspects in advance of the project, and the fact that the project had a customer who had demands. 

\subsubsection{Marketing}
With the lack of marketing skills the result was that the team did not manage to generate a user base large enough to get valid user data from the application. A lot of effort was put into trying to make movies and updating the blog, Facebook page and the website to promote the application, but this would maybe be easier if one of the team members were a marketing student, or someone who could devote all of the time in the project to do exactly this type of work. However the team felt they did the best they could, and their effort into promoting the application was not without results, it just did not reach out to enough users.

\subsubsection{Technical prerequisites}
The lack of technical experience with specifically Android development created some trouble for the team in trying to release as many versions of the product as possible. As a result it was a whole month before the first version of the application was released. If the team had known all the technologies used in the project prior to its beginning it would probably be easier to follow the \gls{LSU} with continuous deployment. However this is something that can happen in any type of project and would probably have been an equally important problem if the team had used another development methodology. 
 
\subsection{Using Lean Startup with a customer}
Having a customer whilst using the \gls{LSU} turned out to be both a positive aspect and a minor difficulty in this project. 

By having a customer the team had demands, and in this case it was a lot of demands. Even though the only requirement was that the \gls{LSU} was used the customer representative always had something he wanted the team to do. It could be requirements of self-documenting API, or that the application had to be filmed each week, or to have meetings at 09.00 on Sunday mornings. The customer representative also had a lot of ideas of how the application should function which in turn influenced what the team thought about the application. In this manner the customer steered the direction of the application’s functionality. Even though the customer in this project also is a user, or many users of the application, it affected the power of other users feedback. 

On the other hand, having a customer with high demands resulted in the team performing many exciting tasks they would not have done otherwise. The idea of creating a website might not have occurred unless the customer had suggested using movies as a product in the first meeting. Neither would the team have used Swagger documentation unless the customer representative had insisted, and Swagger turned out to be very helpful. 

In addition the customer of this project is an IT consulting firm which means that the employees are skilled developers. The customer representative provided the team with resources from the Netlight to help with the different aspects of the project, both technological and \gls{LSU} related. Even though this could be applied to any development methodology the support from employees at Netlight was invaluable.

\section{Workload}
\label{workload}
The duration and hours required this project is described in section \ref{duration}. Compared to other courses at \gls{NTNU} it has been a heavy workload. However compared to other courses the learning outcome and experience received from performing this project has been equally high. The only problem with the workload experienced in this team is that the students have two other courses in addition that takes up some of their time. It is not the time itself that has been the problem, but what days they can not work. 
Within this team there are nine other different subjects that have to be taken into account when deciding when to work together. This resulted in a period of four days (Wednesday-Monday) each week where three of the team members could not meet in person. Even though everyone on the team had good routines on responding and doing their tasks, the team realized it was difficult to collaborate and keep track of exactly what tasks were in development. To solve this problem the team introduced a very strict use of JIRA where the team members were required to put every issue on the board, and constantly update the status of the issues. This turned out to be a good solution and in this way the team handled the problem with not always being able to work together.

\section{Group dynamics}
\label{group-dynamics}
Learning how to go from being a group to become a team was an important part of this project. At the beginning of this project the team consisted of six strangers, but through a course in group dynamics it did not take long before the members got to know each other. The first meetings of this project consisted of getting to learn about the team members’ strengths and weaknesses in a software development project. During this time roles were assigned and sub teams set up. As a part of the strategy to become a team the group decided to call the group a team for the rest of the project lifetime.

The structure of the team has actually worked very well. This structure is shown in figure \ref{fig:org-structure}. All the team members have put in a lot of effort in the project and even though the team has encountered problems during the project the members have focused on always telling the other members what that problem is. The communication between the teams, and within the sub teams is one of the points the team always mentioned in the “went well” part of the retrospective meetings. 

However not all aspects of the dynamics in the team were great. The team experienced some problems in the beginning with not defining clear enough goals in addition to a low participation in the retrospective meetings. The issue of not defining clear goals resulted in the team members being confused with what they were striving for, and as a consequence reduced the efficiency. After this problem was addressed the team leader started to create a clear goal of each version that was written down on the whiteboard so the team members could see what they were working toward. The solution to the retrospective meetings came as an idea from the customer representative and is described in section \ref{retrospective-intro}. When the new routines for the meeting was introduced the team’s feeling of involvement increased and the number of improvement points decreased from version to version.


\section{What should the future customer-driven course students know about the course}
After performing this project the team has some points they want to tell the students who will have this course another year. 
\begin{enumerate}
    \item If you want to do this project you have to give it your full effort. You can not complete the course without working hard throughout the project.
    
    \item Start writing the report early on. As early as possible. And keep writing the report through out the project. For each iteration or sprint, fill in what you did and what happened. Do not wait until the last minute.
    
    \item Document your work in parallel with developing. It is amazing how fast you can forget what you have done. So this team recommends at least a weekly summary. It can be as simple as a blog.
    
    \item You will probably encounter technologies you have not worked with before. The key to handling this is to take the time it requires to learn that technology instead of trying to learn while developing. Do not let the new technologies stress you.
    
    \item Take your time with planning. In this project it was experienced that planning the structure in advance saved a lot of time during the performance of the project. And still the team could have benefited from a more detailed plan and from setting up all necessary documents during the first days.

\end{enumerate}