A directory of resources inthe field of technical communication.

Articles>Collaboration>Agile

17 found.

About this Site | Advanced Search | Localization | Site Maps
 

 

1.
#36022

Agile Across the Enterprise

One of the Agile Manifesto’s basic balance equations is valuing working software over comprehensive documentation. This line of the Agile manifesto can be confusing to some supporting roles in an Agile development enterprise. As technical support staff, trainers, and content creators, what are we doing to fit into this Agile methodology, and what’s working well? Let’s explore some old habits that need to die, and some new rituals to fill that space.

Gentle, Anne. Just Write Click (2009). Articles>Collaboration>Agile

2.
#36023

Agile Across the Enterprise: Prioritizing Value in Support and Training

I have been a technical writer on Agile development teams, and working in tightly collaborative environments has taught me a lot about adding value in the customer’s perception. I still remember being challenged by Michael Cote when we were at BMC Software. He asked, “Why does it take three days to get a PDF out for review? Why aren’t technical writers using wikis for documentation?” Those questions prompted quite a bit of research that finally resulted in my book, Conversation and Community: The Social Web for Documentation.

Gentle, Anne. Agile Executive, The (2009). Articles>Management>Collaboration>Agile

3.
#30707

Agile Principles Are Changing Everything

There's an irony about agile development. There is no hard evidence that it produces better software, faster. And formal adoption rates, admittedly hard to measure, don't reach the 20 percent mark. Yet the ideas that underpin agile development--defining requirements incrementally, writing software in short stints, seeking customer feedback, testing code as it's written, frequent builds--have caught on like wildfire. They are widely accepted as sound development practices, even among teams that have not formally adopted them.

deJong, Jennifer. Software Development Times (2008). Articles>Collaboration>Agile>Methods

4.
#33588

Agile Usability

RITE differs from a “traditional” usability test by emphasizing extremely rapid changes and verification of the effectiveness of these changes. Specifically, practitioners make changes to the UI (prototype or application) as soon as the problem is found and the solution spotted. Changes such renaming buttons, changing the text of menu items often happen before another participant arrives. More complicated, but obvious changes are made as rapidly as possible. This way the change can be tested as quickly as possible.

Levison, Mark. InfoQ (2008). Articles>Usability>Collaboration>Agile

5.
#27600

Applying Agile Methods in Rapidly Changing Environments   (PDF)

The authors (both coming from a heavyweight software development environment) describe their approach to transferring a heavyweight method into a more agile approach. One can argue whether the described result is intermediate or final, the the process described and the choices made are well worth studying.

Kutschera, Peter and Steffen Schafer. Jeckstein.com (2001). Articles>Collaboration>Agile

6.
#37904

The Awesomeness Factor: Cameron Gray on Agile and UX

One of the significant challenges with Agile is that the teams are effectively self managing. This can present an issue when you have a significant number of junior team members. At Mindflash.com we do not have layers of management within the development organization so everyone is responsible for ensuring that they are writing code up to the standards of the organization. For the more junior folks, this means they have to ramp up their skills very quickly and work closely with the more senior members of the team. We are definitely heavily weighted on the senior side of things but I think that is generally appropriate for any team as small as ours.

Boersma, Peter. Adaptive Path (2011). Articles>Interviews>Collaboration>Agile

7.
#35192

Corporate Collaborative Authoring

The idea of a Book Sprint is that you can get lots of documentation written in a focused amount of time with the right team and some amount of content already in place. Gathering people in the same room when possible is extremely helpful and motivating as well.

Gentle, Anne. Just Write Click (2009). Articles>Collaboration>Agile>Documentation

8.
#27602

Easing Into Agile Modeling

Agile modeling started out fairly complex and it grew a bit into its current form.

Ambler, Scott W. Agile Modeling (2006). Articles>Project Management>Agile>Collaboration

9.
#27586

Extreme Programming

Extreme Programming (or XP) is a popular software development process that encourages a return to the days of little or no documentation, Design After First Testing, and Constant Refactoring After Programming. Despite its popularity, not everyone thinks XP is a good idea.

Software Reality (2005). Articles>Collaboration>Agile>Extreme Documentation

10.
#38945

How Not to Be a Wallflower

For those of us in the field of technical writing who didn't come at this from a computer science background (raise your hand if you’re an English major), we’re often introduced to unfamiliar technologies and terminology at the start of a project. It’s understandable then that we'd want to keep quiet and stay on the sidelines until we better understand what the developers are discussing. I’d like to suggest that doing so will lengthen the ramp-up time, and...

Davidson, Ben. Carolina Communique (2014). Articles>Collaboration>Technical Writing>Agile

11.
#35354

The Impact of Agile on User-Centered Design   (peer-reviewed)   (members only)

Discusses the impact of an agile software development process on usability testing. Reports opinions about usability testing within a company before and after a change to agile. Presents strategies to incorporate usability testing into agile product development.

Dayton, David and Carol S. Barnum. Technical Communication Online (2009). Articles>User Centered Design>Collaboration>Agile

12.
#38433

Integrating UX into the Product Backlog: The User Experience Integration Matrix

Teams moving to agile often struggle to integrate agile with best practices in user-centered design (UCD) and user experience (UX) in general. Fortunately, using a UX Integration Matrix helps integrate UX and agile by including UX information and requirements right in the product backlog. While both agile and UX methods share some best practices—like iteration and defining requirements based on stories about users—agile and UX methods evolved for different purposes, supporting different values.

Innes, Jon. Boxes and Arrows (2012). Articles>User Experience>Collaboration>Agile

13.
#36782

My Vision of Agile

Extreme programming showed developers that there was power in self-determination, and in reaction to all that old defensive stuff, many programmers have finally said “Enough is enough”. They emerged from their bunkers to become proactive in *guiding* the development process rather than just doing what they were told (and then getting blamed for the failure that results). And agile is the mechanism they used.

Cooper, Alan. Cooper Journal (2009). Articles>Collaboration>Agile

14.
#36365

Release Scrums: An Important Resource for the Agile Technical Writer

Scrums are part of the particular flavor of Agile methodology project teams use in the portfolio I work in. The managers recently borrowed the scrum concept for release preparation because the projects in this portfolio are interrelated and often have to be released together. This means that a lot of coordination is needed so that there are no surprises for anyone. Because technical writers enjoy surprises as little as anyone else, I get invited to these scrums. This lets me know how much time I have to put release notes together and whether there are any last-minute changes I need to make to them or to any other documentation.

Minson, Benjamin. Gryphon Mountain (2010). Articles>Collaboration>Agile>Scrum

15.
#36599

Sharing Responsibilities in Agile Technical Writing

One challenge a technical writer faces in an agile environment is that the development team splits into a number of sub-teams, each working on a different feature or bundle of features. The sub-teams work in parallel. As a result, all the features simultaneously reach the stage where we can start documenting them, and that’s usually quite close to release date. This can cause major stress for the technical writer and can require overtime work to get everything done in time.

ffeathers (2010). Articles>Collaboration>Agile>Technical Writing

16.
#35538

There’s No Crying in Agile!

When I’ve read Agile practitioner reports that tell tales of times when technical writers have left meetings and fled to cry, I am not just surprised but a little dismayed.

Gentle, Anne. Just Write Click (2009). Articles>Collaboration>Agile

17.
#36615

Together or Apart: Collaboration Models for Technical Writing

Whether you’re integrated into an agile project team and away from other writers, or together with multiple writers on the same project, increasing collaboration is key.

Johnson, Tom H. I'd Rather Be Writing (2010). Articles>Collaboration>Technical Writing>Agile

Follow us on: TwitterFacebookRSSPost about us on: TwitterFacebookDeliciousRSSStumbleUpon