Project Management Stack Exchange is a question and answer site for project managers. It only takes a minute to sign up.
Sign up to join this community
What is expected of the stakeholders when it comes to being agile? Since collaboration is at the heart of agile, shouldn't the adoption of agile values be present on both sides?
As per my observations, stakeholders who do not have adequate knowledge of Scrum or agile tend to give the teams a hard time, especially the PO(Product Owner). Shouldn't there be more emphasis on the stakeholder's role in Scrum?
shouldn't the adoption of agile values be present on both sides?
Yes, it should. But often isn't.
The problem is that Agile/Scrum is more of a mindset than a way of working. But people all throughout the organization see it as a methodology for developing software. If you are an executive, a business person, or working in some other department within the company and you need IT to build you software, the historical de facto way of getting it is to ask for it. Stakeholders usually have expectations from the development team, they don't really collaborate with them. It's a different mindset. An old mindset.
You said it in the title of your question that stakeholders are expected to adopt an Agile mindset. That means letting go of their old mindset and embracing a new one. This is the corner stone for having a successful Agile implementation across the company. A new mindset. But this comes with a lot of things attached to it, like changing organizational structures, reorganizing communication channels, changing organizational culture, changing roles and responsibilities, being more involved instead of just asking for things, and much more.
These are not easy things to change, they involve a lot of time and effort, and many times no changes get done. People expect Agile to give them agility, to make them nimble to respond quickly and effectively to change. To give an analogy, they expect to move quickly through water like a speed boat. The problem is that most companies are huge oil tankers that take a lot of space and a lot of time to make even the smallest turns.
Yes. Stakeholders need to be active collaborators in a successful Scrum or agile process.
While not spelled out prescriptively in the Scrum Guide, in successful Scrum implementations each role on the Scrum Team is responsible for collaborating with stakeholders in a role-specific way.
Product Owner
The Product Owner is largely responsible for aligning stakeholders outside the Scrum Team with:
Scrum Master
The Scrum Master is responsible for educating stakeholders on how Scrum works, and the various inflection points and mechanisms available to stakeholders to guide, redirect, change, or abort the project. There's some overlap with the Product Owner on this, but the Scrum Master should be the primary process evangelist and (when necessary) the process referee. The Scrum Master should:
Development Team
The Development Team need not work in isolation from stakeholders or customers. Scrum insulates developers from excessive task-switching within a given time box, but like all agile frameworks it values collaboration over specifications and plans. The Development Team should:
Treating Product Backlog Items and the Definition of Done as working agreements that include the needs and voices of stakeholders is essential to effective agile implementations. A working agreement is a living thing; it can be updated, modified, or improved to fit changing workflows. An "agreement" also invites collaboration, introspection, and discussions in a way that "immutable rules" don't. Working agreements also encourage stakeholders and the Scrum Team to view one another as partners in the product development process, rather than as adversaries.
The following image illustrates the difference between incremental and iterative approaches, as well as what it looks like when the two approaches are combined.
Scrum is an empirical control system that uses a mix of incremental and iterative development, both of which are very different from the more traditional immutable-specification approach. Explaining that to stakeholders is the job of the whole Scrum Team, so make sure everyone on the team and in the executive ranks of the organization are all drinking the same Kool-Aid if you want your Scrum implementation to move beyond a thin veneer over traditional plan-first control systems.
Stakeholders certainly ought to understand and adopt an agile approach. To use Scrum effectively stakeholders need to appreciate the significance of product ownership, continuous delivery and prioritisation since they are things that decide the outcomes and define the way the business collaborates with the development team.
Agile adoption is often driven by technologists but arguably it should be business driven. Where a technology team is trying to drive agile adoption in an organisation they need to consider that business stakeholders' perceptions might have been conditioned by their past experiences with technology teams (e.g. delivery contracts and phased work breakdown structures created by IT management).
One of the challenges that Agile faces is that it's rare the whole organisation is Agile, particularly if you're operating outside of the tech/startup universe (and, to be fair, within in too). So in almost every agile team, you're going to butt up against non-agile ways of thinking and working. Those different ways of thinking are going to be a source of friction - in the form of mismatched expectations, engagement patterns, and outcomes.
This isn't a new problem - bringing together different parts of a single business operating different ways has been a problem in organisations as long as there have been organisations. It's not new, and it's not going away any time soon. Even different agile teams in an organisation are likely to operate in different ways, think in different ways, and focus on solving different problems.
Broadly speaking, there are a few solutions that can be used.
1. Integration roles - specific individuals or teams that serve as the interface between different parts of the business. This often falls into the Product or Project management spaces. Their job is to speak Agile to Agile teams and speak other languages (Command and Control, Governance, etc) to other teams. The integration team become key stakeholders.
2. Ignore it. The Agile teams get on with being Agile; and practically minimise their interaction with non-Agile teams. This can work when you have a relatively isolated team in a larger business (e.g. a skunkworks type team). The number and influence of non-agile stakeholders are minimised. This often relies on a strong sponsor to protect the Agile teams.
3. Fake it. People within the Agile team act as the interface, preparing the project reports and Gantt charts, and timelines. That work is necessary waste - serving to ensure the team continues to receive budget and resources. This can create a barrier between the stakeholders and the team.
4. Compromise. Soften or change the team's agile approach to fit with other ways of thinking and working. This tends to compromise the agile approach and reduce its effectiveness to some degree. But it does tend to increase the influence of the stakeholders.
5. Try and change the rest of the business. If successful, this makes the whole business more Agile. But it's really hard to do - and requires substantial support from key people within the business (if it's organisation-wide change, then the CEO has to be on-board). The risk is trying to do this unsuccessfully can compromise trust in Agile working even for the teams that are successfully working that way.
There are probably other solutions - but these are a few to cover to start with!
