Dear Agile Stakeholders: Could You Be Failing Your Teams?

The Agile Manifesto[1] is one of the most important documents for software teams because it encourages interaction with all Stakeholders in a project. These engagements provide essential value and direction for a project with timely feedback to determine that work is on track.

In this context, we identify stakeholders as those who frequently interact with the Product Owner, Scrum Master, or the Agile Team to provide information on products and services throughout the project’s development. In this light, typical stakeholders are Customers, Users and Sponsors. Customers acquire the project’s products and services; users engage with the project’s products and services; and sponsors provide resources and support for the project.

As Stakeholders in software product development, you know that the Agile methodology is currently popular and widely adopted to develop software at an acceptable cost, as compared to more traditional Waterfall approaches. However, many Agile software development teams still struggle to meet stakeholder expectations. Let’s take a look at where and how these shortfalls may occur.

Jumping on the Agile Bandwagon

To understand what an acceptable cost is, let’s backtrack to the time when everybody was obsessed with the Waterfall methodology[2]. This meant going through several daunting tasks like gathering requirements, preparing documentation, imagining the outcome, and then waiting endlessly for a tangible delivery – prior to knowing if the final outcome was what the customer wanted or not. The cost of waiting to understand what you do and don’t want isn’t acceptable.

In an effort to find a solution for these continued shortfalls in the software industry, a group of seventeen thought-leaders gathered in early 2001 in Snowbird, Utah. The meeting gave birth to the “Manifesto for Agile Software Development,” known commonly as the “Agile Manifesto.” The manifesto proclaimed a preference for:

  1. Individuals and Interactions over process and tools
  2. Working Software over comprehensive documentation
  3. Customer Collaboration over contract negotiation
  4. Responding to Change over following a plan

Anyone wanting to embrace the Agile Manifesto should be aware of what they are committing to prior to doing so. Moreover, all stakeholders should be made aware, since they will be directly impacted by the way the project is implemented and completed.

The effectiveness of the Agile Development Methodology for your project will depend on the four values or preferences addressed in the manifesto above. While Agile may seem like an exciting new way to work, it’s important that project teams take note of what it means to actually operate as per what the manifesto outlines prior to jumping on the bandwagon, or else its purpose won’t be as effective. This is best illustrated by a paper presented by the Project Management Institute (PMI) titled “Agile problems, challenges, & failures” (2013)[3] which states that the top three reasons for agile project failures are:

  1. Inadequate stakeholder experience with implementing as per agile methods
  2. Insufficient understanding of the required broader organisational change
  3. The Stakeholder’s company philosophy/culture is at odds with agile values

Not Fully Committing to Agile

An Agile project can only be effective if Agile principles are practised properly – and by everyone on the team. Unfortunately, many openly embrace Agile practices but don’t do the same with Agile principles. People love the idea of responding to change in Agile practice, but you can’t only single out change without taking the other three values into consideration. The effectiveness of the process happens only when all four values are embraced at every level within an organisation.

This is being addressed specifically due to the fact that project stakeholders tend to be disconnected from the process once they have invested a certain amount of time achieving a particular resolution or objective, and then delegating responsibility. However, the Agile Manifesto dictates differently. Embracing Agile is all about taking responsibility across the board as one team. Let’s consider how this can be made possible:

  1. Constant communication is key to keeping the entire team on the same page.
  2. Active participation of decision-making Stakeholders in the outcome of the project is essential.
  3. Each person must be responsible for holding true to their end of the bargain without failing to meet deadlines.

The reality is that not every Stakeholder can practically participate in all communications and contribute actively which becomes a significant issue. Similar to the Waterfall methodology, Stakeholders are happy to wait on the last outcome and face failure or success at that point. It’s important in this case to remember that fail-fast is the strategy to overcome heavy losses. The only way to gain insight into where your money is being spent and change the trajectory of the path you are driving is only through active participation and contribution.

Proactive Stakeholder Communication

In today’s globalised world, it is common to see remote teams working together, but distributed across the globe. Stakeholders are often at a different location to other team members such as the product owner, scrum master or developer. Some teams include a variety of other roles, including business analysts, UI/UX or creative designers, QA analysts, architects, database administrators, infrastructure administrators and subject matter experts, among others.

Having a team effectively working 24/7 across multiple time zones has its benefits; the project can flow in a continuous stream from sunrise to sunset – but only if stakeholders actively communicate, providing feedback in a timely manner. If not, the smooth flow of the project is disrupted. This occurs because stakeholders tend to waste project resources by not fully adopting an Agile mindset. They must understand the value of practicing the third Agile principle of ‘customer collaboration’ by communicating proactively and engaging regularly with their Agile development team to ensure that requirements are understood, and decisions are communicated.

In the case of a geographically distributed team, a stakeholder who delays clarifying a requirement by a few hours on a given day could translate into a 24-hour delay due to time zone differences. This means wasted productive hours for the development team while idly waiting on information from the stakeholder.

Effective Stakeholder Feedback: The Four Fundamentals

Here are four key Agile fundamentals that you, the Stakeholder must establish in your Agile projects to help smoothen out these complications: 

1. Appoint a Product Owner

To ensure the active participation of decision-making Stakeholders, consider appointing a Product Owner to act as the Stakeholder representative who in turn will communicate the vision of the product to the entire team. The Product Owner should respond to active decision-making, reduce losses, and increase return on investment (ROI).

2. Appoint a Scrum Master

A Scrum Master’s job is to facilitate and coach the team to improve productivity and efficiency, and to remove obstacles. Although Scrum is a framework for Agile development, a Scrum Master is placed in an Agile team to uphold Agile/Scrum values. 

3. Developers: The Core of the Agile Team

Developers define the capacity and estimate for each Sprint. They are responsible for development tasks, unit testing, system integration, developer testing and code review which a Sprint usually comprises. This means that Stakeholders must empower the development team, set the vision, and balance the ground. To do so, they must create an environment that is open to communication; team members should be able to bring new ideas to the table, take charge of challenges, and even fail at times so that they are able to learn. In a ground-breaking 2006 TED Talk, education expert, the late Sir Ken Robinson talked about the value of making mistakes, saying “If you’re not prepared to be wrong, you’ll never come up with anything original[4]. While intended for an educational context to empower students to discover the right path by overcoming a fear of making mistakes, the concept works well with Agile principles and can enable hitherto unconsidered solutions for your project.   

Encouraging your developers to think out of the box is essential. You can achieve amazing results when you build a team whose opinions are valued, which in turns creates 100% commitment, creativity, and reliability. You might even be able to discover untapped ROI areas in your systems this way. 

4. Follow Agile Ceremonies

There are four ceremonies in Agile Development: Sprint Planning, Stand-Ups, Sprint Review, and Sprint Retrospective. These events allow you to have an iterative approach, look back at what was done in previous Sprints, and improve decision-making for the next Sprint. This enables continuous growth, improves team capabilities, skills, trust, and decision-making. It also helps build an autonomous team who will actively contribute to achieving the best product at a lower cost to what you would have achieved with the Waterfall approach.

This is it in a nutshell: an Agile team with highly involved Stakeholders can produce a better product at a lower cost. The advantages of adapting to changes and meeting expectations, the efficiency of the team and the entire development process are incomparable.

– Be Agile to Follow Agile –


[1] Beck, K., et al. (2001) The Agile Manifesto. Agile Alliance. http://agilemanifesto.org/

[2] Royce, W (1970/2006) The Waterfall Development Methodology http://www.waterfallmanifesto.org

[3] Miller, G. J. (2013). Agile Problems, Challenges, & Failures. Paper presented at PMI® Global Congress 2013—North America, New Orleans, LA. Newtown Square, PA: Project Management Institute.

[4] Robinson, K (2006). Do Schools Kill Creativity? [ video file ]. Retrieved from https://www.ted.com/talks/sir_ken_robinson_do_schools_kill_creativity