5 Simple Rules for Real Agility 

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

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

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

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

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

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

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

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

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

4 – Create an environment of psychological safety for your people

5 – Do no harm to the user

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

The Leader I Am

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

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

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

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

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

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

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

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

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

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

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

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

Scrum Backlog Prioritization

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

Tell a Product Backstory

Scratch your own itch.

Maybe you want to start a company.  Maybe you are at a company but you need to drive a new product to market, with very little guidance on what that product is.  If you are still at the “I bet I can build something great but I don’t know what to build” phase – where I have felt stuck for the last three years – take the advice of Jason Fried and David Heinemeier Hansson, the founders of 37signals (they make BaseCamp):

“The easiest, most straightforward way to create a great product or service is to make something you want to use.  That lets you design what you know—and you’ll figure out immediately whether or not what you’re making is any good.”  Via Rework 

That’s exactly what I’m doing with Emphatic.  Full disclosure, this post is an elaborate backstory for an app!  I write about agile and product innovation, but I’d like to think the product backstory is as topical as the product backlog.  The scope of the MVP isn’t as interesting as why I chose to build it.  After all, software is part of the human social dialogue.  An artifact of our organic will-to-power, collectively, when we come together as superorganisms.

You see, I found my love of writing again with this blog.  I found my love of reading again because I ran out of knew ideas to think through and write about.  

In the process, I found a pain.

Freshly laid off, I knew of a few great books – the source material for other great things I’ve read or seen presented – so I picked them up from the local library.  While reading two of those books, The Lean Startup (Eric Reis) and Show Your Work! (Austin Kleon) – I was frustrated by how difficult it was to get in the zone reading the words on the page fully engaged when I so desperately wanted to capture notes, quotes, insights, page references, other books and authors mentioned, and tangential ideas to look up later.  As a proud millennial, I’ve gotten accustomed to doing everything on my iPhone – emailing, applying for jobs, taking notes, reading news, social media, etc.  I’ve written entire blog posts in the shade of a nice spruce tree using just my two texting thumbs.

So there I was, fumbling with my phone and a physical book and trying not to lose my train of thought or intense focus on the words on the page, I started taking pictures instead.  Thats when it hit me.  This is a pain.  I’d solve it even if I were the only user.  

To go further back, once upon a time, I was completing a philosophy degree and had to read hundreds of pages per week and write dozens of pages per week to show my understanding of complex ideas.  In hindsight, whether in literature or philosophy, the biggest pain has always been attribution and annotation.  I get so consumed by the book that I forget to write anything down for later.  I write it down but forget the page number.  Or I lose track completely of where I found something.

The pain of switching between “reader-response author” and “disciplined researcher” led me to over-compensation – as most people do with a flawed workflow – by separating the two completely!  If proper citations was a requirement, I’d research sources and quotes and build out a bibliography and write whatever I came up with based on my predetermined attributions.  If I was reading Camus for fun, I’d underline and dog-ear the book and never take a note, then write up my thoughts without judgement or attribution! 

In other words, however mundane this pain may seem, is it really a necessary fact of life?  No.  A solution could be created.  So when I see this advice, it really resonates with me:

“When you build a product or service, you make the call on hundreds of tiny decisions each day.  If you’re solving someone else’s problem, you’re constantly stabbing in the dark.  When you solve your own problem, the light comes on.  You know exactly what the right answer is.” Via Rework

All of my time in custom application consulting and delivery, everything I have ever said about agile, innovation, and leadership, is fundamentally related to what they are talking about.  At one end of the spectrum you know the pain personally and need almost no documentation.  At the other end of the spectrum, no amount of documentation will create engagement and inspiration to build the software.

Laura Klein said it like this:

The first tool in any sort of design is truly understanding the problem you want to solve. […] 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 you 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

So while I’ve been Tweeting out product backlog items and I will soon blog about how targeting and user persona validation dictates product roadmap, I wanted to share the product backstory first.  If you can empathize with what I’ve said, you’re my target user.  If you’d like to help solve this pain we share, sign up for the email list here.

Photo via Łukasz Popardowski

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

You have my permission to enjoy your vanity metrics.

I know I talk about valid metrics.  Ad nauseum. I won’t stop anytime soon – and seriously, you do need to get your act together.  That said, I empathize with where you are coming from.  So many numbers yet so little time!

 You have my permission to enjoy your vanity metrics. 

They feel good. When you’re winning, and they seem to scream SUCCESS! 

Getting more Twitter follows, higher site traffic, increasing revenue – focusing on whatever metric makes you feel better about the direction of your product, division, or company can be the little push that keeps you enthusiastic about your work.

I love my vanity metrics too: but this isn’t a “have your cake and eat it too” thing.  This is a “don’t eat cake when you’re dying of dehydration” thing.

So have fun and brag about them – to yourself.  Do not make any decisions based on them.  More importantly, as a leader, don’t let your followers waste time and energy justifying their decisions based on them.  

If you don’t know the one or two metrics that are an actionable, VALID, driver for hypothesis-based product innovation – find an expert who does.

“Managers who don’t know how to measure what they want settle for wanting what they can measure.” – Russell Ackoff

Photo via Luis Llerena

The Lean Startup (Notes)

Here are the notes I took on my iPhone while reading The Lean Startup by Eric Ries.  The difficulty of properly taking notes, referencing the pages, and getting exact quotes was my inspiration for my new app, Emphatic.

That said, enjoy: completely unfiltered or verified. Hope you catch the random Hunger Games reference.

Learning as Ex post facto justification versus a controlled empirical process
It’s better not to give into it. It takes 10 times as long to put yourself back together as it does to fall apart.
Pg19 innovation means learning, which takes controlled failure and is the opposite of efficient
Pg 30 definition of validated learning NOT justification of failure pg 47 conclusions
“Bit by bit, customers tore apart our seemingly brilliant initial strategy.”
Value vs Waste in Validated Learning – what is the simplest, most efficient, fastest way to learn which demand to supply?
Page 50 first to third paragraph
Page 52/53 the audacity of zero reinforces delaying exposure to the truth
54 squandered resources on theatrics instead of progress
Experimenting requires a predetermined definition of success and failure. If you can’t fail, you can’t learn. You didn’t actually test anything. P56

P111 dare you to get your startup idea stolen by a large company
P113 ” successful entrepreneurs do not give up at the first sign of trouble, nor do they persevere the plane right into the ground. Instead, they possess a unique combination of perseverance and flexibility.”
IMPORTANT! P126 – optimization vs learning
135 – comparison of agile team to machines in a factory
144 – guild-based sabotaging, actionable metrics the answer
“The problem with the notion of shipping a product and then seeing what happens is that you are guaranteed to succeed – at seeing what happens.”
Symptoms You Need to Pivot-

Decreasing effectiveness of product experiments

General feeling that the development team needs to be “more productive”
173 – types of pivots
Focus on only one engine of growth:

Sticky – retention, track compounding rate of growth

Paid – advertising, track margin per customer

Viral – word of mouth has an exponential impact, viral coefficient greater than one

P225 – scaling issues and adaptation

You have my permission to enjoy technical brainstorming. 

Technical brainstorming is tempting. Too tempting. Once you have a problem to solve, rushing out to find all the possibilities out there is fun.  It is so fun that it turns into bloated “sprint zeros” and one-year “MVP”s.  Don’t do that.

However:

You have my permission to enjoy technical brainstorming.
My app – tentatively named ShareLighter – has lots of exciting technical possibilities.

The process of bringing the right product to the right people is both art and science. I swear I don’t string together new word groups for intentional buzzwording. I’m learning how to bring an idea to market and sharing it as I go.
Hypothesis-driven backlog prioritization? Audience-first monetization? Analogs and antilogs?
If that’s too many words that you think are just meaningless buzz, I know how you feel. That’s why relationships are so important. Shared experiences.
Once a platform dedicated to highlighting and sharing the most meaningful words of a book is created, the platforms, SDKs, and APIs out there are thrilling to think about! Goodreads, Twitter, Hashtagify, Instagram, OCR, Amazon? It could meaningfully consume and give back so many great things! It gets me excited to read API documentation.

Seriously. All of it.
So let me just say, if you want to start a company and you have great technical chops, especially if your the one expected to wear the engineering hat, I give you permission to get excited about implementation possibilities.
You need an audience full of people can care about and understand as well as a framework for knowing if you’re solving their pains or scaring them away.
But don’t let that steal the joy of learning what you want to learn, as an individual and as a team. Get that 20% time, go down the occasional rabbit hole, experiment, make hackathons as important as your sprint review.
I’ll talk about the importance of building the right thing, but I know you love building it right. So do I. Go ahead, geek out.