Category: Lean

5 Simple Rules for Real Agility 

4 Comments

There is a very wide spectrum from the mythical evil-waterfall-monolith to a perfectly lean and utterly agile continuous delivery of value. In fact, scratch that, it’s not really a spectrum. It’s not even a consultant’s two-by-two matrix. It’s a complex multivariate systems-view that is needed, and fighting religiously for absolutes doesn’t help improve any of the real trials and tribulations on the front lines.
Come on – Don’t try to enforce one-size-fits-all agile or lean or kanban. Instead, create your own adaptive center of excellence from any approaches & tactics, new or old that can provide insights into the variety of techniques that can be adopted for each situation.  

For example, a really well-formed support team could move to kanban and get rid of most of the scrum ceremonies. Likewise, not every multi-scrum-team product needs a cadence of Program Increment planning – but (be honest) some do.

The bigger the organization, the more important it is to be practical in your approach to change you’re passionate about. Self-check: Are you asking for a change that makes the organization easier to work in, better at serving the customer, or more sustainable as it grows? Great! Don’t let fundamentalism get in the way of the spirit of agility and the purpose of your organization.

….Especially if you are an enterprise that is “mid-transformation”.

In fact, rather than worrying about drastically changing to a new and elaborate process with all the answers (which will definitely FAIL), there are just a few underlying principles that will help evolve an enterprise toward lean agility:

1 – Each time you make a business decision, make one that makes it faster to validate your assumption than if you hadn’t made a decision at all.

Anytime you make a decision, make it easier to recover from it as an organization if you are wrong than if you had done nothing at all.

2 – Challenge the biggest assumption first, working to disprove one hypothesis at a time

3 – Each time you touch code, leave it simpler to understand and easier to change than if you hadn’t coded at all

4 – Create an environment of psychological safety for your people

5 – Do no harm to the user

The DevOps Secret that IT Won’t Tell You

4 Comments

DevOps. SAFe. Scrum. Kanban. Did you shiver? The experts have you scared you’re doing it wrong (you know, IT – all of IT). The certificate-teachers need you to need them so they can get paid. The coaches and consultants are taxing your #FOMO (Fear Of Missing Out) on ALL THE AGILE.

Get. Real.

It’s an impossible dream: The perfectly lean and agile software process would be just one person – a masterful engineer with great people skills and business acumen who can hang around a group of people to see what troubles them, create an intuitive software tool that relieves the pain, and collect cash from them while obtaining ultra-constructive feedback. In other words “dev” and “ops” as one person.

Ever seen that happen?

That said, every additional person involved in the flow of DevOps information is either a value-addition or a source of systemic waste. More often, everyone involved is a bit of both. As more bodies are thrown at a problem, it is likely any one of them can only spend 10-20% of their time actually adding value. The other 80% – and all overtime – is typically waste due to waiting on information from others, or over-documenting our value-add so others can consume it.

So it isn’t that IT won’t tell you the secret, if they know at all. It’s easy to crack jokes about how little other people accomplish despite working long hours, but less likely that anyone raises their hand and volunteers the truth about how much time is wasted.

– Waiting for clarification

– Waiting for updates to install

– Waiting for SVN code check-in

– Waiting for someone else to check their code, setup a VM, or answer what their code means

– Waiting for the next meeting

– Waiting for the inspiration to work on something meaningless to you

The great big DevOps secret is that no methodology will fix all that waiting. Over-specialization creates a world in which teams throw big piles of shit over the fence, each group speaking it’s own language that no other group understands. New philosophies won’t fix bad relationships, a toxic culture, and shit tools. It takes time, work, and fearless leadership.

Otherwise, Agile, Scrum, Kanban, and DevOps – or any other recipe for “when to meet” and “what to document” – are like 30-day fad diets; it’s a false hope and a gimmick and it doesn’t change the sedentary fast-food lifestyle that keeps you fat in the first place.

10 Best Product Innovation Techniques

Leave a comment

Need to get a new app, web, or software product to market?  New to the game?  Here’s a handy Top 10 List of practices I’ve discovered along the way.  Instead of exhaustive explanations, Google any words below that are in bold and you will find a wealth of information.

  1. Live a little: Find a significant problem real people have.  Since this really isn’t a technique, go watch Seth Godin’s TED Talk – The Tribes We Lead
  2. Define a User Persona: Define who has the real problem with enough precision a stranger will understand you -For instance: “Women in their forties who get party planning ideas for their children’s birthday using Pinterest” and NOT just “Moms.”
  3. Is the group big enough to support a business model? Time to make a Lean Canvas and share it with a mentor or colleague you trust will give constructive feedback. Also check out How to use the Lean Canvas for App Planning
  4. Customer Interviews: Listen more.  Go to the place.  How are pains currently dealt with?  What is the inefficient current workaround or ineffective existing alternatives?
  5. Empathy Map: Pick an early adopter. Take their picture if they’ll let you.  That’s your new Hero Image.  Capture what she thinks, feels, sees, etc in the moment when the pain occurs.
  6. Pain-Driven Design Roadmap: The problem you want to solve relates to an overarching process or workflow that your target person already does. You should have witnessed this in all the steps above.  Create a prioritized roadmap of solutions based on the problems.  I use a variation of Lean Process Improvement described   Don’t get too attached to this lightweight plan, your goal is to disprove it.  Whatever you can’t disprove through experimentation gets to stay!
  7. User Story Mapping: Take the first item in your roadmap and break it into features. Put those Epics in the order a typical user will access them.  The break them into the tiniest imaginable User Stories you can.  Draw a line that gets rid of anything that isn’t absolutely necessary.  This is a great and tactical write-up via Atlassian’s blog: Guide to Agile User Story Maps
  8. Establish the One Metric That Matters: This will change over the life of the product. For a brand-new app, this might focus on “engagement” – For example, “How many users make it all the way to sending their first Tweet in Twitter?”  Make sure your MVP makes tracking that metric, as well as A/B testing and cohort analysis, possible.
  9. Scope out your Minimum Viable Product – keep cutting. You need so much less than you think.
  10. Experiment: Establish a baseline, be honest about your assumptions, and test the validity of each hypothesis.  If you don’t know much about delivering innovative products, check out Agile or DevOps and the Lean Startup for thought leaders and great ideas on getting better at innovation.

 

 

Breakthrough Agility

Leave a comment

The Olympic sprinter is the perfect metaphor for the lean-agile enterprise.  Being small is not sufficient for winning in a sprint.  Being strong is not sufficient for winning in a sprint.  Speed and agility are the outcome of a pursuit of mastery around which everything else is valued (including size, speed, and composition).  The agility of the sprinter is the rate at which an incorrect or suboptimal step or technique is noticed and corrected while remaining in motion.  It requires that the billions of near-instantaneous corrections in balance, force, positioning, and movement have been so intensely practiced that it can occur with very little thought.  The athlete achieves flow.

Perhaps that’s where the metaphor scares some people.  It suggests that when a Superorganism achieves mastery and fulfills its purpose, when a company is winning, in a state of “flow”, the brains of the company, the leader, in that moment becomes a passive observer of self-fulfillment.

If you want to win in the software industry, that exactly how you must lead.  Discipline, practice, continuous improvement, repetition, until you reach a state of economic flow.  Your eye on the finish line is all that is necessary and the body – through proper resources, experience, and focus – does the rest.

11 Steps to Revolutionize Your Career

Leave a comment

Ever wished you knew the key to getting to the next level, enjoying your job more, or just earning the raise you deserve?  That’s what this post is all about!

11 Steps to Revolutionize Your Career, Unlock Creativity, and Prioritize Your Professional Growth & Learning Roadmap

GREAT NEWS – the same techniques used to rejuvenate enterprises and drive strategic agility can help you to improve your position in your organization, your satisfaction at work, and the career path ahead of you.  I’ll show you step-by-step how to build a prioritized roadmap for professional growth and learning, as well as the science behind the art.  This is most exciting as a group experience – with a circle of friends who share your interests.  Don’t underestimate the power of a guild! Post-It Notes and group goals can be far more effective than going it alone.  Find your love, lead a tribe!  

The overarching idea is that you need to increase how much value you add to the process, the product, and the customer (if different, via the users).

I know “maximizing total stream economic value-add” sounds ivory-tower and too academic to matter to your daily life.  It’s true, no one doing real work talks like that. In practice, it means “time well-spent fixing a pain your customer feels.”  The more you directly relieve pain, the better!  That’s why the customer pays your company and your company pays you.  More pain-killing, better company.  You want to be as irreplaceable in that relationship as possible.

Documentation does not help the pain of the customer.  Budget planning or release plans don’t make a crappy user interface more intuitive.  Even if you literally Your deliverables are not your job.  Your ability to alleviate more pain for the customer than it costs the company to pay you – that is your “job”.  In entrepreneurial lingo – the strengthening the sustainability of your salary-for-value exchange is your only job.  The title, the process and your deliverables are all derivative.  Once you see it that way, improvements to your output, your process, and your skill set are all part of one “roadmap” that keeps your salary potential growing rather than stagnating. 

Let’s take it step-by-step.  Reach out if you have a question!

1 – Narrow your focus

To start, identify the most important information or resource that you handle.  Every role centers around one “wildly important thing” that needs to be accomplished by someone who can combine information and resources with professional knowledge and tools in order to create something new.  As an accountant, role centers around knowledge of the flow of cash and others constructs that can become cash.  The expert knowledge of the law, best practices, and tailoring the visibility of a company’s slice-of-time or in-flow cash is not only a full-time job, it can take an entire team.  If you are a software developer, you combine a problem assumption with your knowledge of code to create software that solves the problem.  As a Product Owner, you prioritize the flow of information to ensure problem-solution feedback loop is as tight as possible. 

2 – Get real about your value add

The way in which you add value in your one “wildly important thing” is a workflow.  It has an input, time in progress, and an output.  The five basic phases of any process as defined by Steven Borg are:

  1. Queue – Understand what to do 
  2. Setup – Get the necessary “resources” ready
  3. Run – Complete the goal
  4. Wait – Look for feedback on success/failure
  5. Move – Find the next goal to accomplish 

The “run” phase is the activity most companies call “performance” and likely that activity is the only thing they would want to pay for you to improve.  That said, we all know that the “run” portion of our week is only 10% to 20% of our time in the office.  Embrace that hard truth here – your role is a creative process and you have to fight for your creativity.  Make the entire process visible, not just the old-school boss-whipping performance dogma that resulted in Ford laying off 20,000 people in one day.

Be honest with yourself, be heretical, be brave.  As you map your workflow, you want to very objectively understand how much of your time is fluff due to the inherent inefficiency of information flow in society and your organization.

2 – Map “The Steps”

When I first learned about value stream mapping, I didn’t get it.  In fact the first several times I learned about it I wasn’t sure if I was missing something or if it was really as simple as it seemed on the surface.  Great news!  It really is incredibly simple and superficial.  It just takes a level of paying attention to mundane details we take for granted that most people just don’t take the time to do it.  Maybe quantifying how much of their job isn’t the “run phase” causes fear for their job security.  Unfortunately, companies full of people who love their work and don’t tolerate bullshit are taking down companies full of unthinking zombies every day.  Your job is not “safe” anymore.  Make yourself irreplaceable doing what you love.

Here’s what to do as you map the steps – somewhere between your job description and the “wildly important thing” you get challenged to do, you have established a routine of behaviors.  List out the steps. 

That’s it.

That’s “mapping a value stream”.  I told you it was simple.  The one difference between a to-do list and a value stream map is tacking on what you do to add value (relieving pain for a customer, right?).  For fun, write at the top of your whiteboard “The {your role} Way” – a proud tip of the hat to “The Toyota Way” that has inspired so much of Lean thinking.

3 – Map “The People”

Once you have listed out the steps you follow to create value, list out the people involved with each step.  It is possible that a department or a team is a bit of a “black box” in your process, which you should highlight!  If you know that you need information X from Susan, that is much more efficient than depending on X from “accounts payable”. 

Don’t skip this step!

4 – Map “The Time”

Go back through the steps and identify (even on average) the real minutes on the clock you spend on each step, then the calendar time waiting between each step.  If you’ve never taken the time to do this, you may find this analysis fairly emotional.  It isn’t comfortable to put on paper that you spend 5% of your time doing something meaningful and 95% of your time waiting and struggling to get “the system” to get out of your way so you can do your 5% and then go home or watch YouTube or whatever.  Do it anyway.  This isn’t about them, this is about you and how you can grow so that more of your time is more meaningful to you in your pursuit of mastery, autonomy, and purpose.  Our goal here is map out the business case for ways in which you can spend less time chasing that 95% or more time engaged in your 5%.

Caution – It’s tempting to run off and try to solve things or make a wish list or start blaming people for your problems, because time is a precious resource and “solutioning” ways reclaim your time is extremely rewarding.  DON’T.  That’s not the point of this exercise and it will ruin your reputation and you’ll miss the goal of this effort completely. 

This workshop is about how you can grow, learn, and enjoy your work more no matter what anyone else does.

5 – Take a deep breath

No really.  Take a break and relax.  You need to approach this calmly, logically, and thoroughly.

6 – Identify sources of waste

You already started this process while you mapped your value stream, but you need to go through step by step and really evaluate several things.  For one, look inward.  Which tasks do hate?  Which ones do you love?  When you feel disengaged, why?  Removing wait times and reducing task times would be nice, but the greatest source of inefficiency in your work is usually your own lack of focus or ability to “ramp up” your motivation.  Mastery requires pride in the mundane.  10,000 hours of scales as a violinist or guitarist; 10,000 hours of free-throws as a basketball player.  If your job includes something it is absolutely essential to your career and you hate it, that’s a symptom that you can grow in that area.

Now, let’s go through this very purposefully and objectively.  For every step, check if you have one or more of these sources of waste, then list it out.  Waste is anything that “adds no value” in your workflow or lessens the value that you add to the process.  Occasionally, you might even find you are, despite the best of intentions, reducing the value of information or resources.  Between us, that’s okay – there is immense wasted energy all around you.  You will be much more powerful by understanding yours.

Here are the types of evil, horrible waste you already don’t love:

  1. Waiting for input (information or resources)
  2. Over-production (doing something or making something no one used)
  3. Rejects or Defects (doing the wrong thing, or doing the thing wrong)
  4. Motion (unnecessary movement, like manually turning a Word doc into an Excel spreadsheet every week)
  5. Over-Processing (anything you do in which you “reinvent the wheel” each time)
  6. Inventory (any pile of information or resources, before or after you add value, that sits untouched for any period of time)
  7. Transport (time spent moving something of value – if it isn’t instant, why not?)

The other take-away you want to gain – for purposes of learning, growth, and personal development of mastery – is a list of any instance of miscommunication or misunderstanding, especially if there is any time when the format in which you receive information is difficult to understand without time spent interpreting it or asking for feedback.  Likewise, how much of your time is spent clarifying what what you provide to someone else?  That’s an opportunity for growth.

ONE MORE major thing to look for:

Waste of Talent or Other Scarce Resources (like your precious time) – Be honest with yourself and others (circle of trust) with this one.  When do you feel like your intelligence is insulted?  When do feel like you’re overqualified?  When do you think people around you are disengaged or wasting their real potential?  We need to find what we can do about those moments.

7 – WooHoo!!  Solve All Your Problems!!

My mentor in the App Roadmap Workshop, a variation of this process focused on enterprise mobility, always loved to say “’Magic happens here’ is okay.”  Of course, for that audience, talking about mobile, that meant “technology too advanced (or difficult for your company to implement) to assume it can be achieved now”.  When it comes to personal growth and development, you need to have the same optimistic view of all the options before the cold reality of life hits you as you struggle to learn.  Don’t prematurely rule out any resolution to any problem at this stage, because you’ll want to come back to this every three months and by then, all kinds of things – your role, your abilities, the tools available – may have changed.  For most of us, we need to just say “’future-me’ will sort out the details”.  That’s what we all do when we make bad decisions, let’s apply that same courage while making some really good decisions.

Go through each step, and every issue or waste you found.  Then do your best to identify something you could personally do differently change the inefficiency.  If people fail to provide adequate information, could you provide them a template?  Is there anything you can automate?  When you look at the situations where the most misunderstandings occur, is there anything you can learn to bridge the gap between your specialty and that other person’s?  Could you succeed more by setting better expectations? 

Put together all these opportunities.  Hopefully there are several.  I personally have more ways I could try to grow than I have time to invest in myself, but I’ve been building out this backlog for awhile and learning has a funny habit of unlocking awesome new ideas about what to learn.  Knowing all the ways you could grow is an extremely healthy form of self-understanding. 

8 – This is about MASTERY, AUTONOMY, AND PURPOSE

Mastery requires pride in the mundane and a deliberate effort to understand the periphery of your specialization.  If you are a Product Owner in a large enterprise, this could be technical training, UX or UI creation, business case building, customer interviews, or a host of other leadership, sales, marketing, development, or other capabilities.  Don’t be afraid to try new things.  Don’t be scared when your plan to try new things turns into a slap in the face about how hard it is to learn those things.  Now is a great time to decide how tenacious and dedicated to your personal development you are.

9 – Prioritize, Prioritize, Prioritize

In Lean, we know that the amount invested in a system from one day to the next is relatively stable.  Because of this, prioritizing investment of time and effort should work to reduce the cost of delaying action.  In software, this means comparing opportunity cost of two features.  If you can only integrate Twitter sharing or Facebook sharing, which one is less urgent?  Invest in the most urgent need first.  There are a number of ways Calculate the Cost of Delay for the changes you want to make, but we will customize this for your personal learning and professional development roadmap.

This is a variation of Weighted Shortest Job First which you can find at www.scaledagileframework.com/wsjf

Line up all the solutions to your problems you came up with in a list.  If you can put this into a spreadsheet, that might be handy for the purposes of staying neat, but post it notes work fine as well (and are better in a group).  This is your formula:

(Potential to Increase your Value Added + Time Sensitivity + Career Opportunity)  / Time Investment

You’ll add each of those as columns in your table.  To give an example, let’s compare two learning goals that you believe will improve the value you add in your role:

  1. Complete the entire iOS course on iTunes U
  2. Watch a GOTO Conference presentation video on Continuous Integration

Both options are money-free free, but each will consume your most precious resource: time.  We want to relatively score both of these options using each variable in the formula above.

You begin by choosing the lowest score and the highest score.  In a group, this is done typically with a predefined fibonacci (this is a useful number set primarily because it makes equal WSJF scores unlikely. Since there are only two items we are considering, we can just score with 1 and 5.

Let’s say, as a Product Owner, that although iOS products could be in your future, the company right now is making a push toward Continuous Delivery as a major lean process initiative.  Clearly, the additional value you can expect to add after the iOS course scores a 1, while the value of knowing what people mean when they voice pains in their Continuous Delivery initiative is the 5.  Remember, this isn’t about what could be the most valuable thing ever, this is about prioritizing your continuous investment in yourself.

Time Sensitivity, do the same.  It’s another clear win for an hour YouTube video. 

Career Opportunity – Maybe knowing how to code in Objective-C give you better prospects in your career.  Give the Continuous Delivery video a 1 this time.

Time Investment – the testing ground of every great idea.  It will take you several days of ongoing effort to make it through that entire iTunes U course on iOS development, especially if you really take notes, do the exercises, and learn to actually code.  The YouTube video and a follow-up conversation with someone you trust, plus a blog post about what you learned?  Let’s 4hrs.  At the end of the day though, you don’t need an actual estimate of the time you’ll spend, you just need to know what’s bigger and smaller relative to your most important options.

Now we can score!  I’ll send you an example of my own current learning goals.  Just contact me.

  1. Complete the entire iOS course on iTunes U (1+1+5)/5 = 2.4 #FAIL
  2. Watch a GOTO Conference video on Continuous Integration (5+5+1)/1 = 7 #WINNING

10 – The highest score wins. 

If you have several items, you order them from highest score to lowest.  Go watch that video and write about what you learn!  Your time is a river, keep repeating this process so that it flows beautifully and the water of insight and innovation is always fresh!

11 – Final Step: Tell people about it.

Learning is more difficult in a vacuum, because the occasional plateaus and time in the trough of disillusionment make it easy to quit once you find out how hard a new skill is.  That’s why you want an accountability partner, mentor, or community of practice leader who you trust for bouncing ideas, sharing goals, and tracking your insights.

BONUS SUDDEN DEATH ROUND

Just kidding, no sudden deaths here.  The bonus take-away from Lean that I’ll give you is the challenge to move from old ideas of quality – “no one complained about a problem” – to the idea of TOTAL QUALITY.  What if everything in your product solved pain for the user?  What if everyone involved added value to solving the user’s pain?  Quality isn’t “less than 1% crash rate”.  Quality is “I gave the right thing to solve pains, at the right time, and it changed someones life quickly and easily because their was no filler, fluff, or distractions.”

ENJOY!

 

Featured image via Liane Metzler

The Virtue of Collaborativeness

Leave a comment

This is part of a series on the key virtues of excellent Product Ownership.
The Virtue: Collaborativeness

Collaboration is, by definition, the ability to work with someone to produce or create something. This excellence, as I like to describe it to people, is the ability to “delight and inspire” a mix of engineers and artists to empathize with the end user and work together to address their pain. This also requires trusting others to do their job well to the extent of their expertise.  

If you slip into a mode where you have too little active participation in building a common understanding with your team, the outcome of their work and the pace at which it is produced will suffer. At the other end of the spectrum, micro-managing and looking over shoulders sends a clear signal of distrust. You might be able to have a nice relationship-building moment sitting with a developer and showing you care what the code does that she is staring at – just don’t overstay your welcome. You have a backlog to manage.  

Without getting overly disruptive of other people’s work, be sure to get feedback. Don’t get in people’s faces, but when you are getting coffee and one of your developers comes into the kitchen, it doesn’t hurt to genuinely care about things like: “Do you think I should be sizing any of the stories differently?” Or “Is there anything I can do to make your life easier today?” Somewhere between ignoring people or annoying them lies caring about what you produce together.

What this really requires of you is genuinely caring about the customer, the end user, and the people building the product for you. Don’t care about your product. Genuinely care about whether your developer knows who’s pain is being alleviated and why. If you don’t care, it shows. Why would anyone follow you or stay engaged in their work if you don’t believe in it? Sort that out, then find a balance that builds a great dynamic with the team.

Scrum Backlog Zombies!

Leave a comment

Product Owners – Do you really want an algorithm to take all the thought out of backlog prioritization? You do?

…
You’re fired.

Pack up your things and request an immediate transfer to a different department. It’s over. You’re a zombie worker. Purposeful prioritization is your one wildly important purpose in the role!

You MUST prioritize the inter-party flow of information between stakeholders, customers, the development team, and your ever-storied users.

You MUST prioritize the flow of disciplined experimentation as the only scientist who can connect “innovative solution” supply with “ever-evolving pain-driven-need” demand.

You MUST prioritize the flow of economic value-add with enough vision and discipline and multi-partisan politics that the agile train doesn’t come off the rails.

Oh by the way, you’re definitely not fired.

What I meant to say before was, you’ll need to light a fire under your ass because you’re insanely important. Product Ownership may not matter to SOME people, but it’s VERY important to the REST of US.

You know, if you are a Product Owner in a large company, I get it if you didn’t ask for all this power that no one fully explained to you. In fact, I’m sorry. It is serious malarky that you’ve been empowered SO MUCH but nobody will tell you until after you fail. That’s because you’re the single point of failure in a system they didn’t want, and they definitely don’t understand what to do with. They don’t know your great power or your great responsibility, how can they possibly help you?

Your boss probably hates agile.

Maybe you hate agile.

But hey, here you are, a bridge between two broken systems, prepared to be blamed as the “single neck to choke” because a ScrumMaster said so.

I’m here for you, and I’m not giving up on you. Whatever tips, tricks, or advice you may need, just reach out.

(Image credit Walking Dead)

Entrepreneurial Product Ownership

Leave a comment

As a Product Owner, is “entrepreneurial” or “innovative” in your job description?  Yeah, I thought so. But what does that even mean?

As I’ve mentioned before, the ability to ensure work is meaningful to the user-in-pain and the customer paying to resolve that pain (occasionally but not always the same person) is super important to the health and motivation of the engineers. The shorter the time between empathy and resolution, the more meaningful the work, the more likely the direct correlation with revenue, and the safer the jobs and projects of the engineers become.

The big “evil” business “side” in a large company doesn’t need any of that in order to maintain risk aversion and product agility. Cancelling a three year project before a customer saw it because a better project was two years in WAS their agility.

Congratulations on your agile transformation, but when you said “agile” you really meant lean concepts like “small batching” and “level-loading” and “systems thinking”. As a Product Owner, you must obtain a clear understanding around lean startup principles. That may shock you. Alas, the moment your team became an agile team, you became a new venture.

At scale, as a Product Owner overseeing delivery of your backlog, it is of tantamount necessity that you strengthen your relationship with your Product Manager. To the extent the Product Manager handles budget approval from the C-Suite on your behalf and builds up buy-in from your top customers, treat them like a venture capitalist with many connections in the VC/Angel community – and this is your first company. The expected return is 10X due to the extra risk. Many of them are having to let go against their will and trust that you know what you’re doing.

Within this context that you bear on your shoulders, the burden-of-proof that the budget can be trusted to the agile engines of production, you now have to proactively validate all learning about three things:

Product risk – The right thing was built to solve the pain of a large (enough) but narrowly (enough) focused group.

Market risk – The ability to build and continuously improve the viability of your product’s business model.

Customer risk – The ability to get the solution into the hands of the customer.

You are the single point of failure for information flow about your product backlog.

Project risk, as you once knew it, is gone. In fact, waterfall was the good ol’ days for the free riders and career passive observers among us. That was part of a bubble in the economy. SO long-lived that it caused no pain to investors, so you never heard it called a bubble. But the era of software-in-itself as a competitive advantage is gone. The fat shall be trimmed.

So no, you don’t have a deadline to track against but you do have the angel investments from your Product Manager(s). Also, you don’t really have “technical risk” anymore right? Come on, there isn’t much that you can’t build because most of us aren’t so imaginative that our requirements are science fiction. The risk that your estimates were wrong is so tertiary that some groups do away with it entirely.

No no no, YOU, my Product Owner friend, risk the loss of intrapreneurial “investor” confidence… the confidence that you know what you’re doing, mostly. Can good forecasting and transparency help? Sometimes. Unfortunately, some of us get promoted from T-Ball to the Majors with no notice that it even happened. We need a pocket-MBA and a time machine to make the new demands reasonable.

What can you do?

OWN your own destiny. The path to autonomy, mastery, and purpose is a purposeful pursuit of excellence in your craft.  If you don’t love agile, you may start to. If your boss hates agile, you’ll win her over. But it’s on you to make it happen. 

There are three “steps” to excellence in Product Ownership. Repeating these steps will take your abilities to the next level.

Step One: Establish Communication and Discovery Ceremonies

Agile transformations seem to fizzle at your level (the Product Owner). That’s because the Scrum ceremonies of the builders “under” you are well-established and grow from the ground up. They have become so commonplace that refusing the development team’s desire for a Sprint Retro seems just silly. The ceremonies that keep the team moving are established – the ceremonies you hold with your stakeholders, not so much. Without knowing the stakeholders and the meetings you already have with them, giving specifics here is hard. But – for whatever problem you’re having, looking outside your company. There is a vendor in the services industry that overcomes your challenge as a full-time business model. Prioritizing a longer term roadmap, creative brainstorming sessions, Lean UX workshops, Lean StartUp coaching – large companies have had the problems you’re facing for a long time. Look for a consultant, google what they offer, read blog posts, attend MeetUps. They are excited to talk about what they do. They know that they have to “out teach the competition” to be seen as the expert. Reach out to me for specifics. At the end of the day, borrow those workshop tactics and meeting agendas, get buy-in from each stakeholder, then establish a cadence for those activities.

Step Two: Pursue Cross-Functional Team(membership)

Never stop learning. Create a plan. Get a mentor or friend to share it with and if possible include it in your check-ins with your manager. As a Product Owner, you are the conduit between nearly every other function. Because the “development side” has begun fighting toward cross-functional teams, it’s critical you develop cross-functional communication skills. A simple way to get started is to ask people what they think works best about their jobs. An even more robust strategy is to list out all the job titles of the people you must successfully communicate with, check online for a job description, pick a skill or requirement and prioritize a backlog skills to learn. Should you master photoshop? No. But a few YouTube tutorials as you play with GimpShop (a free alternative) will be a real eye-opener. Remember this isn’t about becoming a jack-of-all-trades, this about mastery and excellence in your product innovation and delivery ownership role. Sharpening your ability to translate between specialists and clarify your intentions about prioritized effort IS your specialty.

Step Three: Define The Art and Science of Prioritization

I’m writing about this quite a bit else where. Check my blog posts, follow any links I gave and come up with your approach. If you need more specific answers, reach out to me.

Defect Prioritization

1 Comment

Defect Prioritization: Everything you ever wanted to know but were too afraid to admit that you needed to ask.

One of the biggest agile religious debates that seems to get people up in arms is backlog prioritization when planning has to balance known defects (especially in production) against new feature work.  Let’s dig in and find a sensible approach here.

First of all, realize that it isn’t a fun situation for developers: fixing a defect older than two weeks, even if you wrote the code yourself, is like looking at someone else’s work.  Especially if it is the cause of a problem, it hurts inside to look at it.  You wish you could re-write the whole thing because you’ve grown and learned and you’re a better developer than you were then!  I get it.  Naturally, it sucks that you can’t do that because you’d end up down a refactoring rabbit hole due to all the other code that depends on your code.  So you end up feeling like you’re adding duct tape to a hole in the hoover dam.  If you’re fixing a bug in code you’ve never seen before, its like your Product Owner told you to fix a hole in the Hoover dam, but said it in a language you don’t speak, while handing you a box of duct tape and shoving you in the opposite direction of where you need to go.  Support engineers – if they actually like what they do – are a very special breed and should be your best friend.  Get them a Snickers bar and a thank you card sometime.

Second, the “triage” work for identifying the importance of bugs (if that happens at all) in which a manual QA tester writes up a ticket and picks a “Criticality” level is a joke.  Even if you had an elaborate definition for each one, who cares?  A crash that impacts 70% of users is “critical” why?  The defect is critical to… what?  To who?  How many people?  How much money?

Now, the lazy moral high ground of newly trained agilists is to insist you should’ve never let the bugs out at all.  Six Sigma Quality baby!!!  That’s a nice thought, and a very valuable standard if you are starting a completely new project on the latest and greatest stacks.  You know, an iOS 9+ iPhone 6s or later mobile application from scratch.  Then, I do advise you to build less than you think you should, think harder about whether or not each feature is actually important, and ensure that no defect gets into the App Store. 

That isn’t most software and that isn’t the problem established software companies are grappling with while in the middle of an agile-at-scale transformation.  If are a Product Owner for 10% of an application older than three years, you definitely have defects and you definitely need a rule of thumb for what to do about them.  It isn’t your fault, but it is your responsibility.  Operating systems evolved underneath you.  Hardware was replaced.  Vendors changed.  SDKs stopped getting updated.  People changed.  Deprecations occurred.  Now you have a list 1,000 decisions to make.  In that scenario, the moral high ground “you shouldn’t have made any defects!” is lazy and unhelpful.  That’s not the reality and it provides no answer for what to do once you already have defects in production.  There’s really four approaches to consider.

1 – All About the Money:

On the one hand, calculating the ROI of every User Story then attempting to apply the same methods to your production or other leftover defects will require a pretty rigorous approach to finance, accounting, and statistics.  A simple example – if a LinkedIn share crashes every 100th time I cross-post to Twitter, what is the ROI of fixing it?  I’m not a paying customer nor is Twitter.  Should I just leave the crash and hope people don’t complain too much?  No, I don’t think anyone would suggest that.  That said, there definitely is a statistical algorithm for whether or not that crash is likely to impact my decision to become a Premium Member in the future.  But if the crash takes 11hrs to fix, test, and deploy while the data mining, analysis, etc takes 60hrs to gain a certainty of 75% – why on earth would anyone not fix the defect and move on?  Eric Reis popularized the saying “Metrics are people too” while Ash Maurya adapts this to say “Metrics are people first.”  That is to say, if you have crash count of 13, not a very actionable metric.  If you have a percentage of engaged users experiencing a crash in version 1.9.3 – you have an actionable metric, but that metric represents real people who are annoyed in real life about that crash!  Quantitative data needs to drive qualitative insight, not ever-more-complicated quantitative analysis.

On the other hand, there are important occasions when the money makes a difference.  If you have customers with a Service License Agreement or paid SAAS users threatening to leave or your actionable product metrics are moving in a scary direction on account of a defect or the perception of poor performance, the money should be the incentive you need to prioritize fixes over any new feature.  Once a customer is gone they are incredibly unlikely to come back.

2 – Actionable Product Metric: Oops

Oops!  We stopped talking about money and started talking about product metrics!  There is a good reason for that – if you prioritize the development effort that improves Acquisition, Activation, Retention, Referral & Revenue (AARRR!) then you are by default increasing the money.  ROI is not even the money question to solve, is it?  If you have a fixed team contributing to the revenue of a product, ROI variability or Gross Margin variability is what you actually want to track – as long as the costs per month to maintain and improve my product is outpaced by the growth of revenue from paying customers, the ROI is there and the Margins are there and everyone is happy!  The problem is that revenue, ROI, and Gross Margin are extremely lagging indicators of success.  They are a good indication of the stability of the performance of a company over time, which gives investors the confidence they need to keep the money there, but multi-year lagging indicators are very poor metrics for the decision-making of the teams that managing, maintaining, and improving the product.  Growth of total users or active users can be a great indication of possible network effects long-term.  Both of these long-term performance indicators are symptoms of competitive advantage.  NOT the cause.

Now we have the cart before the horse though.  If you have legacy production defects in your backlog and want to move to cohort-based split-testing, your defects are the NOISE in your SOUND.  In the example crash above, if you knew cross-posting to Twitter was an important proxy metric for Referral, the possibility of a crash is also the possibility that I don’t try to engage a second time.  If that defect existed before you began using cohort analysis and split-testing, your viral coefficient is already distorted.  So if your agile release train is making an exciting and important stop at the actionable metrics station, make sure to prioritize any defects that could distort the reliability of your pirate metrics and future experimentation.

3 – Fuzzy-Weighted Economic Value Algorithm: 

A core concept for how the backlog should be prioritize in a lean-agile environment is maximizing the flow of value-add and minimizing waste.  If you are continuously deploying, the scope of feature releases can take a back seat to actually committing to the long-term awesomeness of the product.  Of course, as Ash Maurya says, the product isn’t the product, the product is the sustainable business model – and that’s not a fixed-duration project, that’s a commitment to continuous improvement of your unique value proposition.  So in good lean-agile, at any given Program Increment planning session, you do not need to be certain that your ROI calculations are perfect or your developers will be fully allocated or your that your schedule is on track.  You have a fixed release cadence, only scope may vary.  You have a large backlog, selecting the best possible thing to build matters.  As we said above, if your revenue growth outpaces your cost growth, the ROI takes care of itself.

The Weighted Shortest Job First approach is very useful for exactly this.  Because everything else is a lagging indication of good decisions, the Relative Cost of Delay and the Relative Job Size are the most important factors in job sequencing.  Let me reiterate.  Sequence = prioritization.  Under the assumption that small legacy defects require small individual effort while large value-add features take multiple sprints to roll out, you’ll likely always fix your bugs FIRST.  Which is good.  No one likes a crappy product, no matter how much “SOCIAL!!” you add to it.  Burn your customers long enough and they will abandon you.  Every software product is replaceable if you make the pain of use greater than the pain of switching to an alternative.

Over time, three things will happen.  You’ll get to a point where the outstanding defects will require large-scale refactoring effort while your stakeholder (hopefully) get wise to the fact that a smaller improvement with more certain economic value add is more likely to get prioritized.  At that point, you have flow and hopefully rational planning and discussion will rule the day on deciding what to do next.  On that note….

4 – Politically-Intelligent Fuzzy-Weighted Economic Value Algorithm: 

If you aren’t entirely lean-agile, aka you are still mid-transformation, aka “the top” still works using their old plan-driven paradigm while somewhere down the line an agile-savvy person tries to smooth the flow of that work, you need to add something for portfolio-level politics that impact your program-level prioritization.  In this case, while you may not share it too publicly, adding more scores for which stakeholder you are pleasing should be considered.  You can then weight each of the relative scores, like proxy-voting for your stakeholders.

Yes, that means the old-school problems will be continued because you are giving the important people at the top some blank-check preferred stock when it comes to your backlog prioritization.   The unfortunate alternative is that you live in silly denial that their perception matters or that backlog prioritization is not a political question as much as an economic value you question and the people “at the top” or “in the business” continue to hate agile and second-guess every decision you make.  Concessions to a powerful VP today help earn you the trust you need in order to move prioritization to a more rational approach later.  Admit where you are, challenge it bit-by-bit, and work to improve it.

What does that look like in practice?  Hopefully there is an IT leader at the top too in your large-scale silo-heavy organization.  Hopefully that IT person or a Quality person up “at the top” can be one of the political variables in your weighting approach.  Don’t pit the CEO against the CTO as a Product Owner, that just makes you look like a chump who can’t make difficult decisions yourself.  Gain buy-in and provide enough visibility before planning sessions that no one gets blindsided by your decision to prioritize refactoring over that VP’s screams for “SOCIAL!” 

To reiterate – THE BACKLOG IS A POLITICAL ARTIFACT. 

Your solution is only partially economic or financial or social.  This is not a democracy.  Don’t go asking for votes.  It really isn’t a democratic republic, either.  And it is definitely isn’t just user story meritocracy.  Slapping a relative business value tag and sorting is begging for failure and distrust at your methods.  It looks lazy and it is.  You have to influence the right people to make the right decisions and that takes work.  If you’re lucky, its close to a full-time job and you have job security now.  Congratulations.  But seriously go fix those bugs.  They’re lame.

The Virtue of Scientific Discipline

Leave a comment

This is part of a series on the key virtues of excellent Product Ownership.

The Virtue: Scientific Discipline 

I admit, this one combines a few qualities that make someone’s approach to problem solving incredible. The excellence of scientific product innovation requires the ability to identify and challenge assumptions in isolation so that purposeful experimentation and learning can occur. To succeed at disrupting a market, there is a permanent restlessness and curiosity, a willingness to challenge the status quo. The discipline part requires an understanding of what to measure, how to measure it, and the patience to consistently track and communicate your findings.

The vice of deficiency here is a total lack of experimentation. Say “no” to 99% of requests that don’t fit your vision or serve the longer term goal, absolutely; but if you say “no” to 100% of ideas that come your way, focus on locking things down and playing it safe, you’ll destroy any chance of innovation and your customers will abandon you. As Product Owner, it’s assumed that you are controlling a continuous stream of changes. Passively following an original plan or passively fulfilling stakeholder requests is a lack of experimentation of your own. If you don’t insist on tracking the results of their ideas, you’re also just plain unscientific. Empirical process control (Scrum) implies learning through purposeful experimentation. As the Product Owner, your laboratory is the product-market fit and your target result is the sustainable viability of your (Product) business model.

Of course, the vice of excess here is uncontrolled chaos. Drastic changes without rhyme or reason do not lead to adaptation. Evolution takes the discipline to kill tiny bad ideas as they fail and build on the successes. In Scrum this is an unfortunate use of “super-epics” like “LETS DO SOCIAL!!” Adding 7 social networks at once to a product is the undisciplined throwing-spaghetti-at-the-wall chaos I’m talking about here, and it is inevitable when you separate market planning from development planning. As soon as the developer don’t seem overwhelmed by the size of the backlog, stakeholder start feature-stuffing so they don’t feel like agile means “paying people to sit around”.

So the virtue in the middle that is absolutely essential as a Product Owner – whether you are an entrepreneur with a 5-person Scrum team or you are in the middle of a 5,000-strong software-at-scale enterprise – is scientific discipline feast or famine, insist on controlled experimentation not chaos. Insist on purposeful validation of each hypothesis, not hand-wavey assumptions. Insist on actionable metrics and clear articulation and confirmation on whether the product is progressing correctly.

Because you are the single point of failure for information flow, only you can courageously take a stand before things are out of hand. Stay disciplined and rational, but enjoy creative experimentation.