It is hard to fit an Agile-shaped peg into a business-shaped hole!
The most important factor for a project’s success is gaining the stakeholders’ buy-in the process, so this is what I am going to discuss in this article.
The main predicament here is that by adopting SCRUM you rely on external parties (i.e. not solely the development team) and if they do not fulfil their role and responsibilities, the whole project may crumble.
So let’s see what can go awry…
“I don’t have enough time to work with the team in every iteration”
The participation of the Product Owner is what makes or breaks an Agile team. The collaborative nature of the Agile methodology, where the Product Owner is part of the team, can add a lot of pressure to them in terms of time management. Traditionally, their input is solicited at the beginning of the project (to sign off the spec) and at the end (to sign off that the software meets the spec), but in an Agile project they are requested to attend all the ceremonies, keep the backlog groomed, prioritise it and also interact with the Scrum team on a daily basis.
You need to illustrate to them that they are empowered to make decisions related to the product and use their domain knowledge to focus on functionality — not on the management itself. Most importantly they need to make themselves available by answering important questions quickly, providing valuable information on time and making sure the development team is not blocked. You ought to partner with the Product Owner and support them with anything they need and possibly coach them on how they can best add value to the team.
Courtesy: boost.co.nz
“I don’t need to check-in every Sprint Review; just send me a report!”
Stakeholders are busy people. Their day-to-day job is demanding and they are required to attend a lot of meetings, make decisions, manage multiple projects. They occasionally do not have a lot of interest in the software that gets built, as long as it does what it says on the tin. In a similar fashion with the Product Owners, they are used to get involved at the beginning and the end of a project and unsurprisingly they try to protect their time and eliminate any meetings they do not seem essential.
What stakeholders do not necessarily appreciate is that Sprint Reviews are for the benefit of the team; it is not for them to find what the team is up to, but for the team to find what the stakeholders actually want. You need to get them to understand that in the lack of detailed specs, this is the opportunity to inspect the product and adapt it accordingly. This is when they can request any changes and additions, so if they do not turn up they do not get a say!
Oftentimes the reviews fall into a few pitfalls:
• they are too long: in a two-hour review there is 20 minutes of value so their time is wasted,
• they are too technical: low level implementation details are being discussed,
• there is nothing to see: the stakeholders only want to review the full workflow and not the incremental pieces as they are developed each sprint.
Adjusting the structure of a Sprint Review to be focusing on the product is key to engage the stakeholder participation. It makes it easier for everyone to align their goals and visions for the project and continue to deliver a cohesive product.
“But I already know what I want!”
As is so often the case, people think that they already know what they want and they have a clear mental image of what the software should do, so they believe it is more efficient if they can write it down and let you get on with it. You cannot really say to the stakeholders or the Product Owner: “I do not trust that you know what you want before I show it to you” — You need to be more diplomatic about it and highlight that continuous input over the course of the project is invaluable. Edge cases are not obvious at the start of the project and need to be handled as they occur. Also what the stakeholders want and what they need may be different and likely carries a substantially different cost as well!
A metaphor I like to use is that ‘software development is an embodiment of the butterfly effect’: Minor changes can result in big downstream impact, so unless the stakeholders become available to discuss and validate their needs, the developers will inevitably make assumptions that become increasingly harder to unravel the later in the process you get.
This oldie but goodie tire-swing cartoon summarises it well:
Courtesy: businessballs.com
“I can’t wait for an entire iteration for a new feature”
The second principle of the Agile Manifesto suggests that changes are welcomed even late in development. How stakeholders translate this is that changes are to be accommodated NOW!
The idea of a fixed iteration is deliberate in its attempt to control this constant fluctuation of the requirements and protect the team from starting many things but not completing them. An agreement with the Product Owner and other stakeholders needs to be made on the optimum iteration length: i.e. what is the acceptable length they are willing to wait for new requirements to begin vs. long enough cycle for the development team to complete the features and meet their expected velocity.
“This is a regulatory project — will you meet the deadlines?”
YES!! Contrary to popular belief, an Agile approach can indeed work great in a date driven project. Based on the “iron triangle”, with a fixed schedule, you have to flex one of the other two objectives i.e. either add more people to the project or cut the scope to make that happen.
Courtesy: Wikimedia
However, you need to remember that more resources are beneficial if they are constant for the whole course of the project — assigning more developers to a project running already late, will make it even later (this is well documented in the Mythical Man-Month by Fred Brooks). Regarding the scope, you do rely on the Product Owner — they have to prioritise which features are needed to achieve the Minimum Viable Product. “Learning from the movies” is an approach I recommend too: make commitments with regards to the final release date as late as possible.
An important thing to bear in mind is that in fixed-timescale projects the quality needs to be high so the risk of bugs and the associated delays is minimised. Automated testing and continuous integration come to the rescue and you should sell their added value to the management. Also tools like Atlassian Portfolio or ALM Works Structure visualise the building blocks of a plan (scope, people and time) to help you plan in real-time.
Short iterations and having working software as the primary measure of progress assures that when the deadline arrives, you are guaranteed to deliver a functioning product with the right features. Even if you are stuck with an unrealistic budget, schedule and scope expectations, you should still run the project in an Agile fashion as it provides clear evidence that you will fall short much earlier than you do in a traditionally managed project and you therefore have more options…
Planning is everything, the plan is nothing — D. Eisenhower
Ready — Get Set — Scrum!
In my experience the best way to get buy-in from any stakeholder is to get them to join you in the ceremonies and participate in the day-to-day Scrum execution. Organised presentations and training is also essential to create a feeling that the transition to Agile in the best approach.
On the other hand, the need to foster the Agile atmosphere and prove that it is not FrAgile, does not give you carte blanche to ignore the feedback of those stakeholders who do not necessarily see the value. Instead, to paraphrase Nigel Nicholson in the Harvard Business Review: when someone resists, an effective leader looks at them not as a problem to be solved, but as a person to be understood!
