I have no doubt that team AEIOU could whip up an Android application in one week if we all sat down together for 20 to 40 hours and just coded away. However, the end result might not be user friendly. Usability is critical, but just how much should we be worrying about that right now? We have already, in my opinion, inordinately thrashed a super simple app. When it comes down to it, disputes concerning "what the user would like" are the main sources of lag for pushing out our first alpha. Said disputes tend to be about trivial and/or technical things:
- Since the alpha will only implement one source for images, should it be the camera, gallery, or Web?
- Should we go straight to the camera, keyboard, or main menu when the app starts?
- etc.
Right now, we don't have solid user feedback for a running app. Answering "what the user would like" is difficult at this point. So, let's not get tied up in picayune minutia, let's get the alpha built, and let's put it out there for users so we can get decent feedback! We can always reorder or augment a navigation map later.
Flexibility & Structure | Motivation is fuel for agility?
What motivates each one of us? Why is that the case? Is each motivation exclusive to a context? Can we control our motivations, find new ones, impart them to others, or eliminate them?
I've worked for the Digital Corps for about 3 years. During my employment, I've observed that the most prominent personnel in the Corps are both talented and motivated. I have had the pleasure of working with a highly motivated 4-person team recently whilst working on an app for the iPhone. I would say that the level of agility for that team was extremely high - a 9 out of 10, you might say. I don't think that level of agility would have been achievable if it were not for each individual's motivation to succeed. No one had to be told to do his work. If anything, we were constantly asking one another "what do you need from me right now?" I recall several times asking for a single graphic and getting 3 variations in return. We were not just motivated to get this app done... we were motivated to be the best at whatever it was we were doing. We saw the task of completing this app as not just something we "did for work," but as a testament to our abilities. I think each of us knew this about each other, and we chose to capitalize on the potential synergy.
I think everyone on team AEIOU is fairly comfortable in his respective role, but something still seems amiss. I can't quite put my finger on it. Perhaps the newness of this experience for some is keeping them at a fork in the road when it comes to what exactly should I do next? That was natural for me, too, at first. Well, our team is employing a few new structural tools. Until our new tree grows a bit more, we will keep the stakes close by. Given a little more time, we'll grow into a mighty oak!
It sounds like your Digital Corps foursome comprise a dream team. It's fantastic to work with a team where every member is motivated to succeed.
ReplyDeleteIt sounds like your mind is going the same way mine is after reading the reflection: what are the properties of the DC team vs. the AEIOU team, and how do you mold the latter to behave like the former? As an educator, I have to wonder if there's an intrinsic difference of context. To many students, a class is a class and a prof is a prof, no matter how it is dressed up. This is one of the challenges I face, and I wish I had a complete answer that could be translated into your situation. I encourage you to continue to reflect on these experiences, using tools of empathy and metacognition to consider others' perspectives and the phenomenon of group identity.
From a more practical point of view, if you find that your team is spending too much time on trivialities, I encourage you to lean on the risk matrix philosophy: identify that which is highest risk, and solve that first.
I noticed through Google Docs that you (and your team?) are using a lot more documentation than just the risk matrix. Would you be comfortable presenting this structure during a meeting sometime? I think other teams would find this useful, since each team has its own idiosyncratic collection of experiences to draw from.
Finally, I encourage you to consider sharing a link to your blog from the course blog to try to drive more students to read it, since it's already on the Web. Some students are having trouble identifying how reflections can be useful, but I think your examples here show an exemplary level of insight.