Adolfo González Uzábal

Spend enough time talking with entrepreneurs, product people, designers, and anyone charged with proving something, and you’ll bump into questions about validation.

“How do you validate if it’s going to work?”
“How do you know if people will buy it to not?”
“How do you validate product market fit?”
“How do you validate if a feature is worth building?”
“How do you validate a design?”

You can’t.
You can’t.
You can’t.
You can’t.
You can’t.

I mean you can, but not in spirit of the questions being asked.

What people are asking about is certainty ahead of time. But time doesn’t start when you start working on something, or when you have a piece of the whole ready. It starts when the whole thing hits the market.

How do you know if what you’re doing is right while you’re doing it? You can’t be. You can only have a hunch, a feeling, a belief. And if the only way to tell if you’ve completely missed the mark is to ask other people and wait for them to tell you, then you’re likely too far lost from the start. If you make products, you better have a sense of where you’re heading without having to ask for directions.

There’s really only one real way to get as close to certain as possible. That’s to build the actual thing and make it actually available for anyone to try, use, and buy. Real usage on real things on real days during the course of real work is the only way to validate anything. And even then, it’s barely validation since there are so many other variables at play. Timing, marketing, pricing, messaging, etc.

Truth is, you don’t know, you won’t know, you’ll never know until you know and reflect back on something real. And the best way to find out, is to believe in it, make it, and put it out there. You do your best, you promote it the best you can, you prepare yourself the best way you know how. And then you literally cross your fingers. I’m not kidding.

You can’t validate something that doesn’t exist. You can’t validate an idea. You can’t validate someone’s guess. You can’t validate an abstraction. You can’t validate a sketch, or a wireframe, or an MVP that isn’t the actual product.

When I hear MVP, I don’t think Minimum Viable Product. I think Minimum Viable Pie. The food kind.

A slice of pie is all you need to evaluate the whole pie. It’s homogenous. But that’s not how products work. Products are a collection of interwoven parts, one dependent on another, one leading to another, one integrating with another. You can’t take a slice a product, ask people how they like it, and deduce they’ll like the rest of the product once you’ve completed it. All you learn is that they like or don’t like the slice you gave them.

If you want to see if something works, make it. The whole thing. The simplest version of the whole thing – that’s what version 1.0 is supposed to be. But make that, put it out there, and learn. If you want answers, you have to ask the question, and the question is: Market, what do you think of this completed version 1.0 of our product?

Don’t mistake an impression of a piece of your product as a proxy for the whole truth. When you give someone a slice of something that isn’t homogenous, you’re asking them to guess. You can’t base certainty on that.

That said, there’s one common way to uncertainty: That’s to ask one more person their opinion. It’s easy to think the more opinions you have, the more certain you’ll be, but in practice it’s quite the opposite. If you ever want to be less sure of yourself, less confident in the outcome, just ask someone else what they think. It works every time.

Being a great manager and English gardening have more in common than you might imagine.

If you want to improve your leadership skills, there no shortage of analogies that have been made about great managers.

A great manager is a “coach,” a “captain of a ship,” or even a “human shield.”

However, I heard a more unlikely comparison about leadership made on our podcast, The Heartbeat, when I interviewed David Cancel, CEO of Drift. He told me:

“I kind of think about most of this stuff as English gardening. If you want an English garden most of the work is actually the pruning and the taking care of. It’s not the planting, it’s not the plant selection. It’s this constant pruning. The day that you stop pruning is the day that the garden is full of weeds and overrun.”

I found this to be a brilliant analogy on several levels.

First of all, pruning is a small, seemingly minor activity. You’re not making big, sweeping moves of planting new shrubs or replanting a whole tree. This is also true of good leadership. We often believe great managers must take broad, bold actions. Strong decisions, rousing speeches, uncharted direction. But that’s not really what leadership is. It’s is not lavish, nor massive. It’s small, incremental action that engenders real progress in the long run. True leadership is genuinely saying “thank you” when a team member does a favor for you, or asking “How could’ve our last one-on-one meeting been better?” before you meet with a direct report.

Second, when you prune, you clip away the dead leaves or diseased areas of a garden to encourage healthy growth. A great manager does this, as well. They focus on removing frustrating blockers for their team – be it changing an unrealistic deadline, or deciding to fire a rude customer. They figure out what parts of the team are in decay or lacking in resources. Great managers focus on paring back, and then getting out of their team’s way.

Pruning is also done periodically, only when the season is fitting. If you prune all the time and you can accidentally over prune a plant and deprive it of nutrients. Leadership is similar. Harvard Business Review published research revealed on how managers who are “constantly coaching” overwhelm their team and exhaust them. After studying 7,300 managers, they discovered “employees coached by Always-on Managers performed worse than those coached by the other types.” Constant coaching, like constant pruning, is a bad thing.

However, at the same time, fail to prune consistently over time, and, as David mentioned, your entire garden will be overrun. Weeds sprouting, stems rotting. As a manager, you must be mindful of this. You can’t expect that a single one-on-one meeting with your direct report, once a year, will be sufficient for understanding their thoughts on what could be better about the team. A regular, steady cadence of communication – especially for one-on-one meetings – is critical if you’re to feel connected to your team as a leader. In both leadership and English gardening, “one and done” doesn’t work.

Thank you, David, for making this analogy. Who knew pruning English gardens could be a source of inspiration for us as leaders.

---

Claire is the CEO of Know Your Team – software that helps you avoid becoming a bad boss. Her company was spun-out of Basecamp back in 2014. If you were interested, you can read more of Claire’s writing on leadership on the Know Your Team blog.

Consider two loading docks at small companies.

At the first, a tractor-trailer filled with heavy boxes shows up. The sole worker on the dock is tasked with unloading the trailer, asap.

He puts on his gloves and begins hauling the boxes, one at a time. He’s manhandling them off the truck and straining to stack them to the side. Eight hours later, he has a strained back, blisters and an empty truck. A day’s work, hard earned.

At the second dock, the sole worker looks at the truck and then heads next door, to the larger company and their foreman, a woman he met on the bus to work last week. “Can I borrow your hand truck and ramp for an hour?” It took guts to ask, he might have been rejected, but his calm manner and ability to connect worked.

An hour later, the truck is empty.

Who worked harder today?

For most of us, hard work is measured in insight, emotional effort, and connection. It’s been a long time since the economy fairly rewarded people based on brawn alone.

And now, consider the third company, where the person at the dock planned ahead and had everything ready as soon as the truck was scheduled to arrive…

Or consider the keyboard workers, one of whom does a repetitive task all day long, and the other who did the labor to find a plug-in or macro that would do it in a few minutes…

Statistics, well done, are astounding.

They tell us, clearly and completely, what is actually happening.

Ignaz Semmelweis saved a million lives (eventually) with his approach to statistics, despite the fact that he was arguing for a significant change and was not at all well liked.

There are volumes of detailed and verified statistics about carbon and other emissions. They’re easy to find if we care to look at them and understand them.

More banal but simpler to visualize, it’s easy to dispense with hype and claims from a running shoe company like Nike, but impossible to dismiss this extraordinary report from the Times. They addressed the possible self-selection and placebo effects and still came up with a massive performance shift in an industry where I thought it was impossible to deliver a massive performance shift.

[If you’ve been putting off stats because the math is intimidating, spend thirty minutes with the Nike article and the Semmelweis story. It’s worth learning what they did, because it will help with your work and the way you see the world when you make decisions.]

Every once in a while, we can see a significant effect in the world, one that’s caused by engineering and can be measured. It’s rare, but it’s worth seeking out. Not everything is simply a matter of belief.

Yes, it’s easy to lie with statistics, but quite gratifying and insightful to tell the truth with them.

Statistics never work as well as we might hope. Since we’re humans, statistics don’t change minds. It’s the story we tell ourselves (and others) that do. Statistics are merely a consistent and reliable way to tell yourself a story that’s actually useful and resilient.

The post It’s All Relative appeared first on LeadingAgile.

Do you want to be a great Scrum Master?

I hope so. (Well, unless you’re a product owner or in some other role!) I’ve spent over 20 years as a Scrum Master. Over that time, I’ve given and collected quite a lot of advice. I’ve distilled it down to the ten best bits for you.

1. Never Commit the Team to Anything Without Consulting Them First

As the Scrum Master, you do not have the authority to accept change requests (no matter how small) on behalf of the team. Even if you are absolutely positive that the team can fulfill a request, say, “I need to run this by the team before we can say yes.”

And certainly don’t commit the team to deadlines, deliverables, or anything else without first talking to team members. You may not need to talk to the whole team--plenty of teams will allow some or all members to say, “Yeah, we can do that” without a whole-team meeting. But it’s still their decision, not yours.

2. Remember You’re There to Help The Team Look Good

Being a Scrum Master is not about making yourself look good. You look good when the team looks good. And they look good when they do great work.

You know you’re doing your job well when those outside the team start to wonder if you were even needed. Yes, it can be scary if your boss wonders if you’re necessary. But a good boss will know that your skill and expertise make you appear unnecessary when in fact you are indispensable.

Trust your manager to understand the difference between looking unneeded and being unneeded.

3. Don't Beat the Team over the Head with an Agile Rule Book

Neither Scrum nor agile comes with a rule book (though some have attempted to create one).

If your product has users, consider writing user stories. But stories aren’t required to be agile. If someone needs to know when you’ll deliver: estimate. If not, maybe you don’t. If you think an end-of-sprint review is too late to receive feedback, do one-at-a-time reviews as each feature is built.

Being agile is about honoring the principles and values that create agility. If you stay true to those, you can’t go too far astray, regardless of what some may tell you.

4. Nothing Is Permanent So Experiment with Your Process

Part of honoring the principles of agility is to experiment with your process. Encourage the team to try new things.

Does your team love two-week sprints and think they’re working perfectly? Great. Now ask them to try a one-week or a three-week sprint and observe the results. Experiments might not always be popular, but they are the best way to ensure that you continue to uncover new, better ways of working.

5. Ensure Team Members and Stakeholders View Each Other as Peers

Team members and business-side stakeholders each bring an important perspective to a product development initiative. As such, each needs to be valued equally.

When either side views the other as something to be tolerated, the organization as a whole suffers. Development teams need to understand the unique perspective brought by stakeholders. And stakeholders need to respect the development team, including listening when developers say that a deadline is impossible.

6. Protect the Team, Including in More Ways than You May Think

Perhaps the most often given agile advice is that a Scrum Master needs to protect the team from an overly demanding product owner or stakeholders. And that’s good advice. Sometimes product owners simply ask for too much too often and too aggressively. This forces teams into cutting corners, usually quality corners, that come back to haunt the project.

And so a good Scrum Master protects the team against this.

But what you don’t hear as often is that a good Scrum Master should also protect the team against complacency. Good agile teams seek constantly to improve. Other teams settle, perhaps unconsciously, into thinking they’ve improved enough. And they likely are dramatically faster and better than before they’d heard of agile. But even great teams can often become even so much better.

Great Scrum Masters protect teams from ever feeling they’ve got nothing left to learn.

7. Banish Failure from Your Vocabulary

Every now and then I’ll visit a team that refers to a sprint as a “failed sprint.” Usually this means the team didn’t deliver everything they planned. I hardly consider that a failure, especially if the team finished most planned items or if they deftly handled an emergency.

When a basketball player shoots the ball toward the basket and scores, it’s called a field goal. When the player misses, it’s called a field goal attempt. Not a failure. An attempt.

Good Scrum Masters help teams adjust their thinking so that they recognize sprints and features that fall short of expectations as attempts rather than failures.

8. Praise Often But Always Sincerely

The other day I told my teenage daughter that I was proud of her. Her face lit up. That shouldn’t have surprised me. Who wouldn’t like to be told someone is proud of them?

But the way she reacted made me realize I must not tell her this often enough. I thought it was equivalent to me telling her something obvious, such as, “You’re tall.” But I learned it wasn’t.

Don’t ever offer false praise. No one wants to hear that. But when your team members do good work, let them know. Chances are, they aren’t hearing it often enough.

9. Encourage the Team to Take Over Your Job

A team that is new to agile will rely on their Scrum Master or coach in significant ways. The team may not know how to keep daily scrum meetings under fifteen minutes. Or they may not understand the importance of overlapping work or of being a cross-functional team.

The same is true of a an inexperienced sports team. The coach of the little kids learning to play football (soccer) needs to teach them everything. When my daughters were 6, their coach would run along the sideline the entire game yelling, “Kick and run!” If he didn’t, the young players would forget. Even with him yelling, occasionally some kid would just sit down on the grass and stare.

Contrast the coach of the young kids with the coach of a World Cup team. On a World Cup team, players have learned what to do. If the coach is late for practice, the players will know what drills or exercises to start the day with. The World Cup coach doesn’t need to remind the players to kick and run. But the World Cup team would never tell you they don’t need a coach at all.

No matter how good an agile team gets, I still think they benefit from having a Scrum Master or coach. But good agile teams take on some of the more straightforward coaching tasks themselves as part of their own journeys to mastering the skills needed in product development.

10. Shut Up and Listen

Some of the best coaching or mentoring you’ll do is to stay silent and let the team figure out the answer.

This can be hard. When you see your team struggling to figure out what to do, it’s natural to want to jump in and offer advice. But if you solve problems or even offer suggestions too readily, team members learn to just wait for you to solve every problem for them.

I don’t want to imply you can’t ever offer suggestions. You’re a smart person. If not, you wouldn’t be in the role you’re in. But part of being a great Scrum Master is helping teams learn how to solve problems on their own. If you solve every problem team members face, they don’t get a chance to learn how themselves.

What’s Missing from this List?

I’m sure I’m missing some pearls of wisdom. What is some of the best one-sentence advice you’ve received or given as a Scrum Master? Please share your thoughts in the comments below.

Suppose your organization doesn’t truly know what would be valuable to your customers and you don’t have good technical practices, delivery capability or Agile project management. What would you improve first?

Would a focus on customer value lead to improved technical practices?

Would a reliable delivery process enable the organization to explore and meet customer needs more effectively?

Okay, let me ask you this….Is there any point in a software development team learning to build higher-quality software and learning to do it faster if it doesn’t solve a business problem, remove a constraint, or help meet our business goals?

Focusing on Value to Customers First

If you have a good product idea, good market fit, and good product management practices then you have a shot at success even if development capability needs improvement.

Is the converse true?

If you have a lousy idea, it doesn’t matter how good your software development organization is. So what if you’ve got continuous deployment? If the “what” you’re building is wrong, you’re just auto-deploying code that doesn’t drive any business value.

So that’s a vote for focusing on value to customers first.

Focusing on Technical Practices First

Better technical practices—even if it’s little more than getting the wrong stuff out there faster—should, in theory, lead to faster learning. Faster learning that you’re doing the wrong thing, assuming a minimal level of market/customer awareness.

Improve your delivery capability anyway because doing so will do two things:

1. It prepares you for later
2. It may cause the organization to improve in other areas

If it does, it’s because you’ve created a learning organization. So, change anyway and build the organization’s ability to change—its ability to remake itself.

So that’s a vote for focusing on technical practices first.

Across the Whole Organization

When you begin an improve program, it’s wise to improve technical practices across the whole organization, or at least as far as there are interfaces and dependencies between teams or projects. Failing to move everyone along can frustrate the improved team, living in an organization that can’t consume their work at the rate of production, or can’t feed them inputs or resolve dependencies fast enough.

Parting Thoughts

I’ll leave you with this:

• Improving technical practices throughout an organization takes a long time.
• Learning good product techniques and skills takes months of guided practice.

You should tackle them both.

Attack a few of the biggest constraints that the organization is capable of attacking and do it at the same time.

That is, consider capacity for change. An organization has capacity for only so much change and leadership can manage only so much. But thankfully, the product organization and the technical organization typically have separate leadership and thus distinct capacities for change.

They can change simultaneously.

The post Technical Practices or Value to Customers: <br>What to Focus on First appeared first on LeadingAgile.

I’ve worked for LeadingAgile for the better part of four years.  Did you hear that? The word is even in the name of the company that pays me.  Agile.  It used to matter to me, but now that  I’ve been an Agile practitioner for almost 15 years—I’m not even really that passionate about it.

I’m sure by the time this is published I will have had to reassure my executive team and peers that they don’t need to worry. However, don’t get me wrong. Agile techniques and practices are about the only tools I would ever use in my consulting engagements. Agile practices, Agile program management, and Lean portfolio management are some of the best tools available for managing delivery systems.

AGILE IS MERELY A TOOL

But that’s my point.  Agile is a tool.  It’s a set of practices, guidelines, ceremonies, artifacts, and concepts.  There are as many ways to do Agile planning as I have fingers and toes—maybe more.

I’m as passionate about Agile as I am about the dozen or so screwdrivers hanging on the wall in my basement right now.

Great tools.  Necessary to have around.  Useful in all kinds of settings for purposes they were intended, like assembling a DIY bookcase or opening a paint can. And, even a few creative purposes like opening a wine bottle when the cork is broken.

Agile is useful, even necessary, in today’s world.  If you’re looking for improved processes to manage your overall delivery ecosystem, then Agile should be your tool of choice.

Instead of being passionate about Agile, let’s get excited about change instead.

So, what do I care about these days?  I care about change.  I would like you to use Agile as a tool  to facilitate that change, and if you work with me; you will. But, using Agile without changing the way you work, think, and interact seems a bit pointless to me.

What I care about, and I suspect you do too, is seeing the kind of change that improves outcomes and, frankly, quality of life.

More than mere change, even, I care about Transformation.

GET EXCITED BY TRANSFORMATION

How do you think about Transformation?  Is it radical change?  Is it measured and incremental?  Does it mean everything changes?

Here’s how I think about Transformation. First of all, it’s not the desired outcome.

Change for the sake of change is called insanity, not Transformation.

In fact, I believe every client, and perhaps every team, has a different desired outcome.  Sometimes it’s to be more competitive in the market they serve.  For some, it’s to invent ways to serve or even create new markets.  For others, it’s about controlling the costs associated with running their current business.  Your outcome is unique.  But each of these outcomes typically requires Transformation to achieve.

I see Transformation as the motion, the movement—the journey—from the starting point to the point where you finish and then move past into something better.  It should be no surprise that, oftentimes, the finish point is not always precisely where we thought it would be when the journey began.  And, if it isn’t better, it isn’t the end.  The end point will always be better.

How I approach Transformation as part of my consulting work is not through teaching how to do the best daily stand-up or create the best product roadmap; it’s through helping you create and sustain the motion necessary to inspire and motivate the individuals in your ecosystem to work together differently. Granted, awesome daily stand-ups and outstanding product roadmaps are critical tools.

But, what gets me excited and passionate is working with you to create, and be successful leading, an exciting, unifying, and meaningful journey toward your something better.

The post Why I’m Not Passionate About Agile appeared first on LeadingAgile.

Culture is just the boogeyman people use when they don’t know how to articulate an organizational change management strategy that executives will buy into. – Mike Cottmeyer

You should do Scrum.

You should be open to change.

You should be a servant leader.

You should empower your people.

No?

You’re a bad leader. You have a bad culture.

Maybe, but I’m telling you…companies have legit barriers to adopting Agile. Non-trivial problems to solve.

Companies have competing interests and needs. Poor technology architecture. Uneven staffing models. Lack of subject matter expertise. Crushing market pressure. Governance and funding challenges. Broken systems of delivery.

Even if you know what to do, fixing these things takes time and costs money.

In the interim… work has to get done, clients have to get served, revenue has to be generated.

Careers are on the line.

Unless you have an answer to exactly how a company is going to introduce Agile in an economically justifiable way… how they’re going to remove the impediments to Agility… how they’re going to hire the right people… how they’re going to service the existing customer commitments… how they’re going to meet the expectations of their market… and how they’re going to make money while they do it… you don’t have an answer.

Pointing to culture as the problem is insufficient.

If you were king for the day. If you could flip culture overnight. What would you have everyone go do tomorrow?

If you don’t have an answer to that question, culture is not your problem.

Culture is just the boogeyman people use when they don’t know how to articulate an organizational change management strategy that executives will buy into. – Mike Cottmeyer

The post Culture is the Boogeyman appeared first on LeadingAgile.