Software development is a complex process, and few organizations manage to handle it properly from the outset. It’s no surprise to anyone in the IT industry that software project failure rates still hover near the 40 percent mark even after more than 60 years of industry experience in the field.
To outsiders, though, not only is that failure rate remarkable, but so is the fact that it has come down to that still-atrocious level from a high closer to 60 percent in the late 1990s. That decrease is no accident, and many industry experts attribute it primarily to one thing: agile software development practices.
The most popular of these, hands-down, is called “Scrum.” Forrester Research has determined that more than 90 percent of organizations that identity as “agile” practitioners use Scrum as their methodology of choice. And Scrum’s appeal extends beyond software development, these days, finding a home in lean organizations in roles as diverse as developing new radio programs (at National Public Radio) or building a new hyper fuel-efficient car (at Wikispeed).
The principles behind Scrum will not be foreign to any student of business familiar with conventional lean manufacturing or development practices. By using loosely coupled iterations of rapid development, Scrum seeks to manage risk by reducing wasted effort and maximize value by delivering working software rapidly. Whenever the details of the process start to look obtuse or confusing, return to those basic precepts: they are the heart of the practice.
You can use Scrum to manage almost any sort of project.
The heart of Scrum is the sprint. A sprint is simply a predefined segment of time, during which a subset of product features (called backlog items) will be built by the development team. The most common length for a sprint is about two weeks, although it can be as short as a day or as long as a month. You’ll have to determine the appropriate window for your team and project.
The sprint is part of a loop, a continuing set of iterations of feature definition, development, and acceptance which continue until the product is complete. The goal of each sprint, however, is to have a working piece of software at the end-even if not all desirable features are in place, those that are in place should function correctly and provide value to the user.
The trick to achieving this feat lies in the definition of the backlog items. The product backlog is the master list, created, maintained, and organized in order of priority by the product owner. The owner is the customer or customer surrogate, and is the only person allowed to add or remove items from the product backlog. Each item, however, must be discrete enough to be built entirely within the sprint timeline and valuable enough to make it worth finishing.
Need Inspiration? Check Out Some Related Projects and Tasks
VueStorefront Fullstack Developer
Vue Storefront is our Open Source product for building the PWA and Headless eCommerce frontends. We're looking for somebody who'll join our Expert Consulting team ("Vue Store Force") which is ... (Poland)
Hi, we're looking for a front-end developer. We develop a platform for collecting, analyzing and acting on feedback from customers, employees and students. We are already helping over 600 customers ... (Sweden)
Technical Program Manager, Product
Technical Program Manager - Product Location: Chennai, India Reports to: CPO * Possibility of converting into a full time role. Do you have a passion for getting things done right, and on time? Do ... (United States)
Join A Team Building A Human Resource PHP Website For A
We are building a website with 200 pages, and our team is too small to complete the work for a set deadline. The tech is AWS, PHP, MySQL, Linux. Standard stuff. We do an Agile scrum every day to ... (United Kingdom)
These results are based on the freelance jobs extracted from Upwork.