On Tuesday, we had a guest presentation in 345/545 by Jim Solenberg, Chief Architect at LaViaz Mobile. He gave a very nice presentation on UI design and development, pulling from significant experience in both the technical and the human factors of application development. He based much of his presentation on the Apple iPhone Human Interface Guidelines (HIG), which are worth an exploration.
Solenberg argued strongly for having a product definition statement that a team could return to for justifying all significant decisions about an application. This is a good idea and, as I understand it, a best practice in application development. However, from what I have seen, the Apple HIG does not address the nature of the team, only the nature of the product. In 345/545, we have been following a loose interpretation of Microsoft Solutions Framework (MSF) Team Model, specifically the Risk Management Discipline. This approach was recommended from Hal Abelson for mobile application development within a classroom environment, based on his pioneering courses on mobile application development at MIT. MSF is product-agnostic, but it heavily relies on collaboration by peers: all members on a team are peers, and open communication is necessary.
Inspired by MSF’s Team Model, I had my students include a team mission statement during team formation. The intention was that this would capture the ethos of the team and give them a stable point, even if they changed projects. That is, even if the team unwittingly undertook a project that was beyond their capacity to complete, they could be agile enough to change projects as long as it was consistent with their team mission statement. This is reminiscent of the Resources-Values-Processes business analysis model from Clayton Christensen, where the mission statement represents the Values of the organization.
Students were asked to give a 2-minute project pitch the same day as they announced their team formation. My intention was that this pitch would contain the “elevator talk” version of the project, the product definition statement of the Apple HIG.
From my observations, I suspect that none of the teams have referenced either their mission statement or their 2-minute pitch since the beginning of the semester. One of these is focused on the team, and the other on the project, but they serve a similar purpose: to steer a team towards success. I am left wondering whether more rigorous enforcement of either would have helped the teams through some rough patches. However, because neither the team-centric mission statement nor the product-centric elevator pitch seemed to have much effect, I am left wondering what elements of this approach should be reused. It may be worth noting that none of the teams have shifted projects since their initial pitch in the first week of class, although all have revised their designs through a few iterations.