In this sprint I have quickly realised, that we had many features, but there was very little interaction between them. As time was limited, I decided to hold back on making more features and dedicated my full time and focus on making sure that we would end up with a distributed system, rather than a set of independent components.
Plenty of background work was done by me, which could not be noticed on paper. On each day, I have sat down with each ESD team member individually, asked them for status and offered help in implementing IPC as well as my general coding expertese. I took each individual's problem as my own problem and dedicated my full attention to each case I helped with. I listened carefully to team members and I have written patches for TVCS in order to take weight off team's shoulders and ensure smooth development. Sometimes this required some extra development time at home. I ensured that I am approachable at any given moment by anybody, so that they get my help and spend as little time as possible worrying about the threads. Again, this included remote help in my spare time as well. Also, when somebody needed to find something to do, I had plenty of work to assign, offering my explanation and support. Additionally, I have made sure that every person knows who is on the other end of their code, i.e. the receiver of their output. This has led them to work together and agree on message format.
Having all of this done, I have ensured integrity of the components as a system and integrity of individuals as a team. At the end - it worked out great. The amount of "glue" I have put between the components and their developers allowed a very quick combination in the final phase. We managed to get majority of the components working together to form a system and left plenty of room for extra parts. I believe that the time I have spent on making team's life easier has saved plenty of their time, which has multiplied by how large the team was. This time was contributed towards feature quality, rather than fiddling with unnecessary low-level concerns.
Final code which resides on the PIs can be found here:
I was happy to have personal contact with each team member on daily basis and I think it has developed me in many ways, including my expertise, social skills, team-based development and pair-programming. I have worked in teams before, but this was my first time in a team in which team members were on similar level. It's great to have the conscience at the back of the head that everybody in the team is equal in skill. I also have to admit, I enjoyed to see two people working together after my recommendation. The atmosphere in the room became really positive and productive. At the start we did know each other. Towards the end we were not just professionals working together, but also friends to some level. I would gladly do something like this again.
Project Management Reflection
One thing I was concerned about was the fact that the team was so large. I expected it to be hard to find a job for everybody that would be beneficial for the project. At the end it turned out to work alright and it actually helped, taking the amount of time we were given to complete the system.
Another thing I was concerned about was whether we will get a chance to combine efforts of ESD and Mechanical teams together. From sprint two I have learned, that combining on last day is generally a bad idea and that was the argument that pushed me into making combination preparations throughout the whole third sprint. I constantly involved myself in both loops just to make safe predictions of how much realistically we can implement and used that information when recommending work and giving implementation tips. Teams have made a subconscious decision to focus on feature quality rather than system completeness and I believe it has worked well, because quality benchmarking was finished on time and impact on completeness was really small.
There is plenty of room for improvement in the future generations of this project. Many bugfixes and quality improvements could be applied to LamPi by simply reading the blog entries.
Apart from that, I just came up with an idea that may give this project more purpose. Now, that the lamp is able to move and emit sounds in a controlled way, we could implement an abstraction that would allow organised construction of programmed behaviour. What I mean by that, make a template with a simple set of functions that would allow, let's say, amateurs or kids to decide how LamPi acts. Making change of behaviour easy could end up producing a community around the lamp with a collection of behaviour mods written by third party amateur individuals. Project could be exposed at likes of CoderDojo and gain some momentum on the web if lamp was distributable. Who knows, this may even have a potential for a kick-starter company.
I would like to thank all people involved - the team and Jason - for this experience. It was a really fun and developing journey and I would gladly do it again with the same people. I would especially like to thank Luke and David for showing me the engineering side of WIT and their cooperation in final combination phases. Special thanks to Jason for teaching me how to calm down and take it easy :)
#2 Cannot find. May be counting error
Kamil Mech, post #9