I’m happy to announce that although I am still not much of a programmer, I have discovered some interesting things about Agile. So off we go…
1. Agile is a mindset, not a prescription. When people say they are “doing Agile” or a project is being run as an “Agile project,” I’ve discovered that there is probably some room for argument. They might be confusing Agile with something else.
The characteristics of Agile were cherry-picked from a variety of software development project approaches, including Waterfall, Extreme Programming (XP) and Scrum. Eventually some developers formally codified these principles in the Agile Manifesto. Although this makes it easier to describe Agile, it also makes it a bit more challenging to define it.
To work in Agile, team members gradually develop an “Agile Mindset” that favors consensus, small changes, continuous feedback and learning, and individual interaction. Being Agile means that team members operate under shared vision and personal accountability, while enjoying the autonomy that allows them to choose how to tackle the tasks they work on.
In my time with the Agile team, I found that this way of working was both more efficient and more satisfying. Each day was organized around value-added priorities rather than a fixed schedule.
2. The Agile Manifesto is open to (mis)interpretation.
In 2001, a group of 17 experienced programmers gathered at a ski resort in Utah to codify their common beliefs by creating the Manifesto for Agile Software Development:
We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:
- Individuals and interactions over processes and tools
- Working software over comprehensive documentation
- Customer collaboration over contract negotiation
- Responding to change over following a plan
That is, while there is value in the items on the right, we value the items on the left more.
I recently heard a project manager say that developers don’t like to write documentation because “the Agile Manifesto prohibits it.” As a tech writer and an Agilist, I had to object. Another person in the room helpfully piped up, “People over documentation, right?” No, not quite.
The second bullet above is the source of much confusion. Lazy developers might use this statement to get out of documenting their projects, but the developers I worked with understood that “working software over comprehensive documentation” didn’t mean “eliminate all documentation.”The clue comes in the final, bolded statement: “while there is value in the items on the right, we value the items on the left more.”
In an Agile mindset, documentation flows from working software and constant communication. It may come later in the process, or it may grow out of the user stories that guide each sprint. In a complex project, a technical writer can take on many of these documentation duties.
3. Tech writers have a stake in Agile development. At several junctures, our Agile team was threatened by reorganizations and efforts to mirror our success in other teams. We usually were able to fend off these threats by emphasizing team velocity: it takes time to bring a team through the “forming, storming, norming” stages, and we were unwilling to lose what we had.
But why keep a technical communicator embedded with the team? In my organization, only a handful of other projects had used Agile or Lean methodologies, and as far as I know, they never included technical communicators like me.
Technical communication experts suggest that even though technical writers on Agile teams focus on content, they can contribute to the team effort by providing usability input or helping with end-user testing. This type of participation creates a more visible role for writers, and allows us to offer more informed opinions—assuming we’ve been paying attention all along, as we should. It is also important to insist on accuracy by asking questions, gaining access to test systems and prototypes, and learning as much as possible about how the product works.
One of the criticisms of Agile is that its fast pace does not always lend itself to improving the user experience (UX) through testing. My presence enabled us to do a modest amount of usability testing to improve the interface. With limited resources, we performed 20 tests during a single four-month project. Because of the iterative nature of Agile, we were able to conduct two or three tests after each of the latest builds, recording impressions and problems to take back to the development team.
In conclusion, I plan to bring my Agile Mindset to future projects, whether or not they are using an Agile framework. The availability of different project management models means that teams can always figure out a way to work to best meet the needs of end-users.
I like to think that I base most of my workplace decisions on facts, not biases, but there’s no denying that we humans are imperfect. How might subconscious biases affect the decisions or judgments we make in workplace communication? You may be surprised.
A couple of months ago I wrote about The Halo Effect. This week, I read a terrific related article by Buffer’s Belle Beth Cooper. Citing numerous examples and experts, Ms. Cooper describes eight ways our minds can play tricks on us. I’ve added some workplace context to each of her points, but I’m greatly indebted to her for pulling together all of the research!
1. Confirmation bias happens to the best of us. Confirmation bias happens when we gravitate toward those who think like us. Ms. Cooper acknowledges the need for confirmation of our beliefs and acceptance by our peers, but there is a downside to this need. Gradually we tend to ignore or dismiss anything that doesn’t match up with our own beliefs. Considering the rate of change we deal with in most modern workplaces (technology, globalization, economics…), a confirmation bias can lead to significant problems down the road.
2. We confuse selection factors with results. This one is sort of a “chicken and the egg” situation. Ms. Cooper gives the example of a swimmer’s body: did the body become suited to swimming after training began, or was it already naturally suited to the sport because of broad shoulders, strong arms, etc.?
Or consider a high-performing university. Is it a result of great teaching or the careful selection of great students? Even if the answer is not completely clear, it’s important to understand how people (particularly advertisers) are prone to blurring the lines between causation and correlation. If you are marketing your company’s product, you may need to make the distinction at some point.
3. We fall for the sunk-cost fallacy. This one is tough to overcome. We are hard-wired to feel loss very strongly, and we can make some pretty poor decisions based on this feeling. Ms. Cooper cites the example of buying a ticket for a movie, only to belatedly realize that the movie is terrible. Should you stay to “get your money’s worth” or cut your losses and leave? Most of us would probably stay. But a more reasonable response might be to let go of the monetary investment–it’s over and done–and just move on.
In the workplace, we hang on to sub-standard software, hardware, processes, and many other things just to prove to ourselves that the investment was worthwhile. When do we make the decision to kiss that investment goodbye and cut our losses?
4. We fall for the gambler’s fallacy. If you play cards, this one is probably well-known to you. When you’ve lost, say, five hands in a row, you figure that the odds are in your favor for that sixth hand–surely this will be the winning hand–it has to be!
But probability doesn’t work that way. A coin toss has a 50/50 chance of landing on heads, no matter how many consecutive times it lands on tails, right? The lesson is that in both cards and the workplace, we can’t rely on luck or hope to turn things around. It usually involves a tough decision and some hard work.
5. We avoid cognitive dissonance by rationalizing our behaviors. This is a fancy way of talking about how we deal with situations that induce “buyer’s remorse.” To resolve the mental discomfort (cognitive dissonance) when we make a bad purchase, we either find a way to justify it (“I needed a new Porsche for my commute to work”), or censure ourselves for poor judgment (“I can’t be trusted with money.”) It’s important not to let one bad decision convince us (wrongly) that we’re bad decision-makers.
While it’s also important to avoid “analysis paralysis” in decision-making, it’s almost comforting to know that a certain amount of post-mortem rationalization will be in store when decisions don’t pan out; cut yourself a break when it happens.
6. We get fooled by the anchoring effect. As explained by Dan Ariely, we tend to make decisions by comparing the value of two or more options rather than making a decision based on pure value for investment. We do this all the time in the workplace. Whenever we choose the lowest bid simply because it is the lowest bid, the anchoring effect is at play. Lowest cost does not always equal the best value.
The takeaway: Calculate the value and cost of any option independently from its competitors. Then begin the process of choosing the winner.
And as Ms. Cooper notes, any marketer knows that the word “free” is a surefire hit. Even if what we’re getting for free is not so hot, we consumers can’t resist when the headline includes that magical word. If you are the marketer in your company, use this power wisely.
7. Memory and gut instinct can be wrong. It’s more than a little disheartening to realize that we don’t always remember things reliably. If you need to make decisions in the workplace, look at the facts and data to confirm what you think that you know. While gut instinct can be spot on, you’ll rest easier knowing that you can back up your decision with facts.
8. The conjunction fallacy leads to illogical thinking. This one has to do with the way preconceived notions and a love of detail affect our thinking. The conjunction fallacy was documented years ago by Israeli psychologists Daniel Kahneman and Amos Tversky. As stated in Michael Lewis’s fascinating Vanity Fair article about Daniel Kahneman, “The human mind is so wedded to stereotypes and so distracted by vivid descriptions that it will seize upon them, even when they defy logic, rather than upon truly relevant facts.”
Relying on stereotypes that assume that people are always logical and uniform in their thinking is bound to cause problems. Popular culture offers stereotypes ranging computer programmers (nerdy, pudgy guys who play World of Warcraft) to uptight librarians (ask any modern librarian if he or she goes around “shushing” the patrons, and you’ll get an earful.)
Well, that’s where my mind is today. Let me know where your mind is in the comments below.
Photo credit: unknown
The team project is every student’s worst nightmare. The grim acceptance of yet another doomed academic exercise seems to be an unavoidable part of higher education. Yet, as I tell my students, you will work on some kind of team project in virtually all modern workplaces. With a little bit of planning, you can–and will–survive.
First, let’s define a project. It is
The key to survival is focusing on that first bullet point. A project is temporary. Hang on to that hopeful thought.
It’s also comforting to know that conflict is a natural part of teamwork. Almost 50 years ago, Bruce Tuckman identified his famous team stages: forming, storming, norming, and performing. If you are “storming” within your team project, you can remember that your project is following the Tuckman progression just as it should. (Of course, the problem is that some teams never get past the storming stage. More on that in a bit.)
Meredith Belbin (1981) looked at team projects through a behavioral lens. He noticed that different individuals in a team displayed distinct “team roles” to varying degrees. A healthy team features a fairly balanced distribution of the roles:
- Coordinator (Chairperson): sets agenda, tracks, coordinates
- Resource Investigator: finds new info, new ideas
- Team Worker: looks for his/her part, gets work done
- Shaper: focuses on action tasks, completing project
- Implementor (Company worker): turns plans into actions
- Completer/Finisher: detail-oriented, schedule-aware
- Monitor/Evaluator: IDs flaws, focuses on outcomes
- Plant: creative, focuses on big picture
- Specialist: adds depth, masters a specific topic/area
Knowing that people exhibit their unique set of dominant team behaviors (Plants versus Completers?) helps us understand why we have conflict. Teams truly do have a personality, a mix of traits and behaviors.
The ultimate secret to project success is communication. This involves planning the project (brainstorming, asking questions), establishing a common vision (sharing ideas, setting goals, understanding scope) and time management.
Time management is probably the aspect that causes the most pain. Attending (or efficiently running) the team meetings, meeting deadlines, and completing tasks in a timely manner all contribute to the success of a team project.
Team project tips and coping skills
If you’re about to embark on a team project, here are a few helpful suggestions based on personal experience and Study Skills: Team Work Skills for Group Projects, an article written by students for students.
1. Begin by describing your project. As a group, write a few sentences to establish the exact deliverable (report, poster, PowerPoint, etc.) and what it should cover. Get everyone on the same page, so to speak. It also helps to define what types of work you will need to do to complete the deliverable: research, writing, surveying, gathering stats…
2. Create a project plan. At minimum, a project plan should define the responsibilities of the team members, establish a schedule, and map out conflict resolution.
- Share email addresses, phone numbers, and any other contact information that could be useful.
- Decide how quickly team members should respond to project communications: within one day is reasonable.
- Sit down with calendars and mark off the days that will and won’t work for team meetings. Mark the deadlines of any deliverables, including intermediate steps (drafts, progress reports). Anticipate holidays, birthdays, and the inevitable demands of other classes’ projects. (And be sure to build in time for editing and proofreading!)
- Hope for the best but plan for the worst. If one team member drops the class/gets sick/stops caring about grades, what will you do? Figure this out on Day One. Avoid some of the “storming” and put your team on the path to “norming”.
3. Divide & conquer–or not? Most team projects take a piecemeal approach: you do the introduction, I’ll do the bibliography, he’ll do the graphics. There’s nothing wrong with the divide and conquer approach–it can be a very efficient way to work. Well, that is unless it’s the last hour before the project is due and you are the person who ends up assembling and editing all those inconsistent, unrelated, or missing pieces.
To reduce frustration, be sure to also build in time for the group to simultaneously work on the project. In this approach, all of you assess your progress, assemble the pieces each person has completed, and identify what still needs to be done. This is an iterative process, depending on how much time you have to devote to the project.
4. Take advantage of collaboration technologies. If you have never used Google Drive for collaboration, get yourself to Google now and start learning! Google Drive is free cloud storage for all kinds of formats: Docs, Spreadsheets, Presentations, Forms, and more. It can be a bare bones substitute for Microsoft Office, and best of all it allows you to share, track versions, and see who added that hideous purple text on page 4. Google also offers video and text chat (IM), so you can work together even when you’re apart.
Other technologies include Dropbox (free shareable cloud storage for files), Doodle (a simple calendaring app that lets you schedule meetings at convenient times) and a whole bunch of others. You can even build a free website on Weebly or Wix or (hey!) WordPress.
If you need a high-powered (costly) solution, look for 30 day trials or academic versions. And don’t forget to check out your school’s site-licensed software. You might be pleasantly surprised at what is available.
Stay positive and stay flexible–you will get through this. Look at it as a chance to build your management skills and snag a good story for a job interview (“tell me about a time you had to solve a problem.”) And if all else fails, seek motivation.
Even though I’ve done a fair amount of writing and editing for workplace projects, I have never had to write a proposal. However, RFPs (Requests for Proposal) are a different story. Coming up with a set of software specs, helping to evaluate vendor proposals–that kind of stuff is more in line with what I do.
Jonathan Wold’s article in Smashing Magazine provided me with the view from the other side of the desk: the experience of the vendor, writing up a proposal to respond to the trusty RFP. In fact, Mr. Wold would rather not write proposals at all–they simply haven’t been paying off for his company. Instead, he writes a project evaluation, which seems to cover much of the same ground. But here’s the kicker: unlike a proposal, Mr. Wold’s project evaluations come with a price tag.
While I can’t imagine coming up with the scratch to PAY a vendor to respond to one of our RFPs, Mr. Wold’s description of the writing product is intriguing. To me, it’s a great example of breaking conventional norms in order to serve a communication need more effectively. And maybe it marks a new trend in workplace writing. Judge for yourself:
I’ve noticed an alarming trend in business: the re-purposing of PowerPoint into a pseudo-Word document. I bet you’ve seen this too. Big corporations develop a slick-looking slide design template. Add in the customer’s logo and some boilerplate text, and <!–begin rant–> then just go NUTS! Use the PowerPoint medium for EVERYTHING, even things that would be better served in Excel or Word. The more you can cram onto the slide, the better!! <!–end rant–>
Don’t get me wrong–PowerPoint is not the problem. I like PowerPoint, and I use it a lot. PowerPoint works GREAT as a visual asset to an oral presentation. It even works great for design projects (see Pecha Kucha.) But it does not work as a way to display a complex, tabled/charted teeny tiny report to a room full of people. That’s not sharing: that’s just making things difficult.
My top five rules for PowerPoint:
- No more than three bullets per slide
- No more than seven words per bullet
- Lots of visuals (but only if they add something to your persuasive point)
- No more than 20 slides (20 X 20, the Pecha Kucha standard, is kind of nice & symmetrical.)
- No reading your slides*
(*One exception: if words on your slides are important to your presentation, people with visual impairments need the context. But you don’t want a slideshow full of words anyway, right?!)
Last weekend we helped some young relatives move into their first home, an experience that reminded me of the importance of friends (and muscles.) As the Advil started circulating through my bloodstream, it struck me that the common experience of packing up one’s belongings and moving to a new home is a lot like drafting a written document.
1. Planning. The art of packing a U-Haul is nothing to sneeze at. To make the most of your space (and to minimize re-arranging things), you need to do some serious planning. In writing, the planning step is often skipped, partly because we feel that we can make progress if we just start writing (just fill up that truck!) However, I believe that in about 99% of writing projects, some good upfront planning will actually make the process go quicker. Just sketch out the big picture (the textual equivalent of chifforobes and dining room sets, if you will). The little things can come later.
2. Knowing the neighborhood. I grew up on the West side of Cincinnati, as did our new homeowners. But the new house was on the East side. As I was looking across the back yard, I saw my first ever Lazarus Lizard, a descendant of four wall lizards that were smuggled in from Italy in the 1950s. We don’t have Lazarus Lizards on the West side; it’s uniquely an East side phenomenon. Who knew?
Keep the Lazarus Lizard in mind when you write for a new audience. Even if you have written for similar audiences, it’s a good idea to try to uncover the unique things a new reader knows or cares about. Often a charming or interesting fact is just around the corner!
3. Getting help. My clever young relatives created a Facebook event and invited friends to help them move. We had upwards of 20 people at any given time, in all stages of fitness and age (and did I mention it was 90 degrees that day?) Because of this group of friends, the move went quite smoothly. Sharing our experiences and helping each other made the task more efficient, as well as more enjoyable.
In writing, there are always people who have the knowledge or expertise that you need. Let them help you; and if you are in a position to help someone else, pay it forward.