So Called Agile and Scrum Failures

is a team which continues to basically follow a Waterfall product but uses the language of Agile and adds a few agile practices. For example, the team may present burn-down charts together with Gantt charts. Or the team computes individual resource allocation for the next three months. You can also replace Waterfall with V-Model, HERMES, RUP, and even sometimes SAFe.

describes a team which claims to follow Scrum but misses various practices. For example, We do Scrum, but we don’t have a Product Owner. Or We do Scrum but the Project Manager allocates tasks. Such teams normally have a long list of “buts” and show little progress of removing them.

The most popular Agile method is Scrum, which is a product management technique. Scrum is normally used with a number of other Agile techniques, typically user stories redaction and the technical practices from eXtreme Programming – such as TDD, ATDD, code refactoring, continuous integration and delivery CI/CD, pair programming, etc. Teams that adopt the Scrum framework initially see an improvement in productivity and customer satisfaction. Without technical practices, quality is low, and the team hit the wall. The quality gap makes it impossible to maintain the pace in the long run.

occurs when a team declares itself Agile and blames everyone else for their failure to interact correctly with the group. Such a group typically stops writing documentation, listening to business analysts, product managers, and other customers, and dictates its own delivery schedule. Meanwhile, the team does not improve quality, does not adopt test-driven development or any other practice they dislike.

occurs when a team adopts and applies an Agile method well but does not deliver business value. This is a form of goal deferment where the team considers adhering to the process rather than delivering business value as the success criteria.

on a well-functioning Agile product, the customer, or proxy customer, is called upon to do a lot. They need to decide requirements, set priorities, scout ahead of the product, align strategy, work with the developers, testers, and managers, and may even have their own day job to do. In the earliest XP product (“C3”) the first business analyst came close to a nervous breakdown.

Management may bring in consultants and other experts to help switch a team to Agile. Once the consultants leave, some teams return to their old ways of working. Advisers and consultants can be a great help when introducing Agile. They need to build capacity in the development team to continue learning and evolving when the consultants are gone.

To maximize the benefits of Agile Software Development, the people, processes, and organizations that interface and work with the Agile team need to understand Agile. It should adjust their expectations and working techniques too. Agile is not a drop-in technology that can be swapped in to replace another failing method. Isolated Agile teams will find it difficult to be completely Agile. When other groups adopt agile approaches, the benefits of Agile can spread beyond Software Development.

happens when teams do not sufficiently understand the technology they are working with – either in the solution or problem domain. Small work packages suddenly turn out to be large tasks in their own right.

Most Agile methods, especially Scrum, hold the iteration goals fixed for a few weeks. An exception is Kanban. Most businesses should be able to hold to goals for such short periods of time. If it proves impossible to hold requirements and goals fixed for even one week, then something is wrong. In a few cases, business is genuinely changing extremely rapidly. In this case, teams are better off using Kanban style management than a Scrum-based approach. More often, hyper change in goals and requirements is a sign that something is wrong beyond the team. The organization itself may lack strategy and objectives, or the Product Owner may not be filling their role adequately.

Some Agile techniques, like TDD, ATDD, CI or CD, when poorly applied with a lack of understanding can show short-term benefits but create long-term problems.