So Called Agile and Scrum Failures

Agile will never guarantee project success. All projects, especially application development, entail risk. If a project was risk free it is unlikely to provide significant benefits or competitive advantages. There are however, a number of ways in which Agile Scrum projects repeatedly fail which are worth examining.
Agile approaches and Scrum framework can reduce risks in projects and increase the return on investment. Standish Group report is a proof for this statement. One picture shows it all - look at the failed column -

Below are common patterns and errors when doing agile instead of being agile

• Wagile: is a team which continues to follow a basically Waterfall project 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 compute individual resource allocation for the next three months. You can also replace Waterfall with V-Model, HERMES, RUP, and even sometimes SAFe.
• ScrumBut: 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.
• Hitting The Scrum Wall: The most popular Agile method is Scrum which is a project management technique. Scrum is normally used with a number of other Agile techniques, typically user stories redaction and the technical practices from eXtreme Programming – XP – 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.
  
  However without the 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.
• Fake Agile: 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 do not improve quality, does not adopt test driven development or any other practice they dislike.
• Potemkin Agile: occurs when an a team adopts and applies an Agile method well but does not deliver business value.
  
  This is a form of goal deferment were the team consider adhering to the process rather than delivering business value as the success criteria.
• Customer (Business Analyst, Product Manager, Product Owner) overload: on a well functioning Agile project the customer, or proxy customer, is called upon to do a lot. They need to decide requirements, set priorities, scout ahead of the project, align strategy, work with the developers, testers and managers, and may even have their own day job to do. In the earliest XP project (“C3”) the first business analyst came close to a nervous breakdown.
• Fall back: management may bring in consultants and other experts help switch a team to Agile. When the consultants leave some teams return to their old ways of working. Advisers and consultants can be a great help when introducing Agile but they need to build capacity in the development team to continue learning and evolving when the consultants are gone.
• Failure to go far enough: To maximise the benefits of Agile Software Development the people, processes and organization that interface and work with the Agile team need to understand Agile and 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 adapt the benefits of Agile can spread beyond Software Development.
• Exploding cards: happens when teams do not sufficiently understand the technology they are working with – either in the solution or problem domain. As a result small work packages turn out to be large tasks in their own right.
• Hyper changing requirements: With the exception of Kanban, most Agile methods, especially Scrum, hold the iteration goals fixed for a few weeks. 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 the business is genuinely changing extremely rapidly. When this is the case teams are better off using Kanban style management than a Scrum based approach. 
  More often hyper change in goals and requirements are 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.
• Fragile, not Agile: some of the 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.

Few of these failure modes are unique to Agile approaches, they are reoccurring failure modes for all IT software development projects. Neither are they a comprehensive list of the ways in which Agile or traditional application development projects fail.

We can state that (see the Scrum Guide)

• Team process improvement is a major focus for the Scrum Master or the Scrum Coach
• Coaching the Development Team in self-organization and cross-functionality,
• Teaching and leading the Development Team to create high value products,
• Removing impediments to the Development Team’s progress,
• Facilitating Scrum events as requested or needed,
• Coaching the Development Team in organizational environments in which Scrum is not yet fully adopted and understood.
• Company process improvement is a major task for the Scrum Master or the Scrum Coach
• Leading and coaching the organization in Agile and Scrum adoption
• Planning Scrum implementations within the organization;
• Helping employees and stakeholders understand and enact Scrum and empirical product development;
• Causing change that increases the productivity of the Scrum Team; and,
• Working with other Scrum Masters to increase the effectiveness of the application of Scrum in the organization.

The essence of succeeding with Agile, Lean and Scrum is

• It is a change process with well known and discussed aspects,
• You must have a strong and experienced Scrum Master and Scrum Coach to maximise success,
• Do not tinker with the Scrum process before you really master it,
• If you have to scale your process, please consider LeSS.