What Scrum is all about
If I had to describe Scrum in one sentence, it would be "Done in less than a month.", and if I had only three words, it would be "Getting things Done." Being a bit more voluminous on words, "The team gets a clear goal which they set out to achieve in one Sprint. Their success is measured by how well they meet this goal."The limits of team autonomy
A Scrum team does not have complete and utter freedom to do whatever they please: their freedom is limited to doing whatever is necessary to meet the Definition of Done on the agreed Goal, and their activity needs to focus first and foremost on that.Encountered impediments need to be made transparent fast and dealt with in the most effective manner.
The Scrum team does not have the freedom to squander funds, gold-plate features or mess with stakeholders.
Scrum and Trust
Trust is the development team's capital. It's what they must build upon.The organization and the Product Owner place trust in the team to deliver the agreed outcomes. By delivering a useful increment in the Review, this trust grows.
When agreed outcomes aren't delivered, the trust in the team diminishes rapidly, and with that trust, the team's right to autonomy decreases proportionally.
Scrum and investors
Let's be honest. Investors don't care about Scrum. They don't care about how your team works, what you do all day - or even how long you're at work. They care only about one thing: "Am I getting my money's worth?" With initial funding, the investor provides a level of trust in advance. You better use it wisely!Why investors like Scrum
Still, investors often prefer Scrum organizations over Waterfall organizations, because the very nature of Scrum provides frequent control points at a pace at least the same speed the investor would want to see progress. As long as a Scrum team is able to create growing Product Increments at a rate at least acceptable to the investor, there's a high chance that the investment is wisely spent.Likewise, when a Scrum team fails to deliver what the investor considers a good return on investment, the investor can quickly pull the plug.
The double-edged sword of investment
Every investment is a risk. Nobody likes to lose their hard-earned money, but when investing into product development, the risk of total loss is always there. As mentioned initially, investors neither care about Scrum, the team nor their work, only about ROI.Investors will do anything to protect their investment, that is - maximize ROI and minimize losses. If a product looks irredeemable, the investor will cut funding.
Scrum, a non-argument
When a product looks promising, but the team doesn't deliver as expected, the investor might have suggestions about changing the way the product is being produced: That's their right, bcause it's their money.The investor might simply suggest to stop using Scrum and try something else. The "But that's not Scrum" line won't make an investor flinch, because they're not paying for Scrum, they're investing for ROI.
Likewise, they might not care what the Scrum Master considers their role and responsibility, they will reduce a discussion with the Scrum Master to one question: "What have you done to ensure we're getting our ROI?" There won't be a long discussion whether it's appropriate for outsiders to tell the team how to work, because when investors are unhappy, there won't be a team anymore to do any work!
Dealing with investors
Depending on how attached/detached they are to the product, investors tend to ignore the team and focus solely on economic outcomes: market impact, bottom line revenue. Everything else is just a means to these ends.They tend to be easy-going on high performance teams and don't even want to think about what teams do all day, after all, that's their job and not the investor's business.
When you see investors getting dissettled with the team's work, your question shouldn't be whether they understand Scrum properly - but whether your team has understood Scrum properly!
Scrum Master interactions with investors
Investors obviously want to maximize ROI and might become pushy. Good may not be good enough. This might create a kind of adversary relationship between developers and investors. In such a situation, the Scrum Master may be invaluable to clear up the situation.Protecting the team
As mentioned above, when investors get unhappy, they might cut funding - and that's end of story for the team. So, when the Scrum Master is working with investors, diplomacy is your friend, and "protecting the team" won't mean taking out the big guns and letting investors know what they do wrong. It first and foremost means finding out how investors can be brought to see the value of the team's work.Transparency over Sheltering
If the team feels that investors would exercise undue influence on the team, then it is fully their responsibility to create a sufficient level of transparency to provide the necessary information that intervention is unneeded. When they worry that leaving things untouched means wasting a lot of precious money, they might intervene - otherwise, they won't. It's not like investors have too much time on their hands, anyways.Creating confidence
The Scrum Master won't need to coach investors on Scrum - if anything, the Scrum Master should convey that they themselves are representing what creates good Scrum: Getting things Done, being trustworthy and transparent, consequently and effectively dealing with impediments - and valuing product increments over being busy.Product Owner interactions with investors
The Product Owner is the sole owner of the Product Vision and the Product Backlog. At the same time investors provide the necessary funding to make this vision reality - so it's appropriate to communicate strongly in both directions with investors. "He who has the money chooses which tune is played".Sharing the vision
The Product Owner must constantly remind stakeholders both inside and outside the organization about the current vision as this can both change and be forgotten. As an investor, when the vision moves off my priority list, I might decide to take my money elsewhere.Sharing progress
Investors may or may not show up for Reviews. Still, they have important investment milestones and need to be updated to make decisions for further funding. Product progress is important before launch, but as soon as you launched, more important are metrics such as customer base, campaign progress, market acceptance etc.These may look like distractions from delivering on the product vision - but they aren't. They are reality checks.
The terms "un-agile" or "not Scrum" aren't suitable for any activity related to progress sharing. Give the investors what they need, how they need it: Being agile is about having sufficient flexibility to meet u to circumstance.
Accepting input
Investors might suggest tweaks to the product, the product vision and even changes to the Product Backlog or ways of working. Even when these suggestions look like overstepping the autonomy of the PO and/or team, the PO is well advised to take them seriously, because such input wouldn't be provided without the intention of maximizing product success in order to secure continued funding.Again, terms like "not Agile" are unsuitable in this context, because investors seriously don't give a hoot about what you consider "Agile" or not - they care about securing their investment.
And what's wrong with "Waterfall-ish" or "Command and Control" actions if the outcome is increased success?
No comments:
Post a Comment