The friction in class seemed to finally come to a head this week between the teacher’s methodology and the classes expectations. Due to the extended nature of the discussion on several other group projects and a long discussion on the agile nature of the classroom experience (tying the learnings into the teaching methodology) my group was unable to present our AMP project two assignment
Unfortunately, the key learnings from this week aren’t directly related to a particular agile technique, or even to that of the assignment in of using agile as part of a traditional knowledge area. I broke down what I learned in class here through the contentious conversation between my classmates and the teacher about the the class itself.
- Agile only works when everyone is using it.
It is painfully clear that many of the students have considerably different expectations of the class than that of what the teacher is offering in it. Since not everyone is willing to use agile concepts as part of their learning about agile it is creating friction within the classroom setting. Although some students are very adaptive in the learning process, many still want the traditional method of lecturing and outlined note taking to compromise some, if not all, of the class time. This puts them at considerable odds with both the agile concept itself but also the application of it in the classroom dynamic.
I will admit for myself, it has not been easy adapting myself to this. Selecting the right key points to highlight as part of my notes and follow up outside research on has been difficult. Some of the lessons seem convoluted and so undefined I’m not sure what, if anything, I should be taking from them yet. And, I do find myself dissatisfied with the depth of information and available documentation (which I would use to reference learnings from later in future application) so far. However, I’m trying to be open to the concept and I’m using the projects, this blog, chats with classmates and friends, etc. to help shed critical light on both the process and the information itself. What actually boggles my mind is that there are so many in the class who’s expectation is that the teacher will provide the finished end-documentation, rather then them creating their own for themselves. Many in the class appear my age, or older, and in HS, as an undergraduate and through most of my grad school education teachers rarely provided their lectures, you were expected to document it yourself (record and transcribe if allowed, take own notes otherwise) – my background in doing this is actually proving very beneficial, since in an agile environment you have to document as you go (meeting minutes, etc) rather than having a formal requirements doc provided in advance.
However, since not everyone is attempting to use agile, no one is really using it. It’s difficult to be agile in a environment that begs to be traditional and agile is about efficiency.
- Communication is Paramount to success
Part of effective expectation setting comes in communication efficiency. One of the things I’ve noted is that communications aren’t efficient overall. The lack of defined structure in the classroom setting contributes to this. The teacher’s intention is probably for some kind of emergent leadership to happen or that in working in an XP type environment to create the class itself it’ll occur but thus far it hasn’t. Furthermore, the lack of defined requirements for the projects is also contributing to this. Again, the teachers intention is probably to use DSDM for us to find those requirements or SCRUM to manage our outputs to iteratively produce requirements, etc. but again, thus far, it’s been ineffective, in part because I don’t think it’s been established that that’s the intended lesson.
The feedback loops are delayed by the time between class and the lack of communication by a key stakeholder through that part of the process is hurting many student’s ability to either understand the inherent lesson or apply it to the assignment itself. Furthermore, the closing portion where the project is wrapped up and key learnings for the next iteration are developed feels inherently lacking. It’s painfully clear from this week’s conversations that some in the class never wrapped up the learnings of the first project before moving onto the second and without that defined closing step by the teacher they are unable to effectively express their knowledge.
Rather than the class feeling collaborative it feels defensive and the key reason for this I believe is in the way communication patters were developed early and how information is being provided and processess. One good thing to come out of all this though is these are great insights to what my part of the assignment is.
- Adaption is as important as adoption
Apart from just agreeing to be agile, adapting to the situation at hand is seemingly a key tenant of many of the agile techniques and a core part of applying them to the knowledge areas. Even some of those that want to adopt agile in the class seem to be struggling with adapting it to their learning process throughout the class. What worked at one point may not work again and it seems there’s an expectation that it should.
I’m sure that the nature of the classroom setting and everyone’s differing needs from it is contributing to the difficulty in adapting to the changing environment as it occurs. For me, having the majority of the classroom time seemingly be a tangent from the core learning environment to criticize and critique the teacher’s methodology was a difficult thing to adapt to. To me it seemed like a huge waste of time and resources to hold the discussion the way we did at the time, but I see how it can be interpreted in retrospect to be a part of the learning process. I do doubt the discussion’s impact on some class members still, but I do see the potential for it to help future iterations of our projects and it’s application in the real world (as I’ve experienced impasses in projects that lead to similar situations that had to be difussed).
- Expectation setting is imperative
What I think the previous points more than allude to is that expectation setting is key and my guess is that this in-and-of itself will be an iterative process. If each class represents a Scrum Sprint or FDD deliverable, etc. than there are many parallels to be had… such as the retrospective afterwards leads into the next set of learnings to be applied to the requirements. If everyone understands that equally it can be successful and that comprehension. I question if everyone in the class had the same expectations, or if we’ve even yet come to that common ground in reaching them since the end of last class. For me, at least, I think I’m on the same page as the teacher in what the expectation of my output should be and what I should be getting out of the experience.
The Group Dynamic & Strategy
Since my group didn’t present we re-assessed our project based on what we saw of other groups presentations and the teacher’s evaluations of them. Gleaning some basic insights from them, we took some time at the beginning of the week to each re-asses the initial draft and determine what we’d like to do with it.
I kept my time spent on it this week just below the two hour budget since I’d overspent in previous weeks and still felt a little frustrated from class itself, thus not being inspired enough to shift gears and produce something spectacular.
The strategy remained essentially the same this time in how we worked together. Once we had time to explore our notes and revise our general concepts we met quickly and then proceeded to trade some emails. I led the initial scrapping of the draft and complete revision based on some background information I had from my MBA Op Mgt coursework which felt relevant to adaptive communications strategies that would work in agile.
Conceptually, we were just going to present what we felt was an overall communication’s strategy and not one that focused on a single technique. Again, not being sure we were actually interpreting the assignment right we didn’t focus on a detailed finished product but rather a broader outline to work from and the email-t0-chat-to-email-to-chat process seemed to work well for producing the document.
Three principles in establishing communication:
- 1. Know your Audience:
–Who is the stakeholder–What is their relationship to the project–What are their needs and expectations
- 2. Know your Message:
– What information is relevant–Why is it important
- 3. Know your Delivery Method:
– How are you going to disseminate it–What is the expected responsorial method
Four ways of Fostering good Agile Communication:
- 1. Be adaptive:
– Different Audiences, Project States, Messages and Cultural environments may require different methods so be flexible in a communications strategy and open to change
- 2. Strive for honesty / transparency:
– Emphasize on acceptance and tolerance to reduce misrepresented or incorrect information being disseminated
- 3. Empower the team:
– Facilitate solutions based thinking and allow everyone who should be communicating a voice
- 4. Create Feedback loops:
– Produce ways for everyone to provide feedback at every stage
Tying process into the Communications Knowledge Area
- Envisioning – stakeholder identification
- Speculating – plan for aspects like co-location and understand stakeholder needs
- Exploring – trying different information distribution methods
- Adapting – report and change as necessary
- Close – retrospectives and performance discussions
Five Possible Agile Communication Facilitators :
- 1. Co-location:
Emphasis on collaboration
Reduce lag time between responses
- 2. Existing Relationships / Familiarity:
Reduces ramp up time
Reduce need for team-building to establish trust
Produce more honest and transparent communication
- 3. Diversity:
Allows for more diverse knowledge bases to be tapped and broader communication exploration
- 4. Cross-trained:
Allows broader understanding of all role responsibilities and more contributors to communication
- 5. Servant leadership:
What have you done today?What will you do tomorrow?How can I help you by removing impediments from your way?
Three keys to effective Communication in relation to Agile:
- 1. Listening:
Hearing is just perceiving sound, listening means perceiving all the cues verbal and non-verbal being providing and interpreting themCo-location, an empowered team and can all help facilitate listening
- 2. Clarification:
Ask questions and paraphrase what you understand to ensure comprehension. This will help reduce confusion, conflict and potential unnecessary iterations.An empowered team using available feedback loops make this possible, co-location can quicken the process itself, diversity can help expose potential problems through the process
- 3. Acknowledgement:
Acceptance of ideas creates buy-in and this is done through familiarity and transparency
A Final Point on emphasizing informality:
- Move quicker!
Spend less time crafting, editing, disseminating, clarifying, revising, and re-disseminating.Everyone else spends less time digesting, requesting clarity, re-digesting and sifting through multiple versions of documentation.This can only be done with the right teams using the right tools to facilitate the communication and documentation process to avoid confusion.