http://tc.eserver.org/dir/Agile A listing of the most recently indexed works about Agile in the field of technical communication. en-us Copyright (c) 2005-08 by the EServer. All rights reserved. tclib-editorial@eserver.org (TC Library Editorial Board) webmaster@eserver.org (Geoffrey Sauer) http://tc.eserver.org/images/newlogo.gif http://tc.eserver.org/dir/Agile http://tc.eserver.org/35803.html http://tc.eserver.org/35803.html 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. http://tc.eserver.org/35811.html http://tc.eserver.org/35811.html Agility includes effective, that is, rapid and adaptive, response to change. This requires effective communication among all of the stakeholders. Stakeholders are those who are going to benefit from the project in some form or another. The key stakeholders of the project include the developers and the users. Leaders of the customer organization, as well as the leaders of the software development organizations, are also among the stakeholders. http://tc.eserver.org/35715.html http://tc.eserver.org/35715.html Agile projects aren't yet fully user-driven, but new research shows that developers are actually more bullish on key user experience issues than UX people themselves. http://tc.eserver.org/35658.html http://tc.eserver.org/35658.html 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. http://tc.eserver.org/35538.html http://tc.eserver.org/35538.html 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. http://tc.eserver.org/35421.html http://tc.eserver.org/35421.html It's a simple fact of life. Developing products in today's world requires shorter cycles, sensitivity to customer needs, and a focus on deliverables that breaks the old waterfall development paradigm. More and more there is a need for teams to focus on the entire development process and deliver precisely what customers need with little or no fluff. As products move towards the user-centric model of product development the push is for more intuitive interfaces with little need for documentation -- or does it really? http://tc.eserver.org/35354.html http://tc.eserver.org/35354.html 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. http://tc.eserver.org/35192.html http://tc.eserver.org/35192.html 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. http://tc.eserver.org/35040.html http://tc.eserver.org/35040.html uScrum (uncertainty Scrum) is an agile process developed by a small team at Altitude Software to manage the process of writing user documentation. uScrum manages uncertainty and the unknown, allowing writers to quickly react to changing conditions. uScrum uses orders of ignorance to understand the difficulty of tasks, allowing the team to effectively prioritize regular work together with difficult creative work. http://tc.eserver.org/34751.html http://tc.eserver.org/34751.html As Agile gains momentum as a development approach of choice, documenting design becomes a challenge. Peter Gremett shows how using a wiki to capture your design is a great way to be adaptive as you build and deliver product to customers. http://tc.eserver.org/34496.html http://tc.eserver.org/34496.html Test-driven development or TDD is a widely accepted practice used by agile software development teams of many flavors – not only Extreme Programming teams. For each small bit of functionality they code, programmers first write unit tests, then they write the code that makes those unit tests pass. TDD is seen as a design tool, since it forces the programmer to think about many aspects of each feature before coding. http://tc.eserver.org/33988.html http://tc.eserver.org/33988.html Three panellists talk about how they've applied agile development techniques to XML, followed by audience discussion and Q&A: Tony Coates will discuss XML and schema quality assurance using unit test frameworks. David Carver will discuss agile XML schema development. Claudia Lucia Jimenez-Guarin will discuss software construction for evolving systems with incomplete data definition. http://tc.eserver.org/33640.html http://tc.eserver.org/33640.html 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. http://tc.eserver.org/33588.html http://tc.eserver.org/33588.html 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. http://tc.eserver.org/33454.html http://tc.eserver.org/33454.html Agile methods aim to overcome usability barriers in traditional development, but pose new threats to user experience quality. By modifying Agile approaches, however, many companies have realized the benefits without the pain. http://tc.eserver.org/32997.html http://tc.eserver.org/32997.html eXtreme Programming and other agile processes provide a middle ground between chaos and over-elaborate processes sometimes referred to as 'death by documentation'. A particular attrtactive aspect of the agile approach for many teams is its willingness to accomodate change no matter how advanced development might be. However, this very flexibility can cause user interface design issues and ensuing usability problems. Adopting a user-centered approach to user interface design can address these issues, as the following simulated conversation between a user-centered design consultant and an XP team leader will explain. http://tc.eserver.org/32352.html http://tc.eserver.org/32352.html Some agile environments move so fast, you have to triage what you document because there’s no time to document everything. http://tc.eserver.org/32156.html http://tc.eserver.org/32156.html 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. http://tc.eserver.org/31163.html http://tc.eserver.org/31163.html Documentation teams need a fast and effective review process to move forward on their projects and deliver quality, timely content. Reviewers, may they be SMEs (Subject Matter Experts) or key organization authorities, are usually extremely busy and have limited time (or interest) to review documentation. Interesting dilemma, no? http://tc.eserver.org/31040.html http://tc.eserver.org/31040.html Agile methodologies have had a lot of press in recent years. To listen to some people, agile methodologies are the answer to all the ailments that have ever plagued software development from the beginning of the computer age. But what are they, really? And do they really deliver on that promise? The answer is: (drumroll, please) it depends. http://tc.eserver.org/30762.html http://tc.eserver.org/30762.html Storytelling can make documentation more exciting for both writers and readers. Stories provide context and people tend to remember them. More all-∆around fun when stories are tests. http://tc.eserver.org/30707.html http://tc.eserver.org/30707.html 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. http://tc.eserver.org/30729.html http://tc.eserver.org/30729.html Documentation is an important part of agile software development projects, but unlike traditionalists who often see documentation as a risk reduction strategy, agilists typically see documentation as a strategy which increases overall project risk and therefore strive to be as efficient as possible when it comes to documentation. Agilists write documentation when that's the best way to achieve the relevant goals, but there often proves to be better ways to achieve those goals than writing static documentation. This article summarizes common "best practices" which agilists have adopted with respect to documentation. http://tc.eserver.org/29463.html http://tc.eserver.org/29463.html Read about some of the challenges facing technical writers who create product documentation in a Scrum environment, as well as strategies for confronting these challenges. http://tc.eserver.org/28899.html http://tc.eserver.org/28899.html 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. http://tc.eserver.org/28728.html http://tc.eserver.org/28728.html What would happen when usability community meets agile community? How to adopt usability practice by agilists? http://tc.eserver.org/28669.html http://tc.eserver.org/28669.html 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. http://tc.eserver.org/28605.html http://tc.eserver.org/28605.html In this tutorial, attendees will learn to factor their company's business needs into their existing Agile procedures, and management will learn how to begin the investigative work of determining how to streamline these requirements and activities so that they don't hamper the project. http://tc.eserver.org/28599.html http://tc.eserver.org/28599.html 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. http://tc.eserver.org/28612.html http://tc.eserver.org/28612.html Provides a brief overview of the Scrum method as well as 'playbook' of guidelines and tactics for enterprise-wide adoption of Scrum. http://tc.eserver.org/28607.html http://tc.eserver.org/28607.html This presentation reviews the benefits, principles and history of DSDM (Dynamic Systems Development Method). http://tc.eserver.org/28597.html http://tc.eserver.org/28597.html 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. http://tc.eserver.org/28604.html http://tc.eserver.org/28604.html 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. http://tc.eserver.org/28606.html http://tc.eserver.org/28606.html 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. http://tc.eserver.org/28611.html http://tc.eserver.org/28611.html Rally's Hubert Smits provides a broad introduction to concepts of Agile software development and Agile methods. The talk is based on his experience as an Agile coach and Certified Scrum Master. Concepts that are known from waterfall or plan-driven development are transformed to an Agile perspective. Examples are release and iteration planning, progress reporting, meeting formats and scaling projects from 10 people teams to 300 people teams. http://tc.eserver.org/28602.html http://tc.eserver.org/28602.html This presentation provides a broad introduction to concepts of Agile software development and Agile methods. The talk is based on the speaker's experience as an Agile coach and Certified Scrum Master. Traditional concepts from waterfall or plan-driven development are transformed to an Agile perspective. Examples are release and iteration planning, progress reporting, meeting formats and scaling projects from 10 people teams to 300 people teams. http://tc.eserver.org/28598.html http://tc.eserver.org/28598.html When software development project teams move to Agile methodologies, they often leave project managers behind. Traditionally trained project managers are confused as to what their new roles and responsibilities should be in an environment that no longer needs them to make stand-alone decisions. This paper focuses on re-defining the job of project manager to better fit the self-managed team environment, one of the core Agile principles. Special emphasis is placed on the shift to servant leadership, with its focus on facilitation and collaboration. Mapping of PMBOK knowledge areas to Agile practices is discussed at length. After reading this paper, project managers should have a better understanding of what changes they need to make professionally, and how to make these changes in order to survive the transition to an Agile software development approach. http://tc.eserver.org/28609.html http://tc.eserver.org/28609.html When software development project teams move to Agile methodologies, they often leave project managers behind. Traditionally trained project managers are confused as to what their new roles and responsibilities should be in an environment that no longer needs them to make stand-alone decisions. This presentation focuses on re-defining the job of project manager to better fit the self-managed team environment, one of the core Agile principles. Special emphasis is placed on the shift to servant leadership, with its focus on facilitation and collaboration. Mapping of PMBOK knowledge areas to Agile practices is discussed at length. After reading this paper, project managers should have a better understanding of what changes they need to make professionally, and how to make these changes in order to survive the transition to an Agile software development approach. http://tc.eserver.org/28608.html http://tc.eserver.org/28608.html As Agile development teams gain success, the team's bottleneck moves up the food chain to product owners. To support rapid and iterative progress, development teams are demanding that product owners switch from traditional approaches of super-sizing long release cycles to a continuous flow of independent, negotiable and small, bite-sized morsels. http://tc.eserver.org/28601.html http://tc.eserver.org/28601.html Agile and waterfall methods are utterly different—from the way projects start to the expected deliverables and release schedules. In a waterfall world, what's an IT enterprise to do? Can agile and waterfall methodologies successfully coexist? The answer is yes, for both the short-term and the long-term. In this presentation, Michele Sliger outlines how to: factor your company's business needs into existing agile processes, streamline requirements and activities and identify specific points where agile and waterfall teams must plan, coordinate, and review progress. Learn how you can make agile processes work in the real-world. http://tc.eserver.org/28600.html http://tc.eserver.org/28600.html This whitepaper provides an Agile development overview full of techniques, best practices and educational materials. http://tc.eserver.org/28603.html http://tc.eserver.org/28603.html Sometimes considered an afterthought in the product development lifecycle, technical writers often struggle to become part of a performing Agile team. http://tc.eserver.org/28121.html http://tc.eserver.org/28121.html A Test Map is a list of unit tests associated with a specific function/method under test. It helps you see how that specific function/method is being exercised via unit tests. http://tc.eserver.org/27801.html http://tc.eserver.org/27801.html The purpose of this article is to define a set of ideal practices for an agile software development project. http://tc.eserver.org/27609.html http://tc.eserver.org/27609.html When it comes to getting work done, replace written documentation with more efficient forms of communication. To guide future work, create documents at the end of the project, when everything is complete, well understood, and easy to document. http://tc.eserver.org/27608.html http://tc.eserver.org/27608.html In agile software development you want to travel as light as possible, and the easiest way to do that is to choose the best artifact to record information. I use the term 'artifact' to refer to any model, document, source code, plan, and so on created during a software development project. Furthermore, you want to record information as few times as possible, ideally only once. For example, if you describe a business rule in a use case, then describe it in detail in a business rule specification, then implement it in code, you have three versions of the same business rule to maintain. It would be far better to record the business rule once, ideally as human-readable but implementable code, and then reference it from any other artifact as appropriate. http://tc.eserver.org/27601.html http://tc.eserver.org/27601.html Why do we bother with models or documentation? They don't execute, and our customers pay us for working code, not pretty pictures. We bother with models to communicate. The idea is that a graphical object model can show how objects fit together more clearly than looking at the source, an interaction diagram can show a collaboration better than figuring out the call path from several class definitions. But so often the design documentation fails in this, and leaves me puzzled on my sofa. http://tc.eserver.org/27600.html http://tc.eserver.org/27600.html 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. http://tc.eserver.org/27603.html http://tc.eserver.org/27603.html Discusses the life cycle of Story Cards, what they should be, how to use them and what to watch out for. http://tc.eserver.org/27602.html http://tc.eserver.org/27602.html Agile modeling started out fairly complex and it grew a bit into its current form. http://tc.eserver.org/27604.html http://tc.eserver.org/27604.html The basic idea is that very little of the documentation which gets created during software development actually gets read by the actual target audience. This article explains the problem and presents advice for addressing it. http://tc.eserver.org/27589.html http://tc.eserver.org/27589.html In Agile Documentation, Rüping gets to the heart of the documentation dilemma, offering a two-word solution: minimum necessary. http://tc.eserver.org/27590.html http://tc.eserver.org/27590.html 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. http://tc.eserver.org/27591.html http://tc.eserver.org/27591.html Recently, Agile Software Processes have been discussed as flexible and light-weight alternatives to established Software Engineering approaches, in order to overcome the obstacles created by the cost of producing and maintaining documents on higher abstraction levels. Depending on requirements and needs on the documents itself, Agile Documentation becomes a key issue and brings up questions on how to create, maintain and distribute documents among the team members without creating unnecessary or unjustifiable cost. This paper describes a technique allowing to produce documentation automatically, by conducting analysis on the series of development steps taken during project planning and enactment. http://tc.eserver.org/27588.html http://tc.eserver.org/27588.html When I initially started work on Agile Modeling (AM) I wanted to focus solely on principles and practices for effective modeling but quickly discovered that this scope was not sufficient, that I also needed to consider the issue of how to be effective at the creation and maintenance of documentation too. Some agile models will 'evolve' into official system documentation, although the vast majority will not, and therefore it is relevant to discuss how to be agile doing so. http://tc.eserver.org/27570.html http://tc.eserver.org/27570.html This webinar discusses how Agile Project Management (APM) excels on projects in which new, risky technologies are incorporated; requirements are volatile and evolve; time-to-market is critical; and high quality must be maintained. http://tc.eserver.org/27561.html http://tc.eserver.org/27561.html 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! http://tc.eserver.org/27563.html http://tc.eserver.org/27563.html 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. http://tc.eserver.org/27569.html http://tc.eserver.org/27569.html 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: http://tc.eserver.org/27572.html http://tc.eserver.org/27572.html 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! http://tc.eserver.org/27586.html http://tc.eserver.org/27586.html 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. http://tc.eserver.org/27564.html http://tc.eserver.org/27564.html This whitepaper provides an Agile development overview full of techniques, best practices and educational materials. http://tc.eserver.org/27568.html http://tc.eserver.org/27568.html Provides a broad introduction to concepts of agile software development and agile methods. The talk is based on his experience as an agile coach and Certified Scrum Master. http://tc.eserver.org/27567.html http://tc.eserver.org/27567.html This tutorial brings Scrum to life by introducing Scrum principles, process, practices and roles in the form of an actual Sprint timebox. The prioritized, timeboxed topics are presented and delivered as arranged by the tutorial attendees. http://tc.eserver.org/27560.html http://tc.eserver.org/27560.html Talks about real-world rewards and roadblocks we encounter at all levels of a business, and look at the new management and development processes we’re helping pilot, validate and roll out. For you, we hope this gives an insider’s view of the fundamental shifts taking place in software organizations that are trying to respond faster to their ever-changing understanding of user needs, evolving technologies and business demands. http://tc.eserver.org/27562.html http://tc.eserver.org/27562.html This paper focuses on re-defining the job of project manager to better fit the self-managed team environment, one of the core agile principles. Special emphasis is placed on the shift to servant leadership, with its focus on facilitation and collaboration. Mapping of PMBOK knowledge areas to agile practices is discussed at length. After reading this paper, project managers should have a better understanding of what changes they need to make professionally, and how to make these changes in order to survive the transition to an agile software development approach. http://tc.eserver.org/27565.html http://tc.eserver.org/27565.html In this presentation Ryan Martens and Luke Hohmann describe and show product owners how to think in terms of small, evenly spaced meals. They will introduce Agile principles, processes, tools and organizational structures that enable product owners to support their Agile development team's need for continuous, just-in-time elaboration of requirements and acceptance tests. http://tc.eserver.org/27587.html http://tc.eserver.org/27587.html This is a description of a simple software-internals documentation format and process. It is derived from the Unified Software Development Process, simplified towards eXtreme Programming compatibility, and arranged for realisation in a plain text file. http://tc.eserver.org/27585.html http://tc.eserver.org/27585.html A broader awareness of how changes can impact other things, including schedule commitments and work outside of the immediate area of change, is beneficial in terms of assessing trade-offs and benefits. http://tc.eserver.org/27254.html http://tc.eserver.org/27254.html Though the term 'agile' isn't often ascribed to the ways of software configuration management, Steve Berczuk offers some ways in which applying the principles of agile SCM can help teams work more effectively. http://tc.eserver.org/27253.html http://tc.eserver.org/27253.html Michele Sliger understands the turmoil traditional project management practitioners go through as they make the transition from plan-driven approaches to the newer agile methodologies. This week, she offers more insight as she continues her four-part series on relating Project Management Institute (PMI) best practices--as identified in the Project Management Body of Knowledge (PMBOK)--to agile practices. In this column, Michele discusses scope management and time management. http://tc.eserver.org/19666.html http://tc.eserver.org/19666.html A revolution is under way in software development, revolving around agile methodologies that allow more room for design changes based on input from customers during development. One popular agile methodology is eXtreme Programming (XP).