Moving Along | Reflection #2

Considering Context | Overly concerned?
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:

1. Since the alpha will only implement one source for images, should it be the camera, gallery, or Web?
2. Should we go straight to the camera, keyboard, or main menu when the app starts?
3. etc.

As an aside: I say trivial, but someone else might differ with that.

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!

Team Dynamic | Reflection #1

The first thing I would like to reflect upon is an initial response to our team and its progress. Simply put, I do not sense that our team has found the cohesion is needs to make progress as rapidly and effectively as it should. I start on this negative note because it is the one that stands out most to me. I might have started with a positive note, and there are several, such as the interesting discussions about sound, synthesis, color, perception, usability, and the like. However, those positives seem to be free-floating and not recorded concretely or part of a detectable overall process or plan. Also, I am unsure as to whether all of the discussions that took place were necessary given the immediate goals, the amount of time we had, and the level of foreknowledge for a given discussion.

It appears that little time is devoted to our immediate goals while much is devoted to goals far out in the future ...or perhaps infeasible.

I think part of the problem (for my part, at least) is that the MSF Team Model has not been clearly cemented in my mind until, I think, today when I reread it. Much to my surprise, several of our team members exhibit motivations to address several "Functional Areas" - the sub-roles or sub-goals of any given role in the MSF Team Model; however, these motivations seem to be for Functional Areas in roles other than the ones assigned!

I really believe that our team has a solid application it can deliver. The application (Aural Aura) is most certainly designed for mobile use: it's functionality is simple, quick, to the point, and understandable; not to mention it makes use of technologies usually found in mobile phones (a camera and sound playback). However, I think our team is perhaps like a kid's bike assembled by a proud dad who refuses to read the assembly instructions... not a good outcome. That is, I think we have all the talent, knowledge, and skills we need to be successful, but we need to reallocate them.

Thinking upon this line of thinking, I conclude that I am simply a "know-it-all," type-A, control freak who, maybe, just can't stand to be a part of a team structure with the level of flexibility and agility the MSF team structure presents. I am vexed - should I step in and recommend a restructuring of the team? Or, should I just observe the status quo and watch as the current role assignment eventually proves the agility of the MSF Team Model effective?

Hmmm... perhaps the MSF Team Model would prove itself more effective if roles were, indeed, reassigned. I have to believe that roles are assigned to the best person(s) for those roles. The goal of "shipping" - delivering the final product - is a recurring theme throughout the whitepaper. The perception that the team is a single unit without individuals to blame is also reinforced continually. It would make sense that each person on the team takes roles most suitable to him, so as to minimize the social hiccups within the team... so that, indeed, the team is perceived as one unit that operates smoothly.

I was thinking about this line of thinking as well - why should accomplishing the goal of "releasing an app" force teams to attempt the optimal assignment of roles? Now, I don't mean to be rude or disrespectful, nor do I mean to undermine the goals of the course. I just wonder: is it "okay" to flounder in a role not suitable for oneself if it means learning more as a result of the floundering? For this reason, I have remained silent on certain issues, not knowing if my speaking would stem the learning process.

Hmmm... maybe not. After all, the entire team suffers then, doesn't it? If one cog in the machine won't turn, what happens to the rest? Since the MSF Team Model stresses the team rather than the individual, and since the course uses that model, perhaps it is safe to say that the intent for optimal learning in this course corresponds strongly to optimal team role assignment? How can any individual learn if the entire team is in a stalemate?

On one level, I think it selfish to make suggestion upon suggestion and thus appear to be pushing the team around. However, maybe the real selfish thing to do is withhold my suggestions in attempts to avoid negative feedback. If indeed my suggestions would help the team as a unit accomplish its goal, then I should make suggestions regardless of the prospect of retaliation... however minimal or maximal that retaliation might appear.


I suppose I will make my suggestions to the team after all.