A directory of resources inthe field of technical communication.

Agile

26-49 of 91 found. Page 2 of 4.

About this Site | Advanced Search | Localization | Site Maps
 

« PREVIOUS PAGE 1 2 3 4  NEXT PAGE »

Agile management promotes a project management process that encourages frequent inspection and adaptation, a leadership philosophy that encourages teamwork, self-organization and accountability, a set of best practices that allow for rapid delivery of high-quality products, and a business approach that aligns development with customer needs and company goals. It is related to extreme documentation and scrum methods.

 

26.
#35658

Can UX Be Agile?

Traditional, heavyweight development methodologies can be very effective at solving well‑defined problems, where the person solving the problem has a clear understanding of the initial and goal states, the available options, and the constraints on the problem. At the opposite end of the spectrum are ill‑defined, so-called wicked problems. When it’s necessary to balance numerous, often‑conflicting factors, traditional development methodologies are much less effective.

Hornsby, Peter. UXmatters (2009). Articles>User Experience>Agile

27.
#27561

Careen-Stable

As an agile coach, I get the opportunity to facilitate many teams’ first iteration planning meeting. Now these meetings do start out like typical meetings, with everyone sitting around a table and one person talking. But as the meeting progresses and discussions begin around the work, it can begin to look like chaos to an outsider. What I didn’t realize however, until recently, was that it can also look like chaos to some of the insiders as well!

Sliger, Michele. On Becoming Agile (2006). Careers>Management>Agile

28.
#37093

Case Study of Agile and UCD Working Together

This case study shows how the ComputerWeekly user experience team integrated with an agile development group. It’s important to note the methods we used do not guarantee getting the job done. People make or break any project. Finding and retaining good people is the most important ingredient for success.

Kelway, James. Boxes and Arrows (2010). Articles>User Centered Design>Agile>Case Studies

29.
#27563

CIO's Playbook for Adopting the Scrum Method of Achieving Software Agility   (members only)

The authors of this whitepaper have helped many hundreds of teams adopt Scrum. Here they share how CIOs can implement Scrum on an organization-wide basis - the challenges they will face as well as the rewards - and provides a playbook for adopting Scrum in enterprises where software, and lots of it, is the key to competitive success in the marketplace.

Leffingwell, Dean and Hubert Smits. Rally Software Development (2005). Careers>Management>Agile>Scrum

30.
#28599

A CIO's Playbook for Adopting the Scrum Method of Achieving Software Agility   (members only)

Scrum is a proven, Agile software management method that has been widely adopted by organizations seeking to reliably deliver higher quality software. Scrum is a simple process: it has a small set of interrelated practices and rules, is not overly prescriptive, can be learned quickly and produces productivity gains almost immediately.

Schwaber, Ken, Dean Leffingwell and Hubert Smits. Rally Software Development (2007). Articles>Project Management>Agile>Scrum

31.
#28612

A CIO's Playbook for Adopting the Scrum Method of Achieving Software Agility   (PDF)   (members only)

Provides a brief overview of the Scrum method as well as 'playbook' of guidelines and tactics for enterprise-wide adoption of Scrum.

Schwaber, Ken, Dean Leffingwell and Hubert Smits. Rally Software Development (2006). Articles>Project Management>Agile>Scrum

32.
#28669

Clash of the Titans: Agile and UCD

Agile software development has become fairly popular in the last few years, leaving many UX professionals wondering how user-centered design (UCD) can fit into an extremely fast-paced development process that uses little documentation. User-centered design can involve a variety of techniques that provide insights into users' wants, needs, and goals, including ethnography, contextual inquiry, contextual interviewing, usability testing, task analysis, and others. But all of these take time--time that an agile development process might not allow. There is hope, though. Agile and UCD methods are not completely at odds with each other--and in some cases, agile development can even enable a more user-centered approach. By taking the time to understand the differences and similarities between agile development and UCD, it's possible to devise a process that is both user-centered and agile.

Cecil, Richard F. UXmatters (2006). Articles>User Centered Design>Agile

33.
#38019

Content Strategy for Content Agility

We live in a multi-in, multi-out world. There are so many information pipelines running into, out and around the organisation these days that it’s overwhelming companies the world over. The famous information overload is in stark contrast to an endless pressure to deliver excellent content — quickly and cost effectively.

Urbina, Noz. I'd Rather Be Writing (2011). Articles>Content Management>Content Strategy>Agile

34.
#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

35.
#27569

The Daily Stand-Up

The first and most basic rhythm of the Agile feedback cycle is the daily standup. It's just what it sounds like - a daily meeting where everyone stands up for the duration of the meeting. When I give Agile workshops, one of the questions I'm often asked is how to do daily standups when the teams are geographically dispersed. While this can be a challenge to coordinate and maintain, you'll soon find that the benefits of the daily communication make it well worth the effort. Here are several options to consider with your team:

Sliger, Michele. Rally Software Development (2005). Careers>Project Management>Agile>Collaboration

36.
#32156

Documentation and Agile Software Development

What’s it like doing documentation as part of an Agile software development team? Why is it a better way of working? I mull this over these and other questions with Graham Campbell.

Christie, Alistair and Graham Campbell. ITauthor (2008). Articles>Documentation>Agile>Podcasts

37.
#27590

The Documentation Dilemma

With limited staff, a rapidly changing IT environment, and increasing complexity, my own inflexible documentation practices had to be updated to reflect more dynamic environments.

Dickerson, Chad. InfoWorld (2004). Articles>Documentation>Agile>Extreme Documentation

38.
#28607

DSDM: Go for the Nine   (members only)

This presentation reviews the benefits, principles and history of DSDM (Dynamic Systems Development Method).

Tabaka, Jean. Rally Software Development (2006). Presentations>Project Management>Agile

39.
#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

40.
#27572

eXtreme Documentation and Design

What quicker way can there be to find out if something is teachable than to write up task-oriented documentation? And as things are built or changed, the documentation is updated. I often update the documentation before the code!

Ferlazzo, Ellen Lawson. Sprezzatura Systems (2002). Articles>Documentation>Agile>Extreme Documentation

41.
#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

42.
#36161

Failing Fast: Getting Projects Out of the Lab

“Failing fast” means getting putting applications out in the wild as soon as possible to learn whether they will succeed. This gives you access to early user feedback to quickly weed out ideas and methods that don’t work. Failing fast is a good thing—or, at least, it's preferable to failing slowly and spending too much time, effort and money developing a product that should have been put to rest earlier. Money and time you save by cutting off unsuccessful projects quickly will mean you have more money and time for the successful ones. The concept of failing fast can help businesspeople and stakeholders reduce the riskiness of launching products by letting real users and the marketplace dictate their product choices.

Hillerson, Tony, Alan Lewis, Scott Green, Ryan Stewart and Randy Rieland. UX Magazine (2009). Articles>Web Design>Project Management>Agile

43.
#28597

Five Levels of Agile Planning: From Enterprise Product Vision to Team Stand-up   (members only)

Existing agile methods often focus on small, single-team projects and overlook the broader impact of large, multi-team and multi-year projects. This paper outlines a distinct planning framework that has been used successfully in large-scale agile software development projects and relies on five levels: product vision, product roadmap, release plan, sprint plan and daily commitment. Each of the five levels of planning addresses the fundamental planning principles: priorities, estimates and commitments. In this paper, the main agile principles are introduced, as well as the Lean principles upon which the agile methods are built. One of those Lean principles, Muri, or overburdening of people, is addressed through the extension of the agile planning process. The extension of the most used agile planning technique (iteration planning) is described in detail, both the motivation for the extension as well as the collaboration practices behind each planning level. In the final chapter, the impact of product complexities on the planning process is evaluated, and a solution to create a smooth flow in the planning/delivery cycle is presented.

Smits, Hubert. Rally Software Development (2007). Articles>Project Management>Agile

44.
#28604

Five Levels of Planning   (members only)

The purpose of this presentation is to learn how to plan Agile projects from product vision all the way to daily stand-up and to feel the effect when 100 people prioritize, estimate and commit the plans for a major delivery.

Tabaka, Jean and Hubert Smits. Rally Software Development (2006). Presentations>Project Management>Agile

45.
#35803

Five Skills for Managing Documentation Projects in an Agile Environment

Sometimes, the Agile software development methodology seems like it could be renamed the “Fly by the Seat of Your Pants” methodology. But really, it means that you need a somewhat different set of project management skills for your documentation. I could certainly improve in these skills, but here are a few I rely on in an Agile environment.

Minson, Benjamin. Gryphon Mountain (2009). Articles>Documentation>Technical Writing>Agile

46.
#28899

Four Factors of Agile User Experience

One of the most important aspects of the work of designers do on a project is their ability to explain their choices and the reasoning that led to given design solutions--both to their clients and to other member of a product team. Clear communication is vital to the smooth progress of a project, as even a single misunderstanding or communication glitch can lead to mistakes during implementation.

Mascaro, Luca. UXmatters (2007). Design>Web Design>Agile>User Experience

47.
#33640

Getting Real About Agile Design

Agile is here to stay. The economic difficulties of the past months have finally put waterfall out of its misery; now more than ever, long requirements phases and vaporous up-front documentation aren’t acceptable. Software must be visible and valuable from the start. For many designers, Agile is already a fact of life (and for those less accustomed, some recommended reading follows at the foot of this article). We are reaching the point where we must either acclimatize or risk being bypassed. The good news is that Agile does allow us to still do the things we hold dear—research, develop a vision, and test and improve our designs—we just need new techniques. Now is the time to get real, and prove design can adapt, if we want to stay relevant in these increasingly unreal times.

Bowles, Cennydd. List Apart, A (2008). Articles>Web Design>Agile>Project Management

48.
#28606

Homer's Odyssey   (members only)

In this offbeat presentation, Jean compares the impediments and obstacles encountered by an Agile mentor with those detailed in Homer's classical reference. Through the presentation and dialogue, you will discover who plays which classical roles in an organization's effort to adopt Agile practices: Cyclops, the Sirens, Poseidon, Circe, Cicones, the Lotus-Eaters, and even the good-and-faithful dog Argus.

Tabaka, Jean. Rally Software Development (2006). Articles>Project Management>Agile

49.
#32352

How Much Should You Document? Everything? Strategies for an Agile Environment

Some agile environments move so fast, you have to triage what you document because there’s no time to document everything.

Johnson, Tom H. I'd Rather Be Writing (2008). Articles>Documentation>Agile

50.
#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

 
« PREVIOUS PAGE  |  NEXT PAGE »

 

Follow us on: TwitterFacebookRSSPost about us on: TwitterFacebookDeliciousRSSStumbleUpon