Blog SEO: 5 Simple Techniques to Start Doing Now

July 12, 20161 Comment

1 – Easy-to-Read urls

Use urls that indicate the subject of each post, not numbers. Deep-linking (linking straight to a page) may be bad for security on some portals or throw off your conversion funnel analytics in commerce, but a blog should represent an interrelated series of ideas.

Pro Tip: This probably makes your urls so long that they are hard to properly Tweet. In Social Media, use Buffer, Hootsuite, or SproutSocial to shorten the url and auto-schedule the timing of your post.

2 – Link to Your Old Posts

Anytime you write a new post, think of how it relates to at least one previous post you’ve written, and link to the previous post within the new post. This means you need to know your blog contents. It is nice that a Blog can let you explore new topics on the tangents of your profession, but if you can’t create some sort of emergent cohesion, no reader and no bot or spider will do it for you.

Pro Tip – If you are a member of a team that manage a blog with a TON of posts, read a new post from months or years ago each day. React to it, link to it, write about it.

3 – Link to Your New Post

Anytime you add a new post, find an old post that is related and insert a link to it. The easiest way to do this, naturally, is to use the post you linked in #2. It will be better for your readers if there is a logical place to include it within the content of the previous post, but adding a “Recommended reading” section at the end of a post can help as well.

4 – Tags and Images

The easy thing here is to make sure you start naming any images so that they have meaning independent of the image. Using headers to organize the content of a post should be a no-brainer as well. If you’re bootstrapping and crunched for time – its never too late to start doing it better going forward with more discipline. If you’re a big business with a massive site, an SEO consultant who can dive into your code is a useful ally. What may not realize is most SEO experts will give you a fair amount of information for free. Just ask!

5 – Have Fun!

Okay but seriously, the most important thing that will improve your SEO is to create content you care about. Take pride in the topic. Take the discussion with you into the real world. If the blog is an authentic “shadow” of who you are or who your organization strives to be, people will find it interesting. Find interest groups on Twitter and Snapchat and LinkedIn – then CARE. If you don’t care about your craft, no one will. If you don’t love blogging about your craft, no one will care about your blog.

Why? Why? Why? Why? Why? (5 of them)

July 11, 2016Leave a comment

As I described this weekend on Snapchat using the example of my house, Root Cause analysis – or asking the 5 why’s – is essential to lean scalability and a thriving culture of relentless improvement. In complex systems thinking, you must see problems (lack of quality, decreasing sales) as a symptom of the system as a whole.

I bought my first home in November in a north suburb of Chicago. Naturally, that means finding little issues here and there as I go. It was originally built in the 1950’s and I knew it was in a neighborhood that had flooded a bit a few years back. I was excited from the first tour to see a fantastic dual sump pump system in the finished basement.

Unfortunately: The previous homeowner had treated the symptom, not the problem.

A house (like a software product or tool in its context) is part of a complex adaptive system. It is inserted into a biological ecosystem, and integrated with multiple networks (cable, electrical, plumbing, roads). What the previous homeowner did is a mistake many of us make when it comes to eCommerce, marketing campaigns, enterprise software, you name it – the symptom was treated in the context of a system in homeostasis without changing the ability of the system to adapt to deal with a chaotic event.

SO – my basement has flooded, just a little, three times this spring.

Enter the “5 Why’s” Analysis:

1- Why is the carpet wet in the basement? The sump pump didn’t pump out the water quickly enough. If I were to continue to treat the symptom, I might upgrade the sump pump, which is expensive and might not work (and what we tend to do in the workplace).

2- Why didn’t the sump pump handle it? There was too much water around the house, building up hydrostatic pressure. The second time we had flooding, I noticed that the water appeared to have come in from all sides, not from the sump pump reservoir overflowing. (i.e. without “going to the place” I might have continued to blame the sump pump)

3- Why was there too much water around the foundation? I have a negative grade, meaning my lawn on one side slopes slightly toward the house. Again, easy to blame that and spend a fortune on a re-grading (legacy system migration anyone?) but I had the joy of really, really “going to the place” and spent an 1hr flash-flood storm OUTSIDE, managing the flow of water in non-normal conditions. After all, the yard may slope slightly, but there are 4 basement egresses with drains in the bottom that run to the sump pump…

4- Why did so much water flow to the basement window wells that the drains couldn’t get the water to the sump pump quickly enough? (notice that we are finally getting somewhere in our root cause analysis!) Once I was out in the storm, it was clear that the rain on its own was not the issue: despite having cleaned out my gutters hours before the storm, the winds that blew the storm in kicked lots of new leaves onto my roof, blocked the gutter, and a waterfall of water came off the gutter onto the negative grade instead of going down the downspout system that drains the water in a safer direction. What I also noticed was that the sidewalk gradually filled with water from the downspout nicely – meaning there was a certain amount of in-yard flooding that could occur before the water would pour unchecked into my window wells. (note, I could invest in LeafGuard or something as part of a total replacement of my gutters, but have we really found the root cause?)
5- Why doesn’t the system (my house in its context) handle a the flow of water in that quantity? Now we’re down to business. The soil has a high clay content and hasn’t been aerated recently. The previous homeowner removed bushes on that side of the house but not the roots and stumps. The downspouts eject water 3 feet from the house, but into an area of the lawn that can be easily filled with water that will then flow back to the egresses.

Root cause – The system is not prepared to handle the flow of unwanted inputs under non-normal conditions.

Oops, I slipped into discussing emergent leadership in complex adaptive systems. What I meant was, nobody had bothered to look at what happens to the flow of excess water in flash-flood conditions. Just like I frequently see no one planning for “storms” in their agile or devops culture, their social media presence, or omnichannel efforts.

To round out the story, now that we have a ROOT CAUSE. I can come up with a….

Solution – Create a sub-system that encourage adaptation to non-normal systemic conditions.

Sorry, I did it again. But you really can’t tack on a new tool or process if you have underlying cultural factors that need to be addressed. For my house, the answer is simple, add a French Drain system that will handle excess water during a flash flood.

Now, with my years in custom app development consulting, the parallel is really quite striking. Investment in a bigger pump, a total re-grading, or new and improved gutters would have been an expensive way to deal with emergent properties of the system without helping it adapt properly to non-normal stress. The french drain and dry well implementation I have started will require some hard work (i’m digging it by hand!) but potentially no cash (I already have more river stones than I know what to do with).

I’ve discussed how this applies to agile or DevOps transformations that don’t address cultural problems.
I’ve shown how bad investments in software happen due to a lack of understanding of the root cause.
Look for more on how this applies to eCommerce and Marketing on the way!

“Digital Transformation” Beyond the Hype

June 16, 2016June 16, 2016Leave a comment

Living in the tech implementation space, the most exciting moment in a “Digital Transformation” for me is near the beginning of any project or initiative. It’s the moment someone who is integral to operations finally opens the 5″ binder that has been sitting on their desk untouched; and finding the information contained in the binder is fundamental to all company revenue. Or it’s the moment the battle book comes out from the sales VP and the ensuing conversation shows – to the collective surprise of the rest of the participants – there is no standardized pricing, and no tracking of how prices get negotiated. Or it’s that moment I find a clipboard and start asking about the origin, purpose, and destination of each form.

That’s the juicy part.

On factory tours, in “working sessions” and project kickoffs, or detailing the business logic for an implementation, this is the moment my work is no longer just “make it prettier and online” and the conversation starts driving an actual transformation – of the workplace experience and overarching business model – using “digital” technology.

The reason this moment is so exciting for me happens to also the answer to the question I’ve heard at more than one barbecue from an older neighbor – “And what exactly are you transforming?”

I think that’s a great question in retrospect.

What we are actually transforming is information.

We take the information created purely for human consumption;
We make it easy for “computers” to read it efficiently instead of humans;
We use “computers” to present the information more quickly to more people.

It’s that simple.

Pragmatically, that’s the process that takes the hard-to-maintain spreadsheets that become binders or clipboard papers and transforms them into intuitive digital interfaces (they are also “online and pretty”). By simplifying all of that socially complex and context-dependent information into a flat table a computer can understand, you become free to add all of the social and contextual perspective in multiple ways later (channel and audience specific) instead of just one way forever (in that binder).

Your ROI is Total BS

June 16, 20164 Comments

ROI is meaningless. GP% is meaningless. Signups. Clicks. Views. None of these tell you anything meaningful or actionable. None of this ensures survival. In fact, it is through sheer mass that some enterprises survive. It is the churn of hype cycles and perceived value that keep new customers fooled. But it is definitely not sustainable. Big investments end with big blunders that result in mass layoffs and enormous bankruptcies. The name is the only thing that survives. Is that the company you set out to build? No.

Let’s assume you are a software company selling enterprise SAAS. Your entire company is the value stream. The ongoing operating costs are less than ongoing revenue. Investing in the sustainability of your model of economic value creation and capture is every dollar you spend. Those dollars, little by little, react with the market either creating or negating value creation.

The problem is that most enterprises work from the assumption that large investments equate with economies of scale. While this may be true of investment in automated manufacturing there are no economies of scale in software development. It is the individual knowledge workers that create innovative software. The velocity with which you can adapt as a system combined with superior understanding of problem-solution fit in the market is the key to competitive advantage.

The question of how to invest should be quite simple when you are a large company that has revenue growing at the same rate as costs – small investments per opportunity with maximum ability to correct an incorrect investment.

That is enterprise agility.

Enterprise Agility is the speed at which an incorrect decision is recognized corrected. The smaller the investment decision, the faster the return is known. Lean trims the excess weight, off-balance feedback, and poor technique that undermine agility. The effective flow of information across the creative process of knowledge workers is essential.

This is where you must realize that unless you layoff staff, you’re investing the same amount continuously. The ROI of a project is as meaningless as the ROI of a developer day. The input of resources is relatively static, maximizing the value stream as a system is essential.

This is why the a right-place/right-time, brilliant, socially-savvy entrepreneur-engineer is the most agile and lean possibility: perfect and instantaneous knowledge-sharing internally (in the brain), distinct competitive advantage through the extremely unique skill set (s)he has grown to master. That is the sprinter that you want your Superorganism to become. In the right place, at the right time, with the correct knowledge and materials, with instantaneous information flow across the value stream.

So if ROI is meaningless to decisions (because we are paying for individual pursuit of knowledge-worker-creativity regardless of rate of return), how do we possibly make rational financial decisions about innovation, discovery and exploitation of economics rents? In fact, lean manufacturing has studied this for decades. When the rate of investment (the cost of production) is held constant, prioritization of economic value added rather than expected rate of return should be our focus. In a zero-sum competitive game with uncertain returns and asymmetrical information, the time between investment and value capture is the only meaningful variable we can impact. While cost of delay versus product lifetime return on investment may be more difficult to understand when looking at Toyota and the Prius, this is easy to see with Software as a Service, because the continuous addition of value in exchange for subscription-based fees creates two roughly stable lines. The only meaningful way to improve investment is to exploit information asymmetry more effectively than your competition. Since you are investing the same amount continuously, you must minimize the cost of delay of value capture.

To put it another way: In a system with continuous investment, only the opportunity cost incurred due to delaying an investment matters. This is not first-mover advantage at the new product-market level, this most-effective exploiter of innovation as an a competitive advantage. This requires a shift to systems thinking and investment in strength of culture. Money is not your scarcest resource. Brilliance-time (that you’re paying rent for daily) is your scarcest resource. To maximize value capture, you must maximize the time spent in a state of market information asymmetry. At the current pace of innovation and obsolescence, the only way to maximize value capture is to minimize cost of delay due to incorrect prioritization.

This implies three goals:

1 – Minimize the impact of an incorrect investment of system-brilliance-time by reducing size of each commitment

2 – Increase the adaptiveness of the system to maximize throughout and future adaptiveness

3 – Minimize the time it takes to receive feedback (primarily through analytics) from the market

4 – Make appropriate risk-taking and experimentation a normal part of every creative process

Breakthrough Agility

June 3, 2016June 3, 2016Leave 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

May 28, 2016Leave 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:

Queue – Understand what to do
Setup – Get the necessary “resources” ready
Run – Complete the goal
Wait – Look for feedback on success/failure
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:

Waiting for input (information or resources)
Over-production (doing something or making something no one used)
Rejects or Defects (doing the wrong thing, or doing the thing wrong)
Motion (unnecessary movement, like manually turning a Word doc into an Excel spreadsheet every week)
Over-Processing (anything you do in which you “reinvent the wheel” each time)
Inventory (any pile of information or resources, before or after you add value, that sits untouched for any period of time)
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:

Complete the entire iOS course on iTunes U
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.

Complete the entire iOS course on iTunes U (1+1+5)/5 = 2.4 #FAIL
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

Defect Prioritization

May 19, 20161 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 Leader I Am

May 17, 2016Leave a comment

The foundation of the leader I am today isn’t listed on my resume. Those formative moments don’t really belong in the official documentation of pursuing autonomy, mastery, and purpose through software product innovation.

My training in leadership did not begin during my MBA or any of my agile certifications. It began by watching my father’s servant-leadership as a minister and the mentorship of my high school English literature and composition teacher.

There was a day that came when Mrs. Bernsen, my high school English Lit teacher, gave the disengaged classroom an admonition to inspire our focus as we read and discussed selections from Ralph Waldo Emerson’s “Self Reliance”. Who we choose to be today sets us on a path for who we will become in 5 years. I took that idea very seriously. I studied “Self Reliance” several times and began teaching its ideas to anyone who would listen. I had decided I was a philosopher who loved teaching people to strive for introspection and self-ownership of their journey in life. My career has been expanding on that theme ever since.

As 1st chair trumpet in band, I learned the power of servant leadership and inspiring people to the prestige they wanted. I played third part because I was naturally the loudest and it made the whole band richer. I made sure everyone who wanted one got a chance at a solo that they would succeed at. Senior year we had a particularly challenging piece and not enough trumpet players to effectively make it beautiful, so I noted out with my second chair how he and I would trade off between 1st and 3rd part, ensuring the high notes were never missed while the low notes were the right strength.

As a Youth Minister in college I found the power of Accountability Partnership in learning plans. There is truly to many virtues and too much knowledge in life to tackle at once. Whether a mentor, teacher, or friend, finding someone to share your personal development goals with, and being someone who can ask about progress, is essential. Saying it out loud makes goals more realistic and personally expressing them to someone simplifies the ability to prioritize your priorities.

As an assistant manager in retail and in a restaurant after completing my philosophy degree, I learned the importance of being the janitor. Clean up the messes, socially and physically, that your team can’t get to so that their flow isn’t interrupted and the customer is happy. You show up at 2am to unload the new stock so someone else won’t have to and you run the reports and call the customers no one else wants to call.

Yesterday I was asked to share a story that exemplifies my leadership style. I shared a simple story – I recently noticed a group looking a little lost because there were no meeting rooms were available and they had a conference call. I gave them my office. Their work and that customer were important than my comfort. I worked in the lobby.

All of these moments stay vibrant in my mind, as the milestones of how I became a leader today. Most important though is the example of my dad, which laid the foundation for how I view people in need of guidance, listening more than teaching, and serving where no one else wants to go.

So when you ask me about the leader I am today in the software space, it centers around four goals, built off the foundation described above, and countless other tiny moments along the way.

I use workshops and one on ones to build the confidence and vision of my team so they can pursue their own sense of meaning and purpose at work – I can only help build the bridge between company goals and values to personal sense of prestige and love of your work.

I use learning plans and information sessions to help my team members pursue their sense of mastery in their craft. I am constantly learning what they want to learn so they have someone to meaningfully converse with, while playing the role of accountability partner much more then mentor. I don’t lecture or train so much as play the role of knowledge janitor, cleaning up the chaos of possible theories, tactics, and practices, finding answers for people and resources and thinking a few extra steps ahead about how we can grow.

I am an advocate on their behalf when political games are in the way of their autonomy, while challenging them to become more cross-functional, more collaborative, and better at self-advocacy. I want my people to be leaders who are better at defining their own processes and taking pride in their work because they trust I can challenge them. The most important trait of a leader is gaining trust by proving that I have their back.

Scrum Backlog Prioritization

May 14, 2016Leave a comment

“Portfolio management is the art and science of making decisions about investment mix and policy, matching investments to objectives, asset allocation for individuals and institutions, and balancing risk against performance.” – Investopedia

How do you manage your backlog? The strategists at the top are often accustomed to trusting their gut, while the engineers below insist on absolute scientific certainty. Handing priorities down that game of telephone is a circus side-show of bull whip effect and sociopolitical contract theory.

Not that it doesn’t work out just fine….

Meanwhile, accountants and financial analysts, with the help of algorithms, benchmarking, and actuaries, have been tracking the present value of an asset, mid-investment, with all risks taken into account for a VERY LONG TIME.

The real question is, do you need all that certainty? Should you be focusing on human interaction and the existential plight more? I guess that’s a separate discussion…

I mean, at one extreme, do you care about your customers so much that you feel an ethical duty to fix every little bug no matter how much it costs you, your employees, and the families they feed?

At the other extreme, do you love churning out features so much you don’t care how many of those features aren’t wanted or how unsustainable your product has become?

No, I assume neither of those are you (I hope). Instead, you are trying desperately to strike a sensible balance that lets you sleep at night while feeling good you pleased a small group with their favorite feature. You’re really in the business of political and emotional backlog prioritization.

I want to let you know that I’m okay with that. Relationships and society and worth building. That said, when you are the bridge between the c-suite and several thousand staff member salaries, you may want to find ways to think harder about whether or not you are building the right thing, at the right time, for the right reason.

Thus, I will give you some science on backlog prioritization, but I wanted to let you know that I completely understand where you are with your current methods.

The Lost Product Owner

May 14, 2016May 14, 2016Leave a comment

The Lost Product Owner

At scale, the “Hero-Scrum” paradigm falls apart. A product becomes too large for one team, then the number of teams becomes to large for the Product Owner & CEO model to work. A company working toward agile transformation could slowly restructure toward mini-CEOs; but the truth is, the organizational switching costs are too high to make this a realistic option. Be honest – those that own the customer relationships and those that own the technical communication are, respectively, too specialized – and great at their jobs – to start mashing them together as peers.

That said, I see a clear skew in agile transformation consulting and especially entry-level Scrum training toward protecting the team against the more powerful Product Owner. While this may be a tactical prejudice when the role is played by your boss, my first-hand experience has been the opposite. In scaled transformations, the more likely scenario is that Business Analysts, Project Managers, Jr. Product Managers, Quality Assurance Analysts, or Support Engineers of the organization are asked to rise to the occasion and somehow, instantly and powerfully, lead a team to greater autonomy, mastery, and purpose.

{inspirational anthem plays in here}

Let’s be real.

The two fundamental hero images intrinsic in most Scrum courses – the ever-vigilant, time-protective ScrumMaster and available-part-time, drunk-with-power Product Owner – is meaningless in the more complex patterns of large organizations.

After studying LESS, SAFe, and Lean Enterprise theory, while speaking to representatives or directly working with several dozen organizations, it is clear that there are enough job title “Product Owners” that more attention to the profession (in separate consideration from the role) is a worthwhile pursuit.

Although I initially wanted to pursue the shock value of entitling my first book AGILE IS DEAD: HOW TO GET WHAT YOU MEANT YOU WANTED – it is plain to me that the audience for that book is too poorly defined, the pain is therefore not shared by the entire audience, and the text would be a fantastic (agile) train wreck.

Instead, I can see there is a compelling need to teach the lessons many of us learn the hard way then become agile coaches and lose touch with. There is a very large guild of professional Product Owners that need hands-on tactics for not only how but why specific practices work well in an agile, lean, scrum setting (as part of a larger enterprise). Amazingly, many of the hardest questions for running agile trains have analogs with well-established practices in professions and industries so antithetical to innovative software development that we all collectively forgot to look (and our executives understandably would never pay the handful of thought leaders who were looking to come give us a PhD in the topic).

So be on the lookout for the table of contents, the rough-draft blog posts, and the invites to MeetUps and workshops. I’d love to hear from you on the topic in advance of those things – so reach out to me at andrewthomaskeenermba@gmail.com

Photo via Jaxon Stevens