Following up on yesterday's post about stand-up meetings, I heard a great story today about an impact that the Morgan's Raid team has had in a distant corner of Ball State University campus.
Towards the end of the Spring semester, James Mitchell from the Career Center gave a one-hour workshop called "How to Market Your Immersive Learning Experience." This was in the middle of the sprint, so he observed the team hold one of their stand-up meetings before the workshop. This is the short meeting at the start of each work day in which each team member shares what they have done since yesterday, what they plan to have done for tomorrow, and what impediments are in the way.
Today is the last day of the Digital Archaeology Project, and James joined us to give the workshop to this group of students. He told me that he was so impressed by the Morgan's Raid team's stand-up meeting that he has pushed the staff of the Career Center to do something similar, with the hope of improving communication and camaraderie.
Score one for agile philosophy!
Friday, July 22, 2011
Thursday, July 21, 2011
Forced proximity and stand-up dynamics
I noticed something interesting when acting as Scrum Master for the Digital Archaeology Project. Our main meeting room is the Anthropology Department's conference room, which has tables set up in a U-shape.
While some of the students knew each other before the start of the project, many did not. When we started our first stand-up meeting, it was clear that the students wanted to stand around the outside of the tables, where they had sat down upon arrival. I shepherded the team towards the center of the tables in order to have their stand-up meeting.
There were three professors in the room, and we were all seated on the outside of the U during the stand-up meeting. I think this is significant, since from the very start of Sprint 1 to today, our last stand-up meeting, the students never turned and reported their progress to us, the Product Owners and Scrum Master. Every meeting, the team exemplified the agile best practice of reporting to their teammates. Even though there was clear line of sight among everyone in the room, the tables provided a psychological barrier that allowed the team to carve out its own private space in the middle of the room, without losing the benefit of having the Scrum Master listening in to determine how to remove impediments.
The cost of the room configuration was paid in Sprint Planning meetings. We used a portion of the wall for our task board, which comprised of colored index cards, tape, and yarn.
The cards are standard 3x5, and so to write user stories or tasks on them requires one to write relatively small, around 22 points. During the Sprint Planning meetings, however, the team would sit within the U in two rows. The close row, about eight feet from the wall, could see and read all the tasks, modulo handwriting issues. The next row, probably three times as far, could not make out a thing written on the cards. There wasn't really a way to get everyone close enough to read and still be comfortable, not without moving tables around. In retrospect, perhaps we should have just moved tables around for these meetings. Also, the complications of the space were exacerbated by the fact that we skipped the product planning meetings in which the team would discuss story points per user story: because of our very tight timeline, I assigned story points based on intuition.
There's not enough time in four one-week sprints to react to all the complications that can arise. It would have been nice to have more time in this space to see how to optimally use it. Next semester, I'll be back in my usual Computer Science classrooms, which come with their own issues.
While some of the students knew each other before the start of the project, many did not. When we started our first stand-up meeting, it was clear that the students wanted to stand around the outside of the tables, where they had sat down upon arrival. I shepherded the team towards the center of the tables in order to have their stand-up meeting.
There were three professors in the room, and we were all seated on the outside of the U during the stand-up meeting. I think this is significant, since from the very start of Sprint 1 to today, our last stand-up meeting, the students never turned and reported their progress to us, the Product Owners and Scrum Master. Every meeting, the team exemplified the agile best practice of reporting to their teammates. Even though there was clear line of sight among everyone in the room, the tables provided a psychological barrier that allowed the team to carve out its own private space in the middle of the room, without losing the benefit of having the Scrum Master listening in to determine how to remove impediments.
The cost of the room configuration was paid in Sprint Planning meetings. We used a portion of the wall for our task board, which comprised of colored index cards, tape, and yarn.
There's not enough time in four one-week sprints to react to all the complications that can arise. It would have been nice to have more time in this space to see how to optimally use it. Next semester, I'll be back in my usual Computer Science classrooms, which come with their own issues.
Tuesday, July 19, 2011
Manager's Guilt
We're in the final week of the Digital Archaeology Project, and the students have really hit stride in terms of productivity. The content team has developed a working understanding of iterative design, and they are dealing with the technical challenge of XML-as-a-DSL. (NB: Not ideal, but in a five-week timeframe, nigh inevitable.) The technical team has shown remarkable growth in working with Unity: as I watch and listen to them work, I observe most of the conversation is about the problems of the domain, not problems with the technology.
Yesterday I started reading Clean Code, by Robert C. Martin. I've been enjoying it and am considering using it for Fall's CS222 class, but as I read it, I was forced to acknowledge the dual roles I have been playing on the digital archaeology project—or perhaps, the dual roles I'm not playing.
Early in the book, on page 6, Martin describes the tension between managers and developers, specifically with respect to a manager's need to meet production goals and a developer's need to keep code clean.
I had a discussion (moderated by Google+) with the technology team just yesterday in which they pointed out that our methodology had been ad hoc and that formal code reviews would probably have helped our progress. It forced me to realize that I had been acting only as a project manager, trying to push this ambitious project into its five-week timeframe without stopping to consider the needs of the developers to write clean code. More specifically, I fear that I did not uphold my duty as an instructor to help the students learn how to do these code reviews, how to write usable code. David's recent post on the team blog highlights a symptom of this problem: we both saw that some of his code was unclean, but I fear I did not adequately authorize him to be able to tell me that he needed the time to clean it up. That is, if I only criticized it but did not impart on him the authority to deal with the criticism, then it was a learning opportunity forever lost.
Not that this has all been bad, by any means. Watching the team learn .NET with almost no prior introduction to it was great, and as I mentioned above, their savvy with Unity is laudable, especially after such little calendar-time working on it. Several times, we have been able to reflect on our lessons from Morgan's Raid and apply them to this new context, for both technical design and experience design issues.
But, as this is my place for reflective practice, I feel it is important for me to reflect on the feeling of guilt that washed over me as I read Martin's book. The challenge for me, moving forward, is to me cognizant of my two roles. This is significant for project-oriented, inquiry-based learning. For me to be a facilitator of learning, it's not enough to be a project manager: I need to be aware of those times that the schedule needs to be adjusted in order to help the team to understand the "principles, patterns, practices, and heuristics" that then they can "grind... into your fingers, eyes, and gut by working hard and practicing." (Martin, Clean Code, p.xxvi)
Yesterday I started reading Clean Code, by Robert C. Martin. I've been enjoying it and am considering using it for Fall's CS222 class, but as I read it, I was forced to acknowledge the dual roles I have been playing on the digital archaeology project—or perhaps, the dual roles I'm not playing.
Early in the book, on page 6, Martin describes the tension between managers and developers, specifically with respect to a manager's need to meet production goals and a developer's need to keep code clean.
"But wait!" you say. "If I don't do what my manager says, I'll be fired." Probably not. Most managers want the truth, even when they don't act like it. Most managers want good code, even when they are obsessing about the schedule. They may defend the schedule and requirements with passion; but that's their job. It's your job to defend the code with equal passion.
I had a discussion (moderated by Google+) with the technology team just yesterday in which they pointed out that our methodology had been ad hoc and that formal code reviews would probably have helped our progress. It forced me to realize that I had been acting only as a project manager, trying to push this ambitious project into its five-week timeframe without stopping to consider the needs of the developers to write clean code. More specifically, I fear that I did not uphold my duty as an instructor to help the students learn how to do these code reviews, how to write usable code. David's recent post on the team blog highlights a symptom of this problem: we both saw that some of his code was unclean, but I fear I did not adequately authorize him to be able to tell me that he needed the time to clean it up. That is, if I only criticized it but did not impart on him the authority to deal with the criticism, then it was a learning opportunity forever lost.
Not that this has all been bad, by any means. Watching the team learn .NET with almost no prior introduction to it was great, and as I mentioned above, their savvy with Unity is laudable, especially after such little calendar-time working on it. Several times, we have been able to reflect on our lessons from Morgan's Raid and apply them to this new context, for both technical design and experience design issues.
But, as this is my place for reflective practice, I feel it is important for me to reflect on the feeling of guilt that washed over me as I read Martin's book. The challenge for me, moving forward, is to me cognizant of my two roles. This is significant for project-oriented, inquiry-based learning. For me to be a facilitator of learning, it's not enough to be a project manager: I need to be aware of those times that the schedule needs to be adjusted in order to help the team to understand the "principles, patterns, practices, and heuristics" that then they can "grind... into your fingers, eyes, and gut by working hard and practicing." (Martin, Clean Code, p.xxvi)