11 Steps to Revolutionize Your Career

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

Defect Prioritization

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.

Scrum Backlog Prioritization

“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.

Winning Product Ownership Tactics

Editorial note: My blog’s ScrumMaster let me know that this post was a super-epic with poorly-defined target user personas, so I will decompose this into more actionable User Stories.  I’m leaving this draft in place because I want my Product Owner followers to know that it’s okay to admit you didn’t size or prioritize things right the first time…be genuine.

So now you’re all agile…

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.

So here are the top three winning tactics that can help mid-senior managers and individual contributors succeed.


#1 – Startup Principles are Worth Your Time:

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”.  As a Product Owner what you really must have is lean startup principles.  The moment your team became an agile team, you became a new venture.  You now have to proactively validate all learning about three things:

  1. Product risk – The right thing was built to solve the pain of large (enough) but narrowly (enough) focused group.
  2. Market risk – The ability to build and continuously improve the viability of your product’s business model.
  3. Customer risk – The ability to get the solution into the hands of the customer.

Project risk – as you once knew it – is gone.  You don’t have a deadline to track against, you have angel investments from your Product Manager(s).  You don’t have technical risk that your estimates were wrong, you risk the loss of “investor” (c-suite, VPs) confidence that you know what you’re doing.  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. 

Product Owners – strengthen your relationship with your Product Manager like they are the venture capitalist and this is your first company.  The expected return is 10X due to the risk.  Many of them are having to let go against their will and trust that you know what you’re doing. 

Key skills to learnThe Lean Canvas, Innovation Accounting, Validated Learning


#2 – Everything is Marketing:

There is a java team, and a product management team, and an inbound sales team.  Marketing is not a department.  In a large company, yes, there is a corporate group in charge of advertising, branding, messaging, and copy.  As a Product Owner, embrace the idea that the marketing team is only 1% of the marketing the company does.  Everything is marketing – and you just became a sales(wo)man.  Every time you let a critical defect through and an engineer complains to their spouse and their spouse bad-mouths the company to their friends at a cocktail party – that’s marketing.  The world is a small town.  What you do matters and nothing is in the shadows.

Treat memos like Tweets with a million followers.  Fake your own notoriety if you need to.  As it turns out, you are uniquely positioned to make an enormous difference in how effectively your team meets the needs of customers.  Luckily, you don’t have to just make that stuff up from scratch!  Other people at other companies in roles you never thought to cross-pollinate against have ESSENTIAL skills that are PROVEN to work.  Decades old.  Seriously.  And most of them give that training away just to get you to spread the word!

Key skills to learn:

  1. For Roadmap / Release Planning – Talk to a Custom App Dev guy.  I can make intros if you like.  Most of them are so desperate for attention, you could make up a fake product and string them along for months.  Anyway.  The good ones do Story Mapping and MVP scope for FREE as PRE-SALES.  Lucky you – you already have a product manager to building software for!  You still need to be consultative to ensure collaboration and rational planning occurs.  Same advice as your personal life.  Date your spouse.  Start the courtship over again occasionally.  Things have changed, don’t act like you’ve memorized everything and communication can stop!
  2. For Stakeholder Alignment – Study the super hot topic of starting your own company.  You’ll be glad you did.  On ramps.  Assumption mapping.  Balanced scorecards.
  3. For Sprint Planning – Its a solution pitch.  PLEASE have an agenda.  PLEASE gain all necessary information and buy-in for prioritization prior to involving your developers.  Want an example?  Google “SAP Digital Transformation” and you’ll see that they have an example solution pitch for every industry.  This isn’t new territory you’re exploring, just a new town with a new bar but your old friends came with you.e
  4. Sprint Reviews – There is an art to the tell-show-tell demonstration.  Engineers and engineer leaders can be especially bad at this (and I’ve learned from plenty of terrible webinars as well).  The attitude “you paid me to build it, look its right here, no questions?  great….” is going to erode whatever influence you aspire to have.  Tell your stakeholders what you accomplished.  You know, business goals.  Product Pirate Metrics.  Tell them why it matters.  You know, to revenue and the sustainability of the business as a whole.  Give them numbers if you know them. Then anchor your demo against a pre-defined roadmap.  Lead feedback as you go with open ended questions.  Follow the poll / show of hands, individual follow-up routine.  Most importantly, this means taking it seriously enough to prepare in advance.  Everything is marketing!
  5. Sprint Retros – Until you start making falsifiable hypotheses, you have no experiments.  Without controlled changes to variables, you are not engaging in empirical process control.  You’d be amazed what a 4th grade poster about the Scientific Method could do for your team.  Test at least two assumptions “changing X in the product will influence Y positively” and “changing practice A as developers will impact outcome B as a team”.  There is no learning without defining what a successful outcome is prior to conducting the experiment.

#3 – Show Your Work (Too):

No really, make a scene.  Draw a picture.  Use a kanban board on your wall.  Write haikus.  Whatever you do, show it off in progress.  Disappearing to document things makes you irrelevant.  Show people what you do, how you do it, and why you do it – aspire to be like the great chefs.  You might even realize that people actually care how the sausage is made.

The best way to do this is to teach others.  The only way to build cross-functional teams in an ultra-specialized environment is to show people how much it benefits them to become cross-functional team-mates. 

If you don’t have time (you think) for reading anything intense, just pick up some Austin Kleon.  Savor it slowly.  Sip it.  Like egg nog.   Then tell people the compelling secret to the best homemade sausage anyone every made Tuscan soup with (metaphorically, of course).

That’s Solutioning!

That’s Solutioning!

“Pain-Driven Design” is a great name for the discipline required to build the right thing rather than building the wrong thing the right way. Laura Klein defines this methodology in her book UX For Lean Startups, which you should add to your reading list.  “Pain-Driven Design” captures perfectly the heart of how product innovation needs to proceed when following the principles of the Lean Startup movement. Be forewarned, it is simple to understand but requires enormous discipline.  I have seen it done very poorly or completely disregarded by dozens of companies of all sizes. 

The steps are:

  1. Validate the Person – Be specific about the person you are planning to help (as an archetype and anecdote for a sufficiently large audience of people with behavioral patterns in common).
  2. Validate the Problem – Understand the pain experienced by the person in step one.  Listen to them.  Watch them.  Learn from them.  If you already have a product, learn what they hate about it.  If they use your competitor’s product, learn what is imperfect about the way it solves pain for the person.
  3. Hypothesize the Solution – Now you think up a solution.  Once you have a specific person to empathize with, communicate with, and build a relationship with (as a representative of a group called a “target market”) you can truly understand their pain and address that pain.
  4. Validate the Hypothesis

Of course, I entitled this post “That’s Solutioning!” so let’s start over at the problem phase.  The reason most product innovators fail at solving pains is that they are too busy solutioning to notice all the pains in the first place!  While facilitating groups in enterprise software customization, I saw this all the time.  The discipline required to truly analyze the pains and painful inefficiencies locked away in a workflow – physical or virtual, while shopping or at home or on the job – is tremendous when we are all so excited to get our ideas out there!  I had a colleague who could jovially point right at someone and say “That’s Solutioning!” to keep the group on track.

Obviously (in retrospect), when I wrote about my perfect agile processI glossed over the critical difference it makes to empathize with a real person to understand their pain.  This is the test every “idea” in the Idea Backlog needs to pass prior to validating hypotheses, experimenting, or developing anything. 

It was nice to see I’m not alone in thinking this way:

The vast majority of time I talk to entrepreneurs, they present me with solutions rather than problems.  They say things like, “I want to add comments to my product,” not “My users don’t have any way to communicate with one another, and that’s affecting their engagement with my product.”

By rephrasing the problem from your user’s point of view, you help yourself understand exactly what you are trying to do before you figure out how to do it.

– Via UX for Lean Startups by Laura Klein

This is the part of Product Ownership – more specifically, backlog grooming, prioritization, and decomposition – that ought to happen prior to Sprint Planning.  This is part of the “half her time with stakeholders” that should occur. It should be a significant amount of effort ensuring the market risk of building the wrong thing is overcome prior to mitigating the technical risk of the team’s ability to build the feature or the project risk of aligning resources and timing.

Here’s how to know an idea, an epic, or a user story has failed the Pain-Driven Design process:

  • If I say my target user is “women with an iPhone” then I’m not being specific enough.
  • If I state my solution without a problem then I’m not empathizing enough.
  • If I build a feature without empathizing with a person, my work is meaningless and my solution cannot be properly validated or a source of disciplined learning.

Imagine a bridge.  Everyone else who read this probably imagined a slightly different bridge.  What you most likely did not do is imagine a person who experiences pain crossing a river.  However elaborate your imagined bridge was, however perfect your engineering certainty about its development you may be, however robust your process for ensuring timeline and budget – that bridge is meaningless on its own.  That is the essence of solutioning: a decontextualized answer.

Do this instead.  Imagine a mid-twenties mother of one on the prairie in Kansas during the 1870’s.  Imagine a stream, only two feet wide but ice cold.  She jumps over this stream on her way to town, holding her child, husband by her side, every Sunday.  As the child grows and becomes heavier, jumping over the stream becomes more painful.

Now you have context.  Now you have a User Narrative and a person to empathize with.  There is a real pain that you can solve.  You can write a meaningful user story in-context: “As a mother on the prairie, I want a foot-bridge I can cross on the way to town because I’m starting to experience back pain that might hurt my ability to support my family’s health and well-being.”

Contrast that with an eCommerce executive yelling “We need SOCIAL!”

Don’t be that guy.

 
Photo via Kevin Sequeira

Measuring What Matters to Innovation

Competing on Innovation

The rate of technological innovation and adoption has accelerated to a level that would have been impossible to imagine centuries ago. As such, an amazing number of startups have been able to succeed from strategic position based on niche-market differentiation and a culture of passionate innovators.

Established – and well-funded – large enterprises have taken note. Adoption, disruption, and even disappointment and abandonment of products are forcing every company to tackle what cloud computing, mobile, and IoT mean for their categories.

Every company is trying to become innovative, because we are all competing based on technological innovation.

Unfortunately, building a sustainable competitive advantage around culture of innovation is far more complex than previous strategic positioning was. Nash equilibriums a few decades ago could be easily resolved with a few long-term commitments that ensured indirect competition and margins for all major players. Innovation could actually be stifled – purposefully – by industry oligarchs to minimize the risk of new entrants. The rate of innovation today has made this control impossible, to the benefit of the consumer.

However, building a culture of innovation requires an entire new way to structure the organization and reinforce its behaviors. This is made even more challenging by the abundance of data available that was inaccessible before. Measuring metrics is the formalization of what decisions are worthy of notice. Thus, to understand what to measure, a leader must know not only how to measure a metric but also why the metric matters to the achievement of long-term goals.

To explore this, I’ve been discussing the connection between individual motivation and the company’s goals as a Minimum Viable Superorganism:

‘Selfish individuals pursuing shared goals (arising from shared underlying incentives), held together by a Prestige Economy which consists of two activities: (1) seeking status by attempting to advance the superorganism’s goals, and (2) celebrating (i.e., sucking up to) those who deserve it.’

The executive and visionary of the company must be the purposeful “mind” leading the activity of the superorganism. The relationship between employee motivation and company outcomes rely on this Prestige Economy, so leading a company means guiding this economy.

Naturally, it easiest for me to discuss this in terms of scaling agile or scrum, or technological innovation in start-ups versus large established enterprises. Discussing each, if you are hoping for very specific metrics for you company, will take the rest of my life so I will leave those conversations to a per-company basis. However, the fundamental issue confusing the connection between innovative teams and enterprise-level accounting metrics is the virtually insane forgetting of what has truly changed in our new and rapidly accelerating tech-adoptive society.


 

Market Risk vs Technical Risk

If you recall the example of the terrible metric (for innovation-based companies) “allocable resource utilization” we saw the well-established, consistent distribution – i.e. strategic trade-off – between utilization and responsiveness.

If you imagine one very capable engineer you’ll find:

  • Demands arrive to the employee at a variable rate.
  • Work is accomplished at a variable rate.
  • There is one worker.
  • The possible queue of demands is potentially infinite.

This type of queue is an M/M/1/ ∞ queue.

Whether the “1” here is a server, an interstate, a mobile developer, or a 1990’s movie hacker’s CPU, increased utilization of total potential results in rapidly-accelerating diminished returns as utilization reaches 100%. Likewise, you can occasionally “overclock” with appropriate support and recovery, but constant over-use results in chronically poor responsiveness to demands, a pile up of unmet requests, and finally, a CRASH.

HOWEVER, competing on innovation requires additional variables for our M/M/1/ ∞ queue because it treats “requests” as a discrete abstract entity. It accounts for the possibility, because it is a Poisson distribution, of requests not being the same size or difficulty – technical risk – by stating that work is accomplished at a variable rate.

What the M/M/1/ ∞ queue fails to account for is whether or not the request was the correct request. In the case of a server handling API requests, we could assume the incorrect initial request probability is zero if we believe retrieving unwanted data is the failure intuitive front end or simply user error (the API and the server is not the guilty party). If we are imagining a highway over an extended period of time, drivers who intended to take a different route and got on the highway by mistake are virtually an outlier, and an even less noticeable percentage behave in a way that would impact the flow of traffic.

In technological innovation and the development of any given software product, the risk that the request was the correct request at the time it was made and still the correct request by the time it has been fulfilled is EXTREMELY HIGH. The variable that prioritizes responsiveness over utilization in technological innovation is Market Risk.

After all, when we say “competing on innovation” what we really mean is “responding the fastest to disruptive market shifts while also creating market disruption or new demand and adapting quickly enough to capture value profitably”.

We don’t say the latter, of course, because it isn’t as sexy.

The reality is that a culture of innovation requires a few things that run counter to the leadership methods of old school consulting or manufacturing organizations. Don’t go on a request for quantifiable metrics on these, but an innovation culture requires things like:

  • Excess allocable brilliance
  • Willingness and aptitude for adaptation
  • Vigilant feedback-seeking
  • Permanent restlessness

The greatest risk of any innovation-based company is not the technical risk of learning to implement what was promised or the project risk of time-to-market or delayed advertising campaigns. The primary risk when competing on innovation is the market risk that, for any new product:

  1. The market knew what to demand
  2. Supply correctly met that demand
  3. The product still met a need by the time it went to market

In the App Store alone there are thousands of new apps per day. The market risk not only for a software product in this one market is unprecedentedly high, likewise shifting immense market risk to every feature added and every update released to your company’s increasingly less loyal consumer base. That is why Scrum works sprint-based, with increments that should always require less than a single sprint (2 weeks, ideally) of development team effort – not to mitigate project or technical risk, to mitigate the market risk that the end users or stakeholder knew what they actually wanted, knew the impact on the overall product, properly communicated it, and still want it by the time it is delivered.


 

Fail Faster to Succeed Sooner

We can see that when competing on a culture of innovation, receptiveness and relevance are the necessary compliments to responsiveness. This is the most important way in which agile delivers higher-quality software. Code quality, user testing, and market fit are all checked as often as possible. A great Scrum team fixes cosmetic, logic, and intuitive experience problems as they go, looks for feedback immediately about the demand for the feature, then enhances each tiny increment of the product prior to each release. In agile we call this “failing fast” so that we can assure we succeed sooner. The tight feedback loop means creating the right thing very well, based on the newest information available.

Time-to-irrelevance is the greatest risk to every innovation-based project. Not only the market risk of irrelevance, but also the loss of relevant context – both code and product vision – when ensuring the quality of the software and resolving defects or maximizing the return on a feature by improving it before moving on to the next feature.


 

 

Metrics that Matter

If we are driving a superorganism comprised of teams that are focused on product innovation – not only in software – we can see there plenty of metrics that will reinforce a Prestige Economy built for succeeding in innovation. I’ve described a handful below. One last note of caution here while these metrics are powerful and valuable, it will still be essential to clearly express who is accountable for each metric and empower that person or team so that they are in control of that metric. These are also defined rather philosophically. If you have a documented Work In Process flow to share, I can give you specifics.

Measurement Goal #1 – Receptiveness

Feedback-to-Answer cycle time – the total process time from the market making a demand to the market receiving an indication of response. In classic “core” Scrum, this may simply be the time from a customer making a request to the Product Owner telling that customer a valid expected release date. In a large-scale environment, this may be the time from a Tweet received by Marketing to the time Marketing announces the planned features in a new update that contains the feature requested on Twitter. To the extent your large enterprise is attempting to compete with small startups, this is the crux of your challenge. An entrepreneur leading a small team only needs manage her or his reputation for accuracy of promises and find a reliable way to ensure that single-mind heroic vision for the product becomes a reality. The cycle time from neuron to neuron is infinitesimally smaller than any scaled cycle time that includes multiple business units, functional teams, vendors, and a PMO.

The Feedback-to-Answer cycle can also be measured at the Work-In-Process level – when a card in a latter step is kicked back to an earlier step, how long does it take for that feedback to receive an answer? If it takes a long time and there is very little work-in-progress, this is a sign that receptiveness is poor. Maybe the Scrum board isn’t visible enough or the daily stand up is not as effective as it should be. On the other hand, if there is a huge amount of work-in-progress, capacity is over-utilized and responsiveness is suffering – setting WIP limits may be necessary (even if only for a short experimental period).

Feedback-to-Answer Quality – This is likely to be a qualitative measurement if used ongoing, and is likely a tertiary metric looked at only occasionally. The most relevant use for this metric is electronically documented support tickets that receive a rating by the requestor after it is closed. The problem with qualitative responses, of course is the possibility that only the most positive or most negative reviewers to surface. This makes this a poor metric for individual or team performance but should summarized more broadly for an indication of the process. Don’t set a target, just learn from the insights.

Supply-to-Demand Receptiveness – From a buzzword standpoint, this is your “Social Listening” as an organization, both internally and externally. From the time you meet a demand, how long does it take to discover that you met the right demand? How long does it take to know if you met the right demand correctly? For software, don’t leave this purely in the hands of social network listening – build into your software trailing indicators like usage analytics, product-wide ratings, and (sometimes) per-feature ratings and feedback soliciting.

In a large-scale product environment, pay attention to listening from all sources. A few new “ceremonies” are going to be needed to encourage collaboration from Epic Owners, program/division-level alignment of a shared backlog across products, and Stakeholder Gathering to solicit additional feedback.

Receptiveness is the precursor to responsiveness. If you aren’t “listening” to your market, you will never respond to demands correctly.

 

Measurement Goal #2 – Responsiveness

Demand-to-Supply cycle time – This is the traditional definition of cycle time and the best metric that carries over from Lean Manufacturing to Lean Startup principles. From the moment a market demand is made, assuming receptiveness is held constant, what is the total process time until supply can meet that demand. Anecdotally, the highest performance with this metric in a Scrum team I led as Product Owner was on a large enterprise tool. We released to stakeholders twice a week and released to production weekly. A feedback feature was created that gave the users direct input into our product backlog. We were able to respond to improvement requests made on Monday in a fully-tested Production Release that Wednesday. Statistically, these wonderfully short feedback cycles were outliers and relied on circumstances more than team performance. I share that anecdote as challenge to whatever complacence you may have about That said, if average Demand-to-Supply cycle time is greater than 90 days I would challenge you to consider if you are really “listening”.

Demand-to-Supply lead time – This is the traditional definition of lead time and is the time from initiation to completion of a production process. In classic Scrum, that’s the time from commitment at Sprint Planning to the time it is called Potentially Shippable by the Product Owner. This is a once-in-awhile metric that should be checked as an indication of whether teams are sizing stories and committing properly.   Whether a team is new or old, they will need extra reinforcement from a manager when average lead time is consistently greater than the sprint length. This is a sign of over-commitment and sprint carry-over. Too much WIP, over-utilization, and poor story sizing will leave a team hamstrung. Quality will suffer, context-switching will breed deceleration of velocity, and burn out will occur. This is at the heart of Little’s Law. When lead time is consistently greater than sprint length, this isn’t a performance metric to track – it’s a trailing indication that management needs to set clear expectations around the trade-off between velocity and quality (including market fit). Set WIP limits and enforce true swarming activities. Because WIP is a leading indicator for Lead Time, reducing WIP should lower lead time back below sprint length.

There is an important call-out here. While experienced Scrum teams know all too well the relationship between team WIP and Lead Time – this only covers the process states for that team. In a scaled implementation, where the stakeholders have an internal proxy voice (imagine a product division large enough to include a Social Listening Analyst on the marketing team) WIP limits at the Epic, Feature, Theme/Campaign, and Product may be necessary. Putting too many items on the Work In Process flow of the Product Marketing Managers that must A) Add Epics to the Product Backlogs and B) Give feedback that the right thing was built and properly fits market demand will create terrible inefficiency in the overall innovative delivery process. The same is true when new Business Development or long-term relationship-owning Account Managers are part of the input and output. No amount efficiency gained by the teams building the products will EVER MATTER without tightening the every other feedback cycle. Restrict stakeholder WIP to ensure they pay attention, provide meaningful feedback, and properly communicate new features and gather end user and customer feedback of their own. If average lead time per story is 7 business days but it takes an entire quarter for a minor enhancement worth millions in revenue to “circle back” through the organization to the development team – YOU WILL LOSE. Pack your bags, a startup is about become a category killer.

 

Measurement Goal #3 -Relevance

Cycle-Time Feedback conversion – when an end user or stakeholder makes a request, the WIP cycle ought to have a traceable “funnel” for requests making it through to market. This is not a performance metric but a continuous improvement metric. If a product is in its infancy and market share growth is on the rise, but product innovation is stagnant, ask for more requests to go through. If a product is mature and market share accumulation has plateaued, but the conversion rate is extremely high – the process may be building for the sake of staying busy and a new product should be innovated.

Lead-time Feedback Quality – This is another qualitative metric that may be useful in a 360 review process. From the time a team starts working on a product increment to the time it is delivered, each time an opportunity for feedback occurs, what is the relevance and value of the feedback that is given? Putting metrics around this can be very valuable for a short period of time if approval processes and quality assurance are failing. If it is right for your scaled environment and will not cause unnecessary inefficiencies, this can even be formalized and automatically enforced (e.g. make a Resolution Type and Comment Field mandatory when the Product Owner moves a Story card to Closed, with the expectation that the quality of the feedback will be a topic of review by a manager for purposes of mentoring and career development). At scale, think very hard about the inefficiency this may create and its fairness across the organization prior to roll out.


Conclusion

These are a handful of metrics that actually matter for innovation and success. For specifics that apply to your organization, feel free to reach out to me for free advice anytime at andrewthomaskeenermba@gmail.com or Tweet me @keenerstrategy

This is part of a series!

Part 1 – Metrics: The Good, The Bad, and The Ugly

Part 2 – How to Fail at Performance Metrics

Part 3 – Rules For Measuring Success

Part 4 – Measuring What Matters to Innovation

Throughout the series I tie together ideas from two great resources:

Kevin Simler’s Minimum Viable Superorganism

Steven Borg’s From Vanity to Value, Metrics That Matter: Improving Lean and Agile, Kanban, and Scrum

Lean Principles for Agile Stakeholders

The Problem:

Last week, a colleague and I were discussing the gap in information and training materials surrounding a commonly reported challenge in agile product delivery: Stakeholders who have no experience succeeding with agile.


In Defense of Stakeholders:

The “stakeholder” role in Scrum has no training class.  This is because the “stakeholders” in Core Scrum is not a role, it is a symbol that signifies “that which causes demand-backlogs”.  There are multiple ways this emerges in agile processes:

  1. Core Scrum:  The “Heroic” Product Owner is also the Business Owner.  The stakeholders are paying customers.  Here, stakeholders don’t need training, the need a voice.
  2. Single Organization, Multiple Programs:  The “stakeholder” is one or more Product Marketing Manager that plans and advertises what the delivery organization with create.  The Product Owner must drive heijunka or “level loading” to balance out the demands that can be intelligently fulfilled by the teams available.
  3. Vendor Organization, Multiple Clients:  The “stakeholder” is one or more decision-makers for one or more external clients.  The Product Owner is plays a consultant role, facilitating prioritization and backlog decomposition.
  4. Large Scale Scrum:  The “stakeholder” is a business owner for single emergent product offering delivered by multiple teams.  The Product Owners either become specialists on specific features or may be responsible for specific platforms.

Why is there no “role” for the stakeholder?  Let’s define what a “role” is:

Unlike a position or a title, a role is the single-most important “thing” at the confluence of responsibility, empowerment, and accountability.

In each of the scenarios above, the stakeholder is not responsible for the product, has not been empowered to produce it, or does not have final accountability for what is produced.  However, whether one or many people play the part of stakeholder, there are several Lean Enterprise concepts that can encourage alignment and effective product planning.


Lean Concepts as a Stakeholder:

The first concept to grasp in Lean planning as a stakeholder – as I discuss at length in Applying Lean Kaizen to your Enterprise Mobile Strategy – Kaizen is the process of continuously breaking down a process, removing unnecessary effort or waste, and rebuilding it as a more efficient and effective process.  In manufacturing this progression has been underpinned by technology:  specialization around tools, mechanization of movement, automation of production.  With mobile solutions, we minimize the time and effort in turning social information into actionable data.

As a stakeholder starting the kaizen journey, use these Lean principles to guide your ongoing investment in a portfolio of mobile application programs.


Just In Time

A delivery team uses “just in time” in the Scrum framework as an approach to ensuring the most valuable features are produced “next” by delaying commitment to user stories until it is necessary (Sprint Planning).  This allows the shortest possible feedback cycle between demand and supply so that the Product Owner can adapt feature delivery to the most recent information from stakeholders.  Just-in-Time is a central concept from the Toyota Production System:

Supplying “what is needed, when it is needed, and in the amount needed” according to this production plan can eliminate waste, inconsistencies, and unreasonable requirements, resulting in improved productivity.

via Toyota

Just-in-Time (and just-enough) is not only a useful principle for the delivery team, it is central to effective feature and user experience planning, at the product, program, and portfolio level.  Conveniently, your target audience is increasingly mobile-first, but mobile solutions are fundamentally Just-in-Time!  Social information becomes actionable data on demand and on the go using a highly focused and intuitive user experience.  The ability to ignite a chain reaction from 3 taps of an iPad is an incredible time and cost saving.

PRO TIP for Stakeholders:  The most important way a great agile stakeholder can encourage Just-in-Time principles is through comfort with uncertainty and an understanding of “priorities” versus “prioritization”.

  • Don’t promise more certainty than is justified by market conditions.  The mobile strategic landscape and technological environment rapidly evolves – if you have planned ahead more than six months, have realistic expectations that some of those longest-term plans and promises are likely to change.
  • Plan to Pivot – The more short-term your commitments, the easier it will be to change the plan if market demand shifts.  Over-promising long-term plans to users may restrict the ability to pivot in the future.
  • Know your industry – What level of documentation do you really need?  Do you need comprehensive documentation at the end of the delivery process for regulatory compliance?  Do you need a user manual or should that time and effort provide training and cues in-app?

Jidoka

From the Toyota Production System, the concept of jidoka – “automation with a human touch” means that machines are “smart” enough to identify their own failure, empowering human operators to rectify the problem before faulty parts enter the production line.  Typically, these were only tested at the end of the production line, so a single machine creating bolts for engines could make an entire day’s work unshippable!  As a stakeholder, think of features that support a safe-to-fail environment rather than a fail-safe environment.  Construction workers wear helmets because the ability to create a fail-safe environment is impossible.  Instead, the helmet reduces the overall risk of failure.  Everyone has a responsibility to be careful, but the consequences are minimized.

PRO TIP for Stakeholders:  In mobile, the ability to focus a user on completing a single workflow quickly and objectively is your goal.  This creates a powerful ability to lead subjective observation into objective judgment.  Anywhere your employee is asked to supply critical information, drive what is captured toward Business Intelligence that can inform them and your organization about decisions being made and their impact on safety and profitability.


Standard Work

Because the mobile enterprise user is able to follow an established workflow of interactions, this is a time to analyze current best practices and standardize them.  Standardizing what is done, how it is done, and consistency of output not only reduces the necessity of identifying and addressing under-performers, it creates a context for the employee in which output quality is held constant for them, reducing stress.  Even more importantly, once work is standardized with a mobile application (e.g. instead of a document template) the consistency of output and capture of Business Intelligence will allow an objective review of “best” practices, removing some of the emotion and politics from the kaizen process.

PRO TIP for Stakeholders:  One changes are identified, effective MDM enables your organization to control the shift to a more effective practice by simply releasing a new version of the software.  Build any training (using interstitial screens) and feedback (with modal feature ratings) directly into the application.


Heijunka (level loading)

The Lean Lexicon, 4th Edition defines heijunka as:

“Heijunka is leveling the type and quantity of production over a fixed period of time. This enables production to efficiently meet customer demands while avoiding batching and results in minimum inventories, capital costs, manpower, and production lead time through the whole value stream.”

For an enterprise mobile solution, it is important to know a) what element of a process is most time consuming and b) when separate applications make more sense than adding features to an existing application.  In Lean Enterprise consulting, we compare the “Cycle Time” of each process block to the “Takt Time” of the workflow.  For a mobile application, cycle time is often the time spent per screen while Takt time is the total time from launching the app to completing the workflow that would need to be achieve in order to meet productivity goals.  If any step “as is” in the workflow is exceeding Takt time, its complexity must be reduced, it should be divided into separate features, or your may need a separate application.

PRO TIP for Stakeholders:  Clearly, you will not know any of this without including analytics in your application!  The testing completed by the product team and key stakeholders already familiar with the application will not show which features are causing a bottle neck for your actual users.  Use analytics!


Minimum Viable Product

While I touched on how to plan investments in the original Minimum Viable Product in Lean Startup Principles in Custom Application Development, this is narrow view in Lean Startup theory.  Once the initial release is live, the true principle of Minimum Viable Product – meaning anything that is produced by a process, not just the “product” you intend to market!  As a stakeholder, it is important to understand that you are not driving a single minimum viable product, you are part of a process that must maintain minimum viable production.  This is why we focus final testing on the user’s value from the workflow and look for sticking points in completing the desired output.  Minimum Viable Production Planning will means that throughout the delivery cycle, every increment is the confluence of minimal effort and highest viability.  In Scrum this is represented by the Product Backlog prioritized by the Product Owner.  Working software every sprint is the ultimate test and highest priority for the Scrum team, so Sprint Planning must establish the Minimum Viable Product (Increment).

PRO TIP for Stakeholders:  The goal is not to deliver less – the goal is to invest only the amount needed for any given product increment before diminishing marginal returns begin to erode the investment.  The goal is to invest in as many high-ROI production increments as possible rather than expending immense investment on process waste.  The more you are able to align with the idea of 2-week mini-projects (Sprints), the higher the overall ROI on the aggregate product.

Fixed Budget, Fixed Scope? Be Agile Anyway.

Innovation is Sexy:

Scrum is typically taught with its most innovation-focused form as the example, born from fast-paced software companies who disrupt markets and kill categories.  This is the sexy version of Scrum: a highly elastic process for delivering complex products with emergent design.  In the real world this is not the only context in which Agile, Scrum, Lean, and XP principles can and are utilized to increase quality and velocity.

If you are a newly-trained Scrum professional, bright-eyed and full of hope, do not get discouraged by convergent, fixed-budget, fixed-scope, fixed-timeline projects – be agile anyway!  This is how to do it.


The Agile Manifesto:

It is important to remember that the Agile Manifesto is a set of priorities, not a set of laws. To any extent we can, we strive to prioritize in the direction of team collaboration, continuous improvement, and emergent value creation.  However, there are some occasions when you will have to put additional energy in the secondary priority.  Strategy is the art of trade-offs, so make sure your organization is aligned and the strategic vision is deliberate:

  1. Individuals and interactions over processes and tools – Never lose sight of prioritizing the people who huddle around your solution, never stop collaborating.  Encourage face time and green time.  However, there are highly regulated industries with static expectations, accounting control benchmarks, FDA guidelines, or stable dividends paid to investors for decades.  A well-documented, repeatable process for how software, hardware, or other product will be delivered over the course of a long-term project will assist tremendously with stakeholder confidence.  Make priorities clear on all sides of the contract, set the expectation that communication and availability are mission-critical, but understand that there will be little risk tolerance for out-of-control processes.  Maintain your agility by keeping your document alive and lean, maintain elasticity, but make sure the tools used and the processes adopted, and the pace of process change, gives your fixed-scope, fixed-budget project a stable context for predicting delivery and ROI.
  2. Working software over comprehensive documentation – Delivering builds early and often is the best way to be truly certain of product status.  In emergent product design with incremental feature addition this feels natural.  There is an MVP planned so an opportunity to pivot is assumed, the feedback loop on the progress of high-quality incremental delivery is the best way for stakeholders and users to see and feel the value that is emerging.  When working with waterfall-minded stakeholders – especially if they are an external client – fixed scope, fixed budget, and fixed release dates cannot always be avoided.  However, convergent delivery does not preclude the XP and Scrum best practices of well-formed agile teams and an openness to documentation-heavy products will drive velocity and success waterfall organizations have never seen.  Instead of negative reactions to the expectation of comprehensive documentation, approach documentation as a secondary product and maintain the same expectations of prioritization, collaboration, and responsiveness.  Moreover, a convergent, finite project likely came to you with extensive documentation.  This documentation will require some additional work, but it should not be ignored.  Even though this is a source of waste that is removed during agile transformation and lean consulting in “sexy” emergent product delivery, handling waterfall requirements as documented stakeholder demands can be incredibly helpful in convergent product delivery.  The Product Owner still must aggregate, consolidate, and complete backlog decomposition with the team.  The XP user story and a prioritized backlog should still set the delivery cadence.  Be open to documentation and transparent to stakeholders about its actual ROI after it is delivered.
  3. Customer collaboration over contract negotiation – Good fences make good neighbors.  Some large companies simply cannot risk an open-ended and loosely-defined relationship, especially with vendors or contractors.  If you’re competitive strategy relies on these types of contracts, inspect and adapt.  Find how negotiation can be expedited, build in the process of collaborative relationship change, and build well-formed teams that are as adept at ramp-up as they are at innovation.  The capacity of a Scrum team to quickly assimilate a knew business and architectural context will drive success in products and relationships of all types.  Answering the internal needs of various business functions or developing solutions in new industries requires a team aptitude for understanding new contexts effectively and efficiently.
  4. Responding to change over following a plan – Change is inevitable in product delivery – the demands of the market, the technological tools available, and the state of the product being developed are a state of continuous evolution.  New requirements previously unnoticed will surface in the course of a project.  Even in a mostly-waterfall project, a great Product Owner will apply XP and Lean principals to minimize waste and maximize up-front value.  Great Scrum teams will perpetually improve, increasing velocity.  We often talk about “waterfall projects” versus “scrum projects” when we really mean emergent versus convergent delivery – fixed budget, scope, and deadlines do not preclude scrum, lean, and XP practices, they constrain them to a known outcome.  The difference between delivery by a helpless group of Project Managers and Business Analysts disengaged from team performance versus delivery by a powerful Product Owner and kaizen-crazed ScrumMaster and team is not dependent on emergent product delivery!  Collaborating around the highest value backlog items up front, swarming impediments, and tracking the variance of forecasted-to-actual product-level burn down will allow fixed dates to be met appropriately.  Responsiveness to change needs to be supported by a strong relationship of trust, which must earned.  If you are in a custom software shop, responding to RFP’s and entering into fixed projects is often the inevitable first step to earning the trust that will lead to a more agile relationship, so make efforts to meet the comfort level of the customer’s stakeholders while including a healthy process for addressing requirements changes.

Conclusion:

The values, practices, and behaviors of agile, scrum, lean, and XP have wider applicability than open-ended emergent product design.  Staying open to the unique lessons that can be learned in seemingly less-than-ideal projects will be a terrific opportunity for the kaizen-driven team to grow.  If a rigid process and convergent projects have caused the shine on your Scrum mindset to dampen, step up or step out: don’t let the context defeat you, stay true to your agile values.  On the other hand, if you find yourself in a long-term no-win situation in which you cannot drive change for your team(s) and users, maybe a sexier career path is out there for you to consider.

FREEDOM: How using Scrum un-impedes our full potential!

Scrum frees teams from the tyranny of the urgent:

A key goal of the Scrum transformation is breaking the parent-child relationship between “business” and “development”.  Technical planning, implementation, commitment, and delivery is in the hands of the team while the Product Owner provides a single priority-order backlog of consolidated items from stakeholders, users, and the developers, for the team to plan around.  Once a well-formed-team finds the right mix of XP and Lean practices (especially continuous integration and frequent releases) the pressure of “we have to do this now” is easy to manage.  If major items frequently pop up mid-week on a “release train” that deploys weekly:

  • The team leaves room in their commitment for these items
  • The Product Owner sets realistic expectations with stakeholders on which release will include the request

This is part of the power of Lean planning for making strategic product and release decisions – once the Minimum Viable Product is in the open market, data from the users can determine urgency of backlog items.  Frequently, this is a point where a pivot is desirable.  Through frequent releases, the users, stakeholders, and the team can relax and look at the big picture, free from the fear arbitrary deadlines and urgent scope “creep”.

Scrum frees teams from the fear of making mistakes:

While the extreme co-dependency that drives the tyranny of the urgent is overcome by putting an end to arbitrary deadlines and poor scope decisions, the fear of making mistakes is overcome through the key roles defined by Scrum.  Note, these are roles and this label is intentional – these are NOT by necessity positions or titles.  As I describe in Why Product Owners? a role is the confluence of empowerment, responsibility, and accountability for One Big Thing that rests on the shoulders of a single person.  Teams are free to voice ideas because the Scrum framework encourages collaborative implementation planning, cross-functional brainstorming, and constant discovery of best practices.  With XP Pair Programming, this becomes even easier as a single screen and keyboard gets two minds and four eyes that can converse on best practices, mitigate against knowledge silos, and build team relationships.  In the end, all of these adults acting brilliant and mature, huddled around a problem still have the Product Owner as the proxy to the users and stakeholders.  The team is free to determine one small solution at a time, just-in-time, and just-enough – then iterate or pivot.  When tough decisions need to be made, the Product Owner makes the call, relying on the expertise of the team, sets expectations, and maintains accountability.  Moreover, the user story – as the building block of incremental product delivery – isolates risk of mistakes to the smallest valuable user interaction and continuous integration ensures that when a new increment is not “potentially shippable” it can be easily taken out until additional iteration is completed.

Scrum frees organizations from business as usual:

When things go wrong in a large Waterfall project, multiple helpless Project Managers ask for updates but are unable to check boxes, development teams are powerless to drive the direction of the product, and stakeholders become progressively frustrated by the unfinished pit into which money is being thrown.  Then they cancel the project!  What is missing here?  JOY!  Menlo Innovation’s Richard Sheridan and author Joy, Inc. describes the importance of team joy in an interview with InfoQ:

There is in fact tangible business value to joy. But understand this: our focus is external to the organization. What we want more than anything else is that the work of our hearts, our hands, and our minds gets out into the world and delights people. That’s our definition of joy. We want somebody to stop us on the sidewalk and say, “That thing you built, I love it. Thank you. You made my life better.”

When I build a new Scrum team, guiding them with the help of my Scrum Master through the process of forming, storming, norming, this is the number one fear I must guide them through:  I say “Yes, the requirements will change.  Yes, what you build today will be modified tomorrow.  What matters is that you are a creator, people will actually use what emerges, and it will make a difference to them.”

The move from cancelled projects to meaningful user feedback has an incredible impact on an organization.  The drive to constantly improve, tighten feedback loops, and evolve through empirical process control will make disruption the norm and remove the fear of inevitable change and new ideas.

Scrum frees organizations from process rigidity:

There are three overarching goals driven by the roles, ceremonies, and artifacts in Scrum:

  1. Notice ineffective processes, workflows, or behaviors quickly and cease them.
  2. Notice effective processes, workflows, or behaviors communicate this knowledge
  3. Recommending new processes or practices that can be tested for the length of a sprint

At the organization level, the same process should occur.  While the empirical methodology monitoring “the process” – a mix of lean, XP, and other function-specific practices – is held constant, the practices that are monitored within “the process” are under constant review at the team and organization levels.

At this year’s ScrumAlliance Global Scrum Gathering in Phoenix, Arizona, I attended a terrific session  “Scrum at Scale – Free yourself from the myth of one-size-fits-all scaling led by Scrum Inc.’s Alexander Brown.  Look for an upcoming post on his argument that Scrum is by definition modular and object-oriented, such that organizations scaling Agile, Scrum, Lean, and XP can utilize empirical process control and a mix-and-match approach to the various frameworks most appropriate to the unique needs of each team.

Frameworks for Scaling Agile and Scrum

3Back:

I had the pleasure of attending 3Back consulting’s “Scaling Scrum with Scrum” training last week with Dan Rawsthorne.  It was an EPIC day due to the dense amount of information provided, philosophical analysis completed, and a very worthwhile way to spend eight training hours.  I also completed my Certified Scrum Product Owner training with 3Back’s Doug Shimp because, as a repeat customer, I know Doug and Dan present more than one perspective, offer their personal experiences to the mix, and drive collaborative discussion.  There is no one way to Scrum, and 3Back gives a broad yet practical introduction to the debate.

Frameworks:

The fundamental element of Scrum is the Well-Formed Team.  Philosophical Scrum, your Scrum 101, might make it easy to gloss over this building-block of Scrum – there is an immense amount of information to cover and the importance of the Well-Formed Team is quickly lost on the beginner.  However, after three years of driving Agile, Scrum, XP, and Lean in various organizations, I must reiterate:  the need to build on the Well-Formed Team as a paradigm cannot be overstated.

What does a Well-Formed Team – a “Scrum” in the truest sense, huddling around a problem to solve – look like?

  • It is Self-Organized:  No one on the team directs the work of anyone else on the team.  Everyone is self-started, self-directed, and accountable for their commitments to the Product Owner
  • It is Self-Contained:  We often call it “cross-functional” but this is insufficient.  A truly well-formed team has every resource it needs in one room, ready to solve an issue on a whiteboard together.  The members value working together as a team, work constantly to improve, take pride in their “chores” (effort not directly involved in completion of committed backlog items), take seriously the due-diligence and appropriate standard of care for the product increments that are built for the stakeholders and users, and practice this excellence with complete integrity as professionals.

This Well-Formed Team is completely self-contained – every discipline necessary for working software is in a room, sharing a proverbial pizza.  Pragmatically speaking, “classic” Scrum would have a team that looks like this:

  • 4 iOS developers
  • 1 Middle-tier/ DBA
  • 2 QA testers
  • 1 UX/UI designer

How they grow to become cross-functional is part of their self-organization:  The iOS developers will assist the Middle-Tier and QA in System Integration Testing, collaborate on Human Interface Guidelines with the UX/UI designer.  The middle tier looks to UX/UI and the iOS developers for what information needs to be delivered by a web service.  The QA testers are perfect for “hallway” testing of the UX/UI designer’s rapid prototypes.

framework is a collection of patterns– the Scrum framework is built from the pattern of the Well-Formed Team.

The second pattern consists of the Scrum Ceremonies – the feedback loop of Daily Stand Up, Planning, Review, Retrospective.  The last pattern is the role of the Product Owner as the single point of accountability to the users, stakeholders, business owner, and team for the value created by the prioritize Product Backlog (for more on this, see my post Why Product Owners?).  In traditional Scrum, the Product Owner is outside this Well-Formed Team.  50% of the Product Owner’s time is spent collaborating with the team about the backlog, 50% is spent with the Stakeholders.  Adding a Business Owner that handles most of the sales and business “chores”, this could be an effective Lean Startup!

Scaling the Patterns:

The 3Back course reviews three approaches to scaling the patterns set up by Scrum:

In the interest of time, and because I recommend learning this from 3Back, LeSS, or SAFe yourself, I will skip to my take-aways.  The number one thing to recognize one a framework scales is where accountability is shifted.  This is the biggest with the concept of the “Product” Owner in traditional Scrum – once several teams are delivering a single large product (imagine Spotify or Microsoft Office for desktop), or a single team becomes responsible for a long series of very different products (imagine a team in a typical custom software development company, delivering 4 to 7 products per year), the “ownership” becomes an expectation that must be made clear.

SAFe – Scaled Agile Framework:

SAFe takes the large organization and introduces agile in a scaled manner (in juxtaposition to scaling from small to large as a company grows).

SAFe

It divides the delivery of a large organization into the product, program, and portfolio levels.  The Agile Release Train and (presumably) the ceremonies are on a single schedule for the entire portfolio.  At each level, backlog development is done at the program and portfolio level, leaving the teams to deliver groomed and prioritized backlogs to deliver.  While the Agile Release Train teams, whether delivering a distinct Product or features as part of a large system, have an accountability owner, the key issue with SAFe is how accountability is scaled.  The pattern indicates scaled scrum teams, but those teams do not have Accountable Owners for the decisions or the teams!  You can see how, despite sprint-based delivery, this will eventually result in the Waterfall Witch-Hunt”.

LeSS – Large Scale Scrum:

Large Scale Scrum, is the methodology currently supported by ScrumAlliance.org for its new Added Qualification: Scaling Scrum Fundamentals.  The Body of Knowledge presented on the LeSS site is thorough and full of terrific information on the Well-Formed Team, organizing in the Large, and bringing together the  – I am still revisiting the content and will likely write more on the topic in the future.

As Dan Rawsthorne quickly pointed when tying together the patterns in SAFe and LeSS, the owner of accountability, regardless of what (s)he is called, emerges in three ways from:

  1. Traditional Scrum: The Product Owner is outside the team and gives them a prioritized but not fully groomed backlog
  2. Modern and Scaled Scrum: The Product Owner is part of the team that is handed a prioritized and groomed backlog, some level of interaction with stakeholders is sacrificed
  3. Dysfunctional Scrum: The Product Owner is outside multiple teams serving multiple competing stakeholders for several products (typically, a proxy owner ends up with responsibility but no accountability

In SAFe, the key problem breach-of-pattern is that the diffusion of responsibility overcome through a Product Owner does not scale to the Program and Portfolio levels.  The key issue with LeSS, in contradistinction, is that the the pattern forgets to give each Scrum team their product owner!  It may be be implied that a Business Analyst or Technical Lead is meant to take on the responsibility of ensuring the backlog is fully groomed, but without recommending a solution for this I predict Dysfunctional Scrum – the person accountable, the person responsible, and the person empowered are not housed in a single role.

Scaling Scrum with Scrum:

The Scaling Scrum with Scrum framework recommended by Rawsthorne and Shimp at 3Back attempts to maintain the patterns that make Scrum successful and repeat them across several teams working on cohesive product offering.  Partly drawing on the success of Spotify there is a clear effort to maintain a clear chain of accountability ownership at any level of the organization.  This is not by necessity a command-and-control hierarchy – the reporting structure can rely on Communities of Practice so that skill-specific positions can report to an expert in that field despite working on separate teams.  The goal best driven by SSwS is organizational learning.  The clarity of the One Big Role at each level, where the is a facilitator and aggregator of feedback (scaling the ScrumMaster) and a clear point of accountability for decisions related to the feedback (scaling the Product Owner) stayed true to the philosophical line of thought set up in the first half hour.

Having spent several hours with a pattern-based critique, I quickly realized the main limitation of SSwS – the pattern “scales” 50 to 100 developers in scrum teams up to a cohesive Product Offering.  As the other half of my career was focused on Management Strategy Consulting, I could see that scaling accountability beyond SAFe’s portfolio level in a many-product firm competing with unique strategies in disparate markets quickly becomes management problem, not Scrum problem.  Dividing up strategic divisions, defining positioning in the market, and set the focus of a complex portfolio of investment is strategy solution, not a process solution.  Rawsthorne alluded to the longer discussion of how to Scale SSwS with SSwS and I plan to reach out to him regarding it – Chief Operating Officer as ScrumMaster and Chief Executive Officer as Accountability Owner?  “Clark, I can picture it in my mind and its breathtaking.”

Conclusion:

Scaling Scrum with Scrum is a terrific crash course for someone looking for a philosophical comparison of multiple approaches to scaling agile or taking a large organization and introducing scaled agile.  I would primarily recommend it to trainers, coaches, and change agents.


Connect With Me:

LinkedIn       Twitter