In my January post about planning for 2018 with user stories, I shared three of my epics for the year, related to my work as coordinator of our Professional Writing and Rhetoric (PWR) program, faculty leader of the Design Thinking Studio in Social Innovation, and Scholarship of Teaching and Learning researcher and writer. Below is an update on my progress during the first third of 2018 – a review or demo of what I’ve accomplished.

While we should definitely take time to acknowledge and celebrate our successes along the way, my purpose here is not self-congratulations, or self-flaggellation for that matter. The review is the third of four sprint meetings, or rituals, in the Scrum process, designed to hold team members accountable for finished work but also to provide an opportunity to celebrate progress toward larger goals. I’ve made progress and experienced setbacks like we all do every semester. A review helps me see both more clearly in order to plan for the future.

EPIC 1: As a leader and faculty member in our PWR program, I want to create a solid foundation for the new major in terms of marketing, recruiting, and prioritizing PWR so that I/we can realize our dream of a strong and vital PWR presence on campus and in students’ education. In spring 2018, we successfully shepherded the proposal for a BA degree through the university curriculum committee and will officially be in the catalog for AY 2018-2019. We marketed the new major during preregistration using digital signage, emails to students and faculty advisors, new course posters, and word of mouth. On the flip side, our courses got lost during pre-registration because we changed to our new prefix, and enrollments were lower than we would like. My colleagues and I have work to do to get the word out and get students into our classes. I also need to prioritize PWR leadership next semester.

EPIC 2: As a leader in our Design Thinking Studio program and related design thinking initiatives, I want to collaborate with colleagues and students to create a viable curricular and co-curricular pathway to the Studio so that I/we can provide our students with powerful learning opportunities that focus not just on knowledge acquisition and skills but also on core liberal arts capacities like empathy, resilience, perseverance, collaboration, and curiosity. I really should have broken this epic in two, one for running the second pilot and one for creating a viable model. Regardless, so far, so good on both. The second pilot finished up last week and was a success by many metrics. It was really different than the first pilot just in terms of the students themselves, so we have some analysis to do before going into the third pilot next spring. I’ve also been working with faculty in the College of Arts and Sciences on possible immersive semester and course clusters in order to figure out a potentially viable model for moving forward, with or without design thinking. All of this work will be ongoing in 2018, but I’ve made good progress.

EPIC 3: As a writer, I want to develop, visualize, and sustain a clear pipeline of my writing projects in their various stages so that I can better integrate writing into my daily habits, especially during the Spring semester when I tend to de-prioritize anything writing-related. I’m most behind here. Some unanticipated health issues arose this spring, and I’m honestly still dealing with the mental hit they caused (I’m fine physically though; luckily false alarm!). On the bright side, my colleagues and I officially signed a contract with a prestigious academic press for an edited collection on redesigning and reimagining liberal education in US universities and colleges. I also got both revise and resubmits on my plate turned around and back for second review. I have three articles and a sample case study for the edited collection I’d like to write this summer, but I want to take care of myself first. We’ll see what happens over the summer.

So now what? For Epic 1, I’ll work with my colleagues on program assessment, marketing strategies and materials, and strategic planning. Since teaching courses that get students talking is a primary way of marketing on campus, I’ll prep an excited Feminism and Rhetoric course to run in the fall. Epics 2 and 3 are interrelated in terms of the writing I want to do this summer, so I’ll work to get two articles completed as lead author and contribute to others my Design Thinking Studio peers are working in as well.  I wrapped up a second workshop on immersive curriculum ideas and will report to my dean and see what happens next.

When I did my user stories in January, I didn’t include an epic for Agile Faculty. I’m remedying that now. Epic 4: As a published author and future consultant, I want to continue building the Agile Faculty brand to increase visibility and potential for consulting clients, keynote speaking, workshop facilitation, and other media (videos? podcast?).

If you wrote yourself user stories at the start of the year, how did you do? What are your summer goals, and how will you reach them? if you haven’t written stories for yourself, how might you use them to shape your summer work?

Several years ago, I participated in a book group sponsored by our university’s Center for the Advancement of Teaching and Learning (CATL). We read and discussed Therese Huston’s Teaching What You Don’t Know (more recently I read her How Women Decide which I also recommend). We’ve all been in that boat, maybe the department is understaffed and needs help covering a course outside our expertise. Or a chair or dean “suggests” you widen your course portfolio. Or it’s a required course everyone in the department shares. We do what we can to make sure we are good department citizens and to ensure our students have strong learning experiences, even when we might be out of our depth.

Since I teach undergraduates exclusively, I’ve taught every core course and many of the electives in our Professional Writing and Rhetoric program (soon to be a major in Fall 2018!) as well as numerous sections of our first-year writing course and even two sections of literature (I was not very good, but one was vampire lit and one took place in Ireland so they were definitely interesting). I’m better at some and average in others, but I can still support my students in their learning journeys through my field.

But sometimes, maybe we offer a course on a subject we don’t know much about because it’s timely, meaningful, necessary, important. In the fall, I’ll be teaching a special topics course on feminism and rhetoric. There is a rich body of literature on women’s rhetorics and rhetorical silence, examples from classical times through to Emma Gonzalez today, and extensive theory. I used some social and political capital to swap it out with another elective that was already scheduled. I know this class will attract many students from diverse backgrounds, but I also know many , if not most, of the will know WAY more about feminism and women’s issues than I do.

I’ve been imagining the first day of the class since it went on the books. How do I say I’m trained in old dead white guys and don’t know much about non-old dead white guy rhetoric? How do I explain that gap in my education? Was it a conscious choice I made to avoid it, or were the classes not offered in grad school? Even if they weren’t offered, how had I just not noticed the absence?

Maybe I will just admit to those students in the fall that I (un)consciously avoided this subject because it makes me uncomfortable as a middle-class cis white woman and that I didn’t know to consider or talk about these issues without fear of possibly and quite unintentionally upsetting someone. And that I know now this makes me part of the problem.

So I’m offering this course. To fill that gap in my education; to learn from students far more knowledgeable and skilled in discussing issues of gender, race, and sexuality than I; to become better for it. Hopefully they will be OK about that, and we can learn together. I’ll do my best to pull the most appropriate theory, documents, histories, women in rhetorical theory, and they can help me with the feminism piece.

I have a lot of reading to do this summer. But part of being an Agile faculty member is being open to learning new things from those around you, trusting others’ experience and truth, being open to situations in which you might fall on your face, trusting that someone – even our students – will be there to pick you up and explain how not to fall next time. I’ve already got a stack of books on women’s rhetorics reading to be annotated. I’ll probably reread Huston’s Teaching What We Don’t Know for additional support. And whatever happens during the semester,I know students will learn and I’ll be a better person, teacher, and mentor at the end of it. So here we go.

My professional writing students often get annoyed with me when they ask questions about an assignment because my answer is usually “it depends.” The same is true if you are wondering if you can put together cross-functional students teams for a group project in one of your courses. A colleague in computing sciences who tries to do Scrum in his programming courses says cross-functional teams are rarely possible because students are all learning the same platforms and roles; expecting to create a Scrum team with developers, UX/UI people, and QA testers is unrealistic in this context. But

I think you can create teams with mixed skills, even if they are not truly cross-functional.

An ideal cross-functional team has people with useful skills who contribute to the completion of work every sprint. In my upper-level project-based professional writing courses, I will often get students from my program, creative writing, communication design, strategic communication, and multimedia authoring. When that happens, I can mix up teams with writers, designers, and students comfortable with design technologies.

Sometimes you might get a class with a good cross-section of majors and student abilities, but it is probably uncommon. So what do you do? I give students an “inventory” to fill out before the group project. It asks them

  • what words they would use to describe their strengths and weakness in a team setting
  • what they value most in a team member
  • how comfortable they are with a variety of “hard” skills, such as working with specific software that might be useful in the course, writing in certain genres, analyzing survey data
  • which”soft” skills are their strengths, such as setting a meeting agenda, dealing with conflict, building relationships with team members and community partners/clients, being a motivational leader, etc.

I’m sure to tell my students that the inventory list of hard and soft skills is exhaustive, so no one expects them to be skilled at everything. Areas they rank themselves lower on are opportunities for growth in the team experience.

I then take those inventories, combine it with my knowledge of each students strengths, weaknesses, preferences, and learning goals to create teams with a good mix of skills. The groups I create mix their hard and soft skills as best as possible. I want them to be able to strengthen themselves by leading at some point but also by being humble enough to learn from each other. Sometimes the groups fall out easily and sometimes it’s harder, but I have found this method to be far better than other ways of putting groups together because there is more intentionality.

The most important part of this method for putting teams together is actually telling them WHY I put them into a team. Once I assign the groups, I go around to each one and explain why I think they will make a good team. I point out skills and strengths for each of the them and ways they can learn from each other. I then ask them to create a competency matrix of their skills so they can see it for themselves.

This method has worked really well for me. Sure, you get teams that implode sometimes, but that’s the nature of collaborative work. Happens in industry too. Overall, students appreciate knowing why I put them together in a team because we often don’t explain that to them and they see it as random. And it gives them a place to start when building the team relationship, especially when we do 10- or 12-week group projects.

How do you put student groups together? Might this method work for you?

I saw a post on Twitter a few weeks ago that I can’t get out of my mind:

Jeffries can be cantankerous (which is awesome), but he’s dead-on with this one. He’s talking about software companies and teams. Companies implementing Scrum tend to have one of a few major problems (based on what I’ve read):

  • implementing Scrum without addressing waterfall or traditionalist company culture issues that will ultimately doom an Agile approach
  • implementing “Scrum-but,” basically halfheartedly starting to do Scrum without all of the actual pieces of the framework (“We do Scrum, but we don’t do stand-ups or cross-functional teams.” – uhh, that’s not Scrum, dude).
  • implementing Scrum, and expecting it to magically resolve all of the companies’ problems, then getting disillusioned when it doesn’t.

Scrum is a framework, not a panacea or a quick fix for culture issues, team dysfunction, top-down management interference, lack of trust and respect among employees. Companies that implement Scrum without a true commitment to the entire framework might feel blind-sided when these issues reveal themselves. Companies that know about their dysfunctions and implement Scrum with integrity are prepared to address these issues as they are more clearly revealed.

Scrum is really hard to implement in organizations that don’t start out Agile. There is often too much legacy culture and “how we do things around here” to get past, and the commitment required to do it is often just not there. Culture eats strategy for breakfast, right?

What the heck does this have to do with faculty and higher ed? Sure, it’s not a direct correlation, and really what I’m preaching in Agile Faculty could be considered “scrum-but.” But just imagine trying to run your institution with Scrum, flipping a switch overnight. Or even just your department. Academic culture is rock hard and possibly impossible to break through at existing institutions.

Scrum can work for individual faculty and small groups like research teams and committees. I wouldn’t have written the book if I didn’t believe that. But we also have to remember that we are facing centuries of ingrained academic culture, much of it so far in our heads we don’t even recognize it as our operating system. On an individual level, remember that Agile and Scrum won’t simply solve your productivity problems right away (sorry) and they might reveal to you some other problems, maybe in your workload, priorities, values, approach to self-care. That’s valuable insight. I’m on that journey and have those personal revelations at different points along the way. Scrum can be transformative in helping you know yourself and achieve your goals, but it’s not a cure all. Scrum won’t fix your problems, though it will likely reveal some. It’s up to you to fix them.

I attended the 2018 Conference on College Composition and Communication in Kansas City recently, the largest gathering of instructors and scholars of writing in higher education. I presented on writing and sticky notes in the Design Thinking Studio, but my absolute favorite panel was on rhetorical failure. In rhetoric and writing studies, we often teach students that if they are not successful in their communication, they must not have understood the audience or rhetorical situation well enough to be persuasive. But that’s not always true – and that’s a ton of pressure on the writer or speaker when elements of a situation may be totally out of one’s control.

One presenter told the story of being one among many community members to attend a local government meeting to protest a plan. They spoke well and covered all angles of the argument. They should have been persuasive. But they lost. Because the thing they were protesting was already a done deal and this meeting a formality that was never going to change anyone’s opinion. We probably all feel like this a lot these days given what’s going on in law and politics.

But one of the biggest messages from this session for me was that we, as a Western society, have long fetishized success…but now we are fetishizing failure too. It’s perhaps most obvious in the Silicon Valley entrepreneurial world now, where stories of the world’s biggest tech giants coming out of dorm rooms and the garages of college dropouts are quickly being replaced by narratives about how many ventures fail before a founder find the “right” one (if ever). Stories abound, like how Spanx founder Sara Blakely’s dad always asked them at dinner, “What did you fail at today?” to encourage his children to experiment and take risks. Silicon Valley’s mantra “fail fast, fail often” is chanted by the start-up world, and entrepreneurs commiserate at FailCons about their bombed businesses.

In higher ed, articles about how to teach students resilience and grit abound, claiming that we don’t teach them to fail or encourage them to do so, so how can they be prepared for the world? Faculty write op-ed about adding “failure” to their courses. Major news outlets like the New York Times are picking up stories about education and failure. There’s even a consortium of major colleges and universities.

In my own work in the Design Thinking Studio, we talk all the time about want students to learn how to fail, to know what it feels like to have an idea they really like shut down by the client or partner so they learn not to take that personally. I’m constantly saying, “failure is just data.” Students buy in to the mantra, but it’s much harder in practice. At best we may be creating an environment for productive frustration rather than failure.

But we also have to acknowledge that failure can be privilege, those with safety nets, economic resources, support are more likely to take risks than those who do not. Most of those garage-dwelling dropouts and dorm room heroes are white males. and we have to acknowledge this as we consider adding failure to the curriculum – what does that even mean? When grades are the coin of the realm, can all of our students afford to take intellectual or economic risks? Is integrating “safe” failure experiences even possible in the traditional constraints of higher education? It’s a lot to think about. Carefully and intentionally.

Here are some of my favorite ideas and questions from the rhetorical failure panel to further spur your thinking.

 

 

 

 

 

 

As I mentioned last week in my “Why I’m Not Sprinting” post, I’m not always Agile. Sometimes my Scrum board becomes the place I fear the most (shout-out to Dashboard Confessional). I will sometimes leave  projects off the board even though they are taking up much of my time. Even though I’m committed to the idea that vitality is more important that productivity, I don’t always take my own advice.

I don’t always take my own advice.

This comes from a few places, I think. First, I’m a natural workaholic. I come by it genetically. I don’t know how to not work all the time, whether I like it or not. I do enjoy the academic writing process when I have interesting data or a compelling theory to chase down. I like giving faculty workshops and helping people feel productive and engaged through my Agile Faculty work. I like creating new things, innovative classes, programs, proposals. But I struggle with getting overly excited about an idea, working it out and proposing it…and then ultimately having to follow through.

I’m not very patient, so when I have an idea, I dive in and make it happen, often without thinking about whether I have the time or energy to dedicate to the new project or what it will cost in terms of splitting my focus on other things I’ve committed to or created. Six or seven conferences in one year? Sure, I need to promote the book! Co-edit a special issue of a journal and an edited collection at the same time? No problem; can’t be that much extra work. Try to write at least five articles about the Studio program in one year? Absolutely, don’t want the data to get cold. You can see where this is going.

No one ever taught me how to be content.

But even more importantly, I think, is that no one ever taught me how to be content, how to decide when I have enough going on to maintain a level of work that is sustainable rather than stressful and overwhelming. I don’t know when to stop working, when to stop adding new ideas to the Scrum board, when to relax. Like many of our students, my life has been about building first the transcript and then the CV, looking smart and capable and respectable. Because I’m not sure how much of this ethic is about my own drive or something else.

Is this drive part of imposter syndrome? An advanced version in which I keep turning up my productivity and output in order to continually prove I belong in academia and deserve respect? Or is it just part of who I am, this drive to do more and more? I suspect I’m not alone in this feeling.

Chasing productivity isn’t Agile; it’s a fast way to burn out.

But, at this point, I’m more often than not running on stress hormones, even about the projects I’m genuinely excited about. So I need to start taking my own advice. In the first chapter of Agile Faculty, I talk about the narrative of stress many faculty labor under but also that we can turn that narrative into one of vitality and engagement when we find ways to balance productivity, engagement, creativity, and personal pursuits. Productivity can lead to vitality, but vitality should be the goal all along. Chasing productivity isn’t Agile; it’s a fast way to burn out, which is documented in the Agile and Scrum values. Making time for self-care and self-honesty helps with vitality and, ultimately, productivity too.

Over the next few weeks, I’ll reflect on those values and how they can inform the path toward faculty vitality. I’ll report back here. In the mean time, how do you define career or personal vitality? Are you stuck in a productivity trap too? How can we teach each other and those coming up after us how to be content in our work and when enough is good enough for now?

 

Why do you do group projects in your course(s)? Is it because you value collaboration in your field and want to make sure students have some experience in that? Or is it because you are “supposed to” do group projects? In talking with faculty over the last eight years, the answer seems to fall somewhere between those two poles. But almost everyone I talk to admits to not spending time in class talking about good collaborative strategies, and most have designed projects that, at best, ask students to cooperate, not collaborate.

I found Scrum because I was disappointed in how my students were managing group projects I assigned them – largely dividing up the work, slapping it together at the last minute, and calling it good. But really what else were they going to do? I didn’t talk to them about how to collaborate and didn’t give them much time in class to work together while I monitored.

The last chapter in Agile Faculty talks about how to design effective group projects using Scrum, but the advice for thinking about whether or not your group assignment is effective or not transcends Scrum. So as you are thinking about that end-of-semester group project, ask yourself the following questions:

  • How does the project directly help students work toward the course learning objectives?
  • Is it more important that students cooperate or collaborate for the project? Do they actually need to work with their peers to complete the task
  • Why is this assignment a group project instead of an individual one?
  • Is the project realistic in scenario or connected to things students value?
  • How much time will the project take – and will you use class time to allow students to work on the project?
  • Can you make it clear in the course schedule that you value the assignment as a means to meet course learning goals?
  • How much control might students have over their own learning and deliverables while completing the project?

Chapter 8 does into depth withe these questions, but taking time to consider these ideas can help you decide if your assignment really needs to be a group one, why you are adding this assignment to your course, and how you might improve the assignment to reach your course outcomes.

At the end of 2017, I shared with you my own year-end retrospective, a review of my process for accomplishing goals in 2017. And now that it’s midterm for most of us, I thought I’d revisit the retro meeting as a way to do a process review of your activities and even those of your current courses.

The retrospective is the fourth meeting of the Scrum cycle, the last one before planning for the next sprint. The team and Scrum Master gather and review their team process during the finished sprint. They talk about how well they collaborated, what they could have done better or differently and how they will improve the team in the coming sprint. They might compare their actions over the sprint to goals they set for themselves previously or to a vision statement or team charter they created previously. However they frame the meeting, it’s about process and only process.

It’s fitting that this is a private meeting of the team. Remember the Scrum values – focus, commitment, courage, respect, openness – these have to start with the team themselves. The retro is one of the places in the framework that these values are honestly discussed in terms of how and how well they were manifested in the sprint.

During the first pilot of the Design Thinking Studio in Social Innovation, we taught the students to do retrospectives in their project teams, once using the starfish activity (right) and once using a scaled-down version of the “run the boat” activity (below). Each asks the team to brainstorm the good, the bad, the average about their teamwork during the sprint, then to visualize it in some way. The starfish categories are pretty straightforward. The sailboat categories are a little more creative, but the metaphors are useful.

How might you use retros? If you have your students do longer group projects, have them do a retro mid-project and at the end. This helps to remind them that process is just as important to work as the ultimate product. You could also do this with a research team or committee to refocus on the values of focus, commitment, courage, respect, openness.

A Retrospective in Action
The students in the first Studio pilot did something that surprised us last year, but it was powerful and something I want to do in future courses or leadership roles. Because the first semester was a true pilot in every sense of the word, we were playing by ear most of the time. And that was frustrating for all of us in different ways at different times. After we taught the students do a retrospective in their project teams, they asked if we could do the same activity, all of us, for the program itself. This was, in all honesty, scary for me because I don’t like verbal conflict and I knew the students were frustrated while I was doing my best to create a good experience under the circumstances.

So we all did the starfish retrospective activity, students and faculty alike brainstorming ideas and concerns on individual sticky notes before compiling them into the appropriate categories. While it was still stressful because of the potential for conflict to bubble over, the activity was extremely valuable. We were all able to share pros and cons using the language of the activity without singling people out for criticism. It allowed the faculty to better explain some things that were truly out of our control and places where we shared their critique. It allowed students to productively articulate frustration and contribute to the solutions rather than simply venting and potentially hurting feelings. We used this experience to reset the program as best we could, but it helped build further trust and respect that was needed.

You might consider doing a midterm retrospective in one of your courses, letting students share their experiences and suggestions. You might also try this with your research team if conflict is rising or with your department/program colleagues to remind everyone that focus, commitment, courage, respect, openness are part of the experience of working together that have to be built, tended to, and sustained. But importantly, if you do a retrospective, collaborative agree on what everyone will work to do better next to continue to improve the experience for everyone. The action after is almost more important than the retro itself.

I’d love to hear from you if you’ve tried retros and how it went!

 

What is your definition of done? Seems like a weird question, but think about it.

When is a research project ever really done? When you submit an article? When you become interested in something else? When the funding runs out? What if the article is rejected or earns a revise and resubmit? Did that new direction you are interested in come from something in that original project? What if you are in limbo waiting to hear about a grant?

Same question with courses. When you turn in final grades? What if you have to teach the course again, the next semester or even a few years later? What if a student in that course wants to continue working with you on a project started that semester?

Andre service commitments ever really done? In my experience, even if the topic of the service changes, old service breeds new service. Do reports crafted by one committee just die, or are they taken up by other groups to guide new or extended work? Do decisions made by some committees, promotion and tenure for example, live on in the conversations and activities of the university and faculty lives for a long time to come?

In Agile software development, teams often have to come up with their collective definition of what done is, as they learned a good lesson from waterfall teams. In waterfall environments, when teams are separated by function, software was often considered done by a team when they “threw it over the wall” to the next team – developers punting their code over to the testers and wiping their hands of it, for example. But the project starts for the testers when it comes over the wall – and more often than not, the code doesn’t work or doesn’t mix with another developer’s code. Who is responsible for it now?

According to Mike Cohn, a Scrum team’s definition of done (DoD) is a set of things that must be true to consider the project or story done. It’s like a checklist, an agreed upon set of standards all code must meet before being released that says “this is ready.” Good teams post their DoD statement somewhere in the team room and use it to assess every story before they can check off a story at the end of sprint. Having an agreed upon DoD gets teams away from questions like “Are you done? No, I mean, done done? Having a common DoD on cross-functional teams makes sure that no one relinquishes authority and responsibility for the code until everything is done, soup to nuts, planning to testing.

Students definitely have school-specific definitions of done when it comes to course work and papers. Sometimes it feels like most will turn in a paper and not think about it again until they get it back with a grade. And even then they will often look at the letter or number value rather than process any carefully written feedback from the instructor.

Yes, that is a gross overgeneralization, but it’s important to talk to our students about what “done” means. As a rhetorician and writing professor, it’s my job to help students realize that all communication is part of a chain that is doing something in the world. Even if it’s them turning in a draft, me commenting, them revising, etc., that work accomplishes something – learning. Every email or meeting with me is an opportunity to build or break down a relationship. Every article they read and respond to is a link in a conversation going on all around us. It’s important students realize that writing, communication, collaboration are all parts of chains that get work done, not just assignments to earn the current currency of the realm.

And we as faculty need to assess our own definitions of done as a way of possibly managing our own productivity expectations and scheduling activities.

So how do you define “done” in your own work? For your students?

“What are you doing over spring break?” I’ve been telling people (and myself) that I would be conducting an #AFSprint writing challenge this week over our spring break to finish a third article on the first Design Thinking Studio in Social Innovation pilot. It took a long time for me to really process the emotional and intellectual experience of last spring, and I should* be writing about it since the program is so new and innovative. So I’ve been trying to decide what to work on for several weeks – should* I work on an article about student identity and goals setting that is about half finished (but similar to another article I just submitted), or maybe one on emotions in the Studio service-learning experience (which got sparked when I was working on the identity article), or maybe one on retrospectives as student reflection (why not? they were interesting). But, then, after I made an unexpected breakthrough in my thinking about a disciplinary angle on the Studio while prepping for my CCCC conference presentation last week, I should* definitely work on that article before I forget, right?

I should definitely work on that article over Spring Break, right?

I’d also been hoping to recruit others to sprint with me so I could test out plans for #AFSprint to be a signature service, Scrum-based writing accountability groups, that I could offer through the Agile Faculty consulting business I hope to grow. To do that effectively, I should* have developed some handouts, recruited some people who are already interested in Agile Faculty to participate, and set up a conference call to help those folks set up their backlogs for the week.

As I typed the two paragraphs above, I started coughing. An asthma cough in my throat. I do have asthma that usually only acts up if I get a cold, but as my husband has repeatedly told me over the last couple of years, that cough isn’t asthma. It’s a tell. It’s anxiety.

That cough isn’t asthma. It’s a tell. It’s anxiety.

Why am I anxious? Just look at all of those “shoulds” in the first two paragraphs. I should be sprinting. I should be writing about the first Studio pilot. I should be working on the disciplinary article, especially since it’s attached to a grant. I should be creating documents and working on AF as a business since the book just came out. I’m wasting time, data, opportunity if I’m not writing or working on AF.

I’ve been putting off for weeks deciding what to do, feeling guilty that I was prepping for two conferences instead of working on the #AFSprint materials, that I was working on two more conference abstracts for AF workshops for faculty developers, that I haven’t responded to some of the second cohort’s student reflections and plans. Coughing when I think about it all.

So I’m not sprinting this week. I’m writing this from my favorite cafe (which is about 45 minutes away from campus) where I just finished my favorite croissant breakfast sandwich. I saw A Wrinkle in Time yesterday – one of my favorite books of all time. I got a pedicure. I’ve scheduled a massage and a haircut (I’ve been so stressed I haven’t been to the stylist in 14 months). I’m going riding at least twice, even though I’m so out of practice, I feel disappointed in myself for putting work above everything. I’ll have lunch with friends I haven’t seen for a year on Friday. Yes, I’ll work. I can catch up on those reflections and student plans, write that conference proposal, tease out the idea for the disciplinary article, work on posters and marketing materials for the new PWR major starting in the fall. But I’ll do them in my own time this week, in the mornings, before I relax and refresh in the afternoons.

No one ever teaches you when is “enough” in academia – enough writing, enough research, enough service, enough time available to students. When will I know I’ve done enough work to be promoted to full professor? Do I even want the extra work associated with being full? Why am I churning out conference and book proposals – do I really care about the subjects, or do I think it’s expected of me now that I’ve published one book? When will I be good enough? This is a topic I’ll definitely come back to here on the blog. Agile Faculty is about vitality as much as it is about productivity. In fact, vitality is more important.

Agile Faculty is about vitality as much as it is about productivity.

This week I’ll work on being honest with myself about what I can do and what is too much. I’ll revisit my plans for the year and make some hard decisions about what is enough. Hopefully I won’t cough the entire week.