How I Made My Team Deliver Value After Failing for 6 Months
Scrum is a framework difficult to learn and dangerous to master
For 180 days, I cranked out endless UX projects that were applauded and then trashed by the end of each and every Sprint. Developers wrote thousands of lines of code that never reached a single one of our customers.
You’d be surprised to know that it didn’t happen at a startup, but at a multi-million eCommerce instead. We were struck by a combination of Covid-19 + the onset of our Agile transformation + new business model — the perfect recipe for this disaster my squad went through.
After 6 months of failure, I approached our Agile Coach and said: “if our CEO checked the ROI of our squad today, we’d all be unemployed by tomorrow”. That’s when I realised I had to do something — and many things I did, leading to a salary increase 2 months later!
I’m sharing these hands-on tips with you today because I know there are endless Scrum Teams struggling out there. Feel free to leave any questions in the comments if something is unclear to you. :)
1st mistake: an obsession with points and velocity
As the great Maarten Dalmijn states: “companies that worry about velocity are clueless about Scrum.”
I remember this one stakeholder that always joined our Reviews with a look of disbelief in her face. That’s because she knew what the devs and Product Owner were about to say — which was the same they said every Sprint:
“But see, we delivered these many points and coded all these things here in the done column. You can’t see it, but we are doing work!”
Yeah, all these worthless things and unnecessary work, you mean. Delivering points and delivering value are two worlds apart, as the Agile Manifesto clearly states below:
“Working software is our primary measure of progress.”
Do you have working software that delivers value to the customer by the end of the sprint? No? Then it’s irrelevant: Scrum is not a video game in which you seek points on a leaderboard — we have a Need for Value, not for Speed!
And no, I’m not suggesting points are useless. (Actually, that’s what I like most about Scrum.) I’m just saying that if points and velocity are your main concern, chances are your team is failing hard and, most likely, those metrics are certainly NOT the reason.
How I solved it
Championing a M-A-N-D-A-T-O-R-Y practice that many specialists deem to be optional: Sprint f*** Goals, my friend.
“The heart of Scrum is a Sprint (so) each Sprint has a goal of what is to be built (and) the resultant increment.”
Can you live without your heart? So can’t your development team! You either let Sprint Goals pump some purpose into your sprints’ heart or you risk having 6 months of arrhythmia.
We conducted Plannings making estimates and asking Devs what they could deliver — and we sure worked a lot — but we always forgot to ask: “what do we really want to achieve? How does this task lead us to our North Star Metric?”
Seriously, what’s the purpose of building anything if you don’t really know what you want to achieve? There’s a misquote from the Cheshire cat which says: “if you don’t know where to go, just about any way goes”. The same applies to Product Management: you either have a clear roadmap or you can simply save time by picking tasks at random. Your results will be the same.
“If you don’t have a goal, then finishing all tasks becomes the goal,” — Maarten Dalmijn
This Sprint, for instance, our Visual Merchandising team didn’t have enough people to release our main Epic. Now, do I like VM? Do I like coding that site? No, I despise both, but I immediately volunteered since that was our goal.
That’s because Goals make your team rally around what matters most. Wasn’t for that clear Sprint Goal, this what would follow:
- The VM team would be embarrassed for failing;
- My PO would have to explain herself to our Head;
- Then our Head would have problems with our Director;
- And the same cycle would unravel in the other Tribe;
- Oh, and Customers would continue having a bad experience for weeks!
Yeah, the Dev Team could simply wash their hands since they had nothing to do with it, but that’s not the corporate mindset we need. Not the values the Scrum Guide preaches.
2nd mistake: pursuing dream-projects rather than assertive solutions
I’m a designer. Designers are trained to design the best possible solution even when things are trivial, so if we could spend a whole month embellishing a single icon, be sure we would!
That may be a good thing in the arts, but it’s absolutely awful when it comes to product management. Spending too much time on development is one of the best ways to pave your competitors’ road to success.
The funny thing is: all managers I’ve met throughout my life were also accursed by that pursuit of greatness. As humans, all of us want to be part of something great, but if there’s one thing experience will teach you, is that such greatness takes time — and time costs money, so you need to mitigate your expenses along the way.
To be successful with Scrum and Product Management, it’s crucial that you focus on delivering value as soon as possible, so you can validate your ideas, mitigate costs, and innovate at a faster pace than musing about perfection would ever allow you to.
How I solved it
Advocating for Vertical Slicing and MVP-driven development.
Here’s a great example: as a Brazilian marketplace, our clothes are distributed all over 8.5 million kilometres. Shipping costs of a t-shirt can vary between 10 and 200 bucks — it all depends on your (and the clothes’) location.
Here’s how things unravelled:
- “We need to make our carts show detailed shipping info so people will remove expensive products,” I suggested;
- “The platform restricts our coding efforts there”, the developer objected. “This may take 1–2 months”;
- “Customers are bombarding us every day”, I reminded, “maybe we should start by adding shipping price to product pages”;
- But if they don’t calculate shipping there, they’ll still be shocked during checkout. “It also may take up to a week of development”, the dev said;
- “True thing, so let’s do some UX Writing here: let’s add a short, friendly warning to our product pages and carts explaining how shipping works.”
- “Ok, that may take an hour or two”, the dev said.
We sliced and MVPed our solution until we found something that could be released in no time — and as a result, our contact rate dwindled; social media haters stopped; our Net Promoter Score rose; cart abandonment rate dropped.
We achieved all those things in two hours, ending weeks of endless hate comments in our pages. That was only possible because we focused on the problem rather than the solution — satisfying our customers’ needs before our creative egos.
No, we didn’t give up on that new cart design with all the detailed info. We just delivered a faster proto-solution so we could appease our customers and work on the ultimate design peacefully. (An awesome true win-win situation!)
My best advice would be: always ask yourself how to address a problem faster and how to make a project smaller. If most of your user stories can’t be solved within a Sprint, odds are you are planning your sprints the wrong way.
Most problems can be addressed by targeting specific parts of it; others may require a more encompassing approach, but that can be done with an MVP. Regardless of the case, going step by step will 1) bring you faster results, 2) faster learning, and 3) enable you to design a better final solution to it.
3rd mistake: an inexperienced Scrum Team
I first have to say that I’m not questioning anyone’s abilities. Here we say we value people above all, and awesome people we have, but weren’t the right people to face Covid-19 + Agile transformation + new business model.
This was particularly bad to my squad since we work for the least important brand in the group so — although our Agile Coach did his best to aid us — we lacked the appropriate resources to make our squad valuable. (That analogy about changing a tire while driving never felt so real!)
How I solved it
I signed up to Medium and read 70 Serious Scrum articles within a month. I also joined a University of Michigan’s Agile program a while ago.
Sorry if you expected some spectacular resolution to this, but all it took was a burning desire to make things work. Reading was enough to pinpoint our weaknesses during Scrum events and, for my surprise, my managers were happy to hear it from a junior. (I told you we have awesome people!)
Here are a few suggestions:
- Road to PSM III by Sjoerd Nijland renders the Scrum Guide useless
- Sprint Goals by Maarten Dalmijn
- New to Product Management? by Rameez Kakodker
- The importance of saying NO by David Pereira
- What the Scrum Guide doesn’t say by Dan Ray
- Agile is a Cursed Name by Romario Eichlig
4th mistake: UX, managers, and developers were never aligned
You spend weeks reading about the neuromarketing of discounts. You benchmark solutions; you sketch it; you design it — and the dev trashes it.
Actually, It was never even possible to build it in the first place…
We were so velocity-driven that Plannings were a mere formality, never aligning stakeholders and users’ needs. We didn’t do proper Discovery phases because it would delay development, “so why don’t you just design it and later we see if we can build it?” (No one said that, but I heard it in my mind.)
There were also times that we indeed built everything exactly as requested — except that it wasn’t really requested. That’s because demands were so focused on alleged solutions that we hardly knew what we were building it for — so our products were usable, but rarely useful. (Usable = works perfectly; useful = addresses needs perfectly.)
How I solved it:
I trained my facilitation skills and group dynamics. Am I good at it? Hell, no, but it’s enough to fix our processes and — since I survived our performance review — there’ll be plenty of opportunities to keep improving.
One way I put it to work is by leading design thinking processes so we don’t start major projects with endless unknown-unknowns. Now the UX Designer, known as I, won’t move a finger before we know something can be built.
No, I don’t host our Scrum events, but such skills brought me the confidence to intervene when the process seems off, so the Dev Team is no longer a passive agent in our meetings.
There’s this quote I love and would like to share with you: “I don’t suppose anything; I either know or I don’t know”. Always have in mind that design and coding cost money — so don’t turn our wage into a guess.
5th mistake: we never said “no”
Working with the Spotify model, we have 7 brands split between a digital commerce tribe and a product tribe. Since the eCommerce tribe is the one making the money, they get to demand whatever they want — and their short-termism is terrifying.
Retailers have a new pressing calamity every day — it can be logistics, politics, marketing, finances, etc. — and they can think of megalomaniac ways to solve it in a minute. (Oh, that ought to be delivered by yesterday, of course!)
That’s when you manage to travel back in time, build the Eighth Product Wonder they needed and suddenly realise they never needed it. Everything is now discarded and so will be everything else for the next 26 sprints.
How I solved it
I reenforced that the product squad is autonomous, just like theirs, so we have our OKRs to be met. Also, I started asking “does it really matter?”
All managers had OKRs in their heads but the development team didn’t even know they existed, thus we didn’t know what we were fighting for. That’s why I built an Epics roadmap with our OKRs to ensure everyone was aligned and that all backlog items would be assigned to a real goal. (“If it doesn’t fit, maybe we don’t need it.”)
No, I didn’t become a preacher against the eCommerce — we are in this together after all — but they needed to learn we can help them beyond the short-term. (And that we have our own Head to report progress to by the end of the quarter, so…)
I also suggest you print an Important vs Urgent Matrix and Stick it to the wall behind your bed so you never forget how to prioritise work. Not knowing the difference between important and urgent tasks is one of the worst sins product managers commit every single Sprint.
Example: “We need a new coupons page!” Yeah, we sure do; we are an outlet and that’s what customers come here for… But here’s the thing: shipping price has gone haywire and costumers want us dead now.
Both of those tasks matter, but one is important and one is urgent — just like treating a bad knee is important whereas treating a stab is urgent. Sorry to go criminal here, but the only problems of equal importance I can think of would be having both my parents at gunpoint at the very same time.
Everything else can be reassessed, ranked, and prioritised.
“Agile is a curse name”, I told you last month. The road to true agility is paved with endless pitfalls that can not only ruin your productivity but also your team’s morale and your will to move forward.
It doesn’t need to be that way.
We from Serious Scrum share hands-on tips and practical knowledge every single day to make Scrum practitioners more effective and, from my own personal experience, healthier and happier.
Make sure you follow us and feel free to drop any questions you find suitable; I’ll be more than happy to lend you a hand! = )
Do you want to write for Serious Scrum or seriously discuss Scrum?
Special thanks to Maarten Dalmijn for saving our squad with his articles, and reviewing this piece, of course!
