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.
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.
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!
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.
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.
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.
Provides a brief overview of the Scrum method as well as 'playbook' of guidelines and tactics for enterprise-wide adoption of Scrum.
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.
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.
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.
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:
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.
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!
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.
“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.
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.
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.
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.
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.
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.
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.
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...