There is no single characteristic of Agile that makes it work so well to manage projects. Instead, it is the holistic practice of Agile that makes development teams successful. When project teams choose to practice Agile, they are practicing a concept that is still evolving, making this one of the best ways to work in a culture of continuous improvement.
Jon Terry is Chief Evangelist, Lean-Agile Strategy for Planview, a market leading provider of portfolio management, agile management, collaboration, and ideation software. The Benefits of Agile Development. One rule of thumb when practicing visual management with iterative work is that all work should be broken down as much as possible, so the team can see the work, prioritize the most important items, and divide and conquer.
Team efficiency Agile teams are known to be highly efficient at getting work done. Look for an Agile solutions provides insights into delivery trends to remove bottlenecks and adapt workflow processes for improved productivity.
Adaptability of a software development team Project managers cannot see into the future, but they can impact how easily a team is able to adapt to changes when they occur. Scalability of Agile projects Time and cost are the main factors in determining whether a company will go forward with a project.
How long will the project take? What will it cost? Will it be worth the initial investment to get this project done? What else could be done with the same resources and team members that may hold more value? The scope of the product and its features are variable, rather than the cost. This is an important benefit that can create much more positive and enduring working relationships. Above all other points, the ability for agile development requirements to emerge and evolve , and the ability to embrace change with the appropriate trade-offs , the team build the right product.
In agile development, the emphasis is absolutely on building the right product. The active involvement, cooperation and collaboration make agile development teams a much more enjoyable place for most people. Instead of big specs, we discuss requirements in workshops. Instead of lengthy status reports, we collaborate around a task-board discussing progress.
In my experience this makes it a much more rewarding approach for everyone. In turn this helps to create highly motivated, high performance teams that are highly cooperative. But there are implications.
Become a Data-Driven Organisation. Agile software development helps keep technical debt to a minimum. Any defects, feature changes or other maintenance tasks are added to what is known as a product backlog. The team reviews the backlog during each sprint planning session to determine what to address next. Thus, each sprint is a new opportunity to fix defects along with new feature development. Teams not only adapt to change in Agile, they are encouraged to embrace the practice.
Agile acknowledges that customer needs change and that teams must be able to adapt. Working in time-boxed iterations means the team does not need to wait on a lengthy requirement change, review and approval process. Any change or maintenance item is added to the backlog and allotted to an upcoming sprint based on priority and business need. An Agile software development process requires a level of collaboration and involvement that one would not find in a traditional waterfall project.
In waterfall, each phase often only involves a specific set of individuals with expertise to accomplish the tasks for that phase. However, Agile is quite different. Before each sprint, the entire team reviews, validates, and agrees on which user stories to assign to the sprint.
The developers, analysts, testers, and product owner work together to accomplish the items assigned to the sprint. The team meets daily to keep everyone on the same page. The traditional approach to software development leaves product testing and release to the end of the project. Using Agile for mobile application testing, teams get feedback almost daily and can act on that feedback immediately. Developing a product in sprints allows teams to quickly determine if they are on track and allows them to adjust almost immediately.
Also, because sprints are customer-focused, the team can be sure they are producing value at every release. Waterfall methodology can negatively impact the quality of the product. In a waterfall methodology, project phases may be so full of features that developers must rush to complete them and little time is left for testing. As a result, they may not have the time needed for proper mobile application testing. On an Agile project, the team does not attempt to develop all features at once.
Instead, the team assigns a smaller subset of features to each sprint. Management should remove impediments to easier, more fruitful collaboration. Innovators who can see their results in real market conditions will learn faster, be happier, stay longer, and do more-valuable work. Teams should experiment on small parts of the product with a few customers for short periods, and if customers like them, keep them.
Team members should resolve arguments with experiments rather than endless debates or appeals to authority. Most detailed predictions and plans of conventional project management are a waste of time and money. And people should be happy to learn things that alter their direction, even late in the development process.
That will put them closer to the customer and make for better results. Time to market and cost are paramount, and specifications should evolve throughout the project, because customers can seldom predict what they will actually want.
Rapid prototyping, frequent market tests, and constant collaboration keep work focused on what they will ultimately value. Compared with traditional management approaches, agile offers a number of major benefits, all of which have been studied and documented.
It increases team productivity and employee satisfaction. It minimizes the waste inherent in redundant meetings, repetitive planning, excessive documentation, quality defects, and low-value product features. By engaging team members from multiple disciplines as collaborative peers, it broadens organizational experience and builds mutual trust and respect.
Finally, by dramatically reducing the time squandered on micromanaging functional projects, it allows senior managers to devote themselves more fully to higher-value work that only they can do: creating and adjusting the corporate vision; prioritizing strategic initiatives; simplifying and focusing work; assigning the right people to tasks; increasing cross-functional collaboration; and removing impediments to progress. Agile is not a panacea.
It is most effective and easiest to implement under conditions commonly found in software innovation: The problem to be solved is complex; solutions are initially unknown, and product requirements will most likely change; the work can be modularized; close collaboration with end users and rapid feedback from them is feasible; and creative teams will typically outperform command-and-control groups.
In our experience, these conditions exist for many product development functions, marketing projects, strategic-planning activities, supply-chain challenges, and resource allocation decisions. They are less common in routine operations such as plant maintenance, purchasing, sales calls, and accounting.
And because agile requires training, behaviorial change, and often new information technologies, executives must decide whether the anticipated payoffs will justify the effort and expense of a transition. Agile innovation also depends on having a cadre of eager participants.
Give them the environment and support they need, and trust them to get the job done. OpenView Venture Partners, a firm that has invested in about 30 companies, took this path.
He found that they fit some activities more easily than others. Agile worked well for strategic planning and marketing, for instance, where complex problems can often be broken into modules and cracked by creative multidisciplinary teams. Some of them immediately loved the idea of implementing it; others had different priorities and decided to hold off.
Intronis was one fan. Its marketing unit at the time relied on an annual plan that focused primarily on trade shows. Its sales department complained that marketing was too conservative and not delivering results.
So the company hired Richard Delahaye, a web developer turned marketer, to implement agile. Under his guidance the marketing team learned, for example, how to produce a topical webinar in a few days rather than several weeks. A swiftly prepared session on CryptoLocker malware attracted registrants—still a company record. Team members today continue to create calendars and budgets for the digital marketing unit, but with far less line-item detail and greater flexibility for serendipitous developments.
The sales team is much happier. Large companies typically launch change programs as massive efforts. But the most successful introductions of agile usually start small. They often begin in IT, where software developers are likely to be familiar with the principles. Then agile might spread to another function, with the original practitioners acting as coaches.
Each success seems to create a group of passionate evangelists who can hardly wait to tell others in the organization how well agile works. The adoption and expansion of agile at John Deere, the farm equipment company, provides an example.
Gradually, over several years, software development units in other parts of Deere began using them as well. Jason Brantley, the unit head, was concerned that traditional project management techniques were slowing innovation, and the two men decided to see whether agile could speed things up. Tome invited two other unit managers to agile training classes. But all the terminology and examples came from software, and to one of the managers, who had no software background, they sounded like gibberish.
Tome realized that others would react the same way, so he tracked down an agile coach who knew how to work with people without a software background. Hundreds of Deere employees joined the discussion group.
Team engagement and happiness in the unit quickly shot from the bottom third of companywide scores to the top third. Quality improved. Success like this attracts attention. Today, according to Tome, in almost every area at John Deere someone is either starting to use agile or thinking about how it could be used.
Japanese martial arts students, especially those studying aikido, often learn a process called shu-ha-ri. In the shu state they study proven disciplines. Eventually they advance to ri, where they have so thoroughly absorbed the laws and principles that they are free to improvise as they choose.
Mastering agile innovation is similar. Before beginning to modify or customize agile, a person or team will benefit from practicing the widely used methodologies that have delivered success in thousands of companies. Over time, experienced practitioners should be permitted to customize agile practices. For example, one principle holds that teams should keep their progress and impediments constantly visible. Many teams are still devoted to this practice and enjoy having nonmembers visit their team rooms to view and discuss progress.
But others are turning to software programs and computer screens to minimize input time and allow the information to be shared simultaneously in multiple locations. A key principle guides this type of improvisation: If a team wants to modify particular practices, it should experiment and track the results to make sure that the changes are improving rather than reducing customer satisfaction, work velocity, and team morale.
Spotify, the music-streaming company, exemplifies an experienced adapter. Founded in , the company was agile from birth, and its entire business model, from product development to marketing and general management, is geared to deliver better customer experiences through agile innovation.
0コメント