Agile is dead.

Agile is dead.  Not the way your goldfish dies as a kid.  “Agile” is dead the way Marxism (as a socioeconomic political stance) is dead.  The dilution of the meaning of the word through excessive use, improper use, and deconstructionism, has made it not-worth-speaking-about.

Pragmatically speaking, there are really two ways people killed “agile”:

  1. As part of a movement, several institutions adopted the language of agile without changing their structure, values, or goals.  This made it necessary to explain your use of the word agile.
  2. Many of the practices that made “agile” marketable have become the normal way of developing software due to market demands, even in companies that expressly claim they will never practice “agile”

That latter disconnect is why you’ll see I’ll still write about things that sound like “agile” as a noun, the kind consultants charge money.  I’m going to be more specific about how innovate new products, encourage logic in product management decisions, and help you not destroy the team that makes you successful.  As dave Dave Thomas, one of the original authors of the agile manifesto said:

Agile is not a noun, it’s an adjective, and it must qualify something else. “Do Agile Right” is like saying “Do Orange Right.”

Having built my career around agile and scrum, the dread I began to feel roughly six months ago when someone started talking to me about agile in software development was meta-disheartening. 

Now, instead, I’m beginning to see that getting very specific about what I would improve in a company’s strategic planning, management tactics, and organizational psychology is extremely important.  After all, when was the last time that you used “agile” the noun-and-buzz-word-for-sale in the same way you used “agile” the adjective?

ag·ile

adjective

1.able to move quickly and easily.

“Ruth was as agile as a cheetah”

synonyms: nimble, lithe, supple, limber, acrobatic, fleet-footed, light-footed, light on one’s feet

Does that sound like your company?  Does it sound like your software team?  Product strategy?   Only if you are small, most likely.

If you work at a very large company, I have a hard truth for you.  The nimbleness of a body with extreme mass is internal. In a startup, you cancel a feature when it has a detrimental impact on a key metric.  Choosing one feature over another in a new product can pivot you into an entirely new competitive landscape, target market, and revenue stream.  In a very large company, you cancel the entire project.  You lay off an entire division.  You sell off everything tangible about the business process that are no longer part of your corporate strategy.

Remember how I said Marxism is dead?  Do you hear much about communism as a US social movement?  What about socialism?  Probably not.  Instead, in the ongoing internal dialogue of the USA superorganism, opposers and supporters alike rallied their opinions and held debates and made decisions using the words from the movement until the original words no longer accurately described the problem at hand.  Now socialism is part of our capitalism and capitalism is part of our socialism.  The only people who really care about the words as they were originally meaningful are the people either using them as a weapon or avoiding them out of fear of it hurting their reputation.

So when I stop fighting for “agile” don’t worry, my core values didn’t change.  I’m just targeting the problems more specifically, empathizing more with the people affected, and resolving their pain directly rather than fighting for revolution.

Here are a few things to do right now that will make your company better:

  1. Plan your business decisions (project-based investments) in smaller increments.
  2. Decompose development tasks so that they are less than a week of coding.
  3. Require continuous code integration (and pull-before-you-push, etc).
  4. Empathize more with users, and show your early adopters your work-in-progress.
  5. Ensure division of labor – “specialization” – isn’t leading to alienation.

 

Photo via davide ragusa

How to Validate the Problem Statement

Lean Startup Principles – Validate the Problem Statement

Remember when I said that most companies waste money on mobile and that their smart presence makes them look dumber than when they started?  Remember how I said that the Lean Canvas can be used for product roadmap and feature prioritization? 

Let’s dig in to how I’m doing that with Emphatic, the mobile app for sharing physical books with your virtual society.

Now that we have a heartfelt product backstory, let’s build the business model.  You may recall that I encourage the Lean Canvas.  It can be done quickly enough that you can think through multiple possibilities for what the right “Plan A” business model before you start investing time and energy in developing your product.

Lean Canvas Step #1 – Identify Top 3 Problems

“Validating the pain” means two things: 

  • The pain is significant enough that people would pay you for a better way to alleviate it.
  • The pain is shared by enough people that focusing a product on that pain will result in a viable business model.

In other words – “Do I have a problem that is worth solving?”

Brainstorming for Emphatic

Here is the long-winded brainstorming version of the problems. 

Problem 1 – As a father, time to myself when I can read is limited.  When I wanted to Tweet a quote from a physical book or make a quick virtual note about my thoughts so I’d have it later, the process was distracting from the experience of reading the book.  With limited time to read and limited time to write, the inefficiency and ineffectiveness of trying to do both at the same time was extremely frustrating.

Problem 2 – Keeping track of my thoughts and insights is hard short-term and nearly impossible long-term.  I love “book pairing” – I gain more from reading two or more books with topics distinct enough that the synergy between them is worth more than reading the one book alone.  As an example, reading Austin Kleon’s Show Your Work! at the same time as Eric Ries’s The Lean Startup gave me two fairly different but complementary perspectives on choosing what to create (as an artist or writer or worker) and making sure you’re creating something worth the time you spend.  Of course, he drawback if you want to properly attribute/cite your sources (and you should), is that it becomes even harder to keep track of the insights you gain and which author and book should be credited.  As I shared in the Product Backstory, this is challenging enough when I’m writing a short blog post a few days after reading two or more books.  When writing a 30 page thesis with dozens of sources that were found over a 6 month period, this went from challenging to “maybe I should just find some new books instead”.

Problem 3 – Speaking of research papers, the tougher concept to grasp in high school about bibliographies and citations wasn’t the format in which to provide the information (that just takes practice and a handy set of examples).  The painful part was the grey area between researching as a group with your classmates versus “cheating” – too many shared sources looked like you didn’t do your own homework, even though learning and researching as a pair is far more effective than doing it alone.  The flip side of that is the grey area between what you need to cite in the first place – when I combine my philosophy and MBA background with Austin Kleon and Ash Maurya to produce an idea that is fairly unique to me – what do attribute I and when? It takes so much time to properly cite things in double-spaced New Times Roman MLA format that I went ahead and restricted the number of sources to compensate – hardly what my teacher intended!

Get Succinct – Add the Problems to the Lean Canvas

If I was teaching you this in a workshop, I’d get you boil down each problem statement enough that you could write it with a Sharpie and fit it on a Post-It note.  Us workshop peeps do this for two reasons – the rest of the room needs to be able to see it from wherever they are sitting and you need to be succinct.  Thus, the long version up top represents the conversations and musings I’ve had about this so far (like I’d facilitate in a workshop) while below I’ll summarize them.

As Ash Maurya describes in Running Lean, knowing the pains that Plan A will address is important, but its the ability to validate the business plan as a whole – in this case, by sharing the completed Lean Canvas with friends, mentors, or potential customers – that is the real point.  If you can’t explain to a potential customer what pain you can solve for them in under a minute, they probably won’t care about the business model you’re building around their pains.

So here are the Post-It size problem statements:

Problem 1 – Frustration capturing quotes and notes

Problem 2 – Difficulty keeping track of insights

Problem 3 – Grey areas when citing sources

Validate the Problem!

Remember how the title of the post is “How to Validate the Problem Statement”?  You have to go talk to people!  I’m going to head over to the library and ask people who look like they love books about these pains.

Want in?

If you can empathize with these pains, you’re potentially my target customer!  If you’d like to help me solve this pain we share as an early adopter, sign up for the email list here.

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

How to Have Your Marketing Automation and Eat It Too

So you are starting a blog.  Or a company.  Or launching a new product.  Or you’re an intern or analyst somehow tasked with marketing and social media.  Me too.  I’m a couple of those – so we have things in common.  Here’s where I’ve landed so far with Marketing Automation.  Leave a comment or Tweet me @keenerstrategy if you have additional awesome ideas I can try or if you have any questions about what I’ve done.

This entitled “How to Have Your Marketing Automation and Eat It Too” because I have a fundamental impatience with my craft.  I don’t want to wait until the perfect time to publish a post.  I had the thought, I put it “to pen” and I feel closure knowing its OUT THERE.

Here’s what I do:

I use WordPress to write the post and I publish it as soon as its done.  This doesn’t optimize for the WordPress Reader audience, but that isn’t the source of views for me.  It also shares to LinkedIn, Facebook, and Twitter.

LinkedIn and Twitter are the source of my views.

I have IFTTT (IF This Then That) set up to automatically Tweet my post like this:

IFTTTThis way, using the insights from Hashtagify about my target market (people who would want to read about how I “do” product innovation and management) I can automatically add the high-impact hashtags and have Buffer send out the tweet at the time optimized for impressions.

So it looks pretty simple the first time:

After

Then the second time (when it matters on Twitter via Buffer) it has great tags added automagically:

Before

After trying both, I do like Buffer better than HootSuite.  I like the iOS app better, but the real differentiator is that it works with IFTTT – something I use for other fun things and intend to expand because it is awesome.

The other great thing to do with Buffer – because I write about innovation and Tweet posts from TechCrunch – is to use Chrome and the Buffer Chrome extension.

Have fun automating!

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

My First MVP.

Notice the blank spaces.  Notice the technological wonders that – despite my imaginative artist-engineering mind, you’d never actually see.

Tentatively Entitled – ShareLighter

Product Vision

Do you love reading physical books, but wish it were easier to share the insights you’ve gained and quotes you love via social media?  

Value Assumption

People want to share quotes from physical book pages with virtual highlights, blackout, or underlines as a form of expression. Someone – somewhere – in the fantastic conversations that grow from this narrative of noting, quoting, and sharing, wants to pay to be a patron for this game of reader-response, learn it and share it, cultural-criticism-gone-viral.

Growth Engine

Viral. People will love the app enough to share it with two or more friends. 

Success Metric

Viral coefficient, tracked by release version cohort analysis. If the viral coefficient is increasing, the cohort is correlated with the newest features, indicating they have tentatively proven their success hypothesis. 

Minimum Viable Product

To establish our baseline, we need the core functionality of taking a photo, highlighting text virtually, and sharing the photo with a caption to a social network.  To track our success, we will need an “invite friend” feature and the ability to correlate the act of inviting to the version of the app. 

“Blue Sky” Potential Features

You’ll have to see the Trello board…

Do you care?

You have other ideas, because you want this app too, right?  @mention me on Twitter for glory or shoot me an email. andrewthomaskeenermba@gmail.com 

Fine, I’ll Do It Myself

I’m going to launch a product.  I’m going to start a company.  I’m an entrepreneur now. 

I see clearly that grabbing my best intellectual ally(s) and applying the combined, multifaceted, full-stack, full-spectrum brilliance we have is far more powerful than huge enterprises can compete with.  They are weighed down.  They can’t stop siloing.  They have enough money to survive their blunders for decades – that’s the only advantage they have.

With the inspiration of Austin Kleon’s Show Your Work! behind me, I will show anyone willing to listen exactly how I progress.  By doing so, I hope every potential user can be involved in the process, not just consume the product.

I’m not worried about having my idea stolen.  I care about it because it solves a pain I have and you might have it too.  I am building it based on selfishness, love, and empathy. 

“The special challenge of being a startup is the near impossibility of having your idea, company, or product be noticed by anyone, let alone a competitor.” 

The Lean Startup by Eric Ries

If you want in, Tweet with the mention @keenerstrategy and #ShareLighter to send me questions, requests, or ideas.

Image via Kaique Rocha

How to Lose the Innovation Game

How to Fail at Agile, Ruin Your Culture, and Lose the Innovation Game

Cover photo via Andrew E Weber

There is one major issue that – if not properly addressed – is going to kill your company.  In fact, many companies FAIL MISERABLY when trying to break down silos, increase collaboration, and begin competing as a culture of innovators.  Every company must innovate or die.  Every product will face competition from a connected variant supported by a mobile app.  Mature enterprises who have never competed on innovation before are now suddenly competing with innovative tech companies!

Tearing down functional silos so that solution-oriented, self-contained, fully-functional and ultra-innovative collaborative teams is now THE biggest overarching challenge that will make or break enterprises that are struggling to maintain their decades-old success and strategic position.  Moving to agile in maturing industries, that are now being utterly disrupted, has become unavoidable for most companies.

The most common label for repositioning to compete on innovation is “agile” and breaking down silos is labeled “agile transformation”. 

There is a major failure that is gradually breaking many companies as their agile and high-tech endeavors fail miserably.  This is issue is caused by executive leadership’s denial and insecurity to face the terrifying reality that to truly “break down silos” is NOT (exclusively) a process transformation or change management issue.

Ready?

Here it is:  Breaking silos REQUIRES organization restructuring.

This major issue is two-fold and occurs simultaneously:

1. Failing to have “tech” report to “business”

2. Failing to have “business” people report to “tech”

There is an unwillingness to break apart and completely restructure the separation of “tech” disciplines and “business” disciplines, despite the growing number of roles that are impossible to clearly classify as one or the other.  In the sad but traditional approach massive enterprises take in the face of a major strategic decision, many companies are attempting a straddle-the-fence strategic position by attempting to leave their existing antiquated structure intact while building entirely new divisions modeled on the structure of successful tech companies.  This is likewise problematic – to succeed at this, revenue growth must accelerate enough to both maintain the old organization while building the new division(s) and the corporate efficiency gains of sharing administrative and brand resources means the new groups will adopt many of the dysfunctions of the old organization.  To the extent this is a Zero Sum Game played out against other competitors and multiple competitors are attempting this simultaneously, no one is likely to “win” the game.

What is the problem?

Let’s look at the first hard lesson facing companies attempting to compete against innovation-base startups and high tech for the first time.  They bring in consultants to help them break down silos, communicate cross-functionally for the first time, and establish a shared vision.  They bring together teams across various business functions, bring in agile coaches, and try to get everyone to collaborate.  They bring in vendors who seem to be better than them and try to “copy their homework” so to speak.  With enough cash, they may even implement widespread training and certification and bring in new employees who are from flat, agile, startups.

The problem that companies introduce when they do this, at any given level of the organization:  without restructuring, there is a “business” and “tech” person set together in equal standing.  If they get it down to two, that is an accidentally triumph.  It is more likely a three to four person group representing a) marketing/sales b) technical leadership c) requirements and project management d) creative design.  There is no clear empowerment for any of them, because mentoring, performance review, and promotion or disciplinary power are all linked to other pieces of the organization.

This diffusion of responsibility was the failure of waterfall in the first place!

Attempting to preserve a forced distinction between “business” and “tech” as well as the hierarchical position of leaders, then forcing “equals” into a nightmare arranged marriage on a per-project basis is a recipe for a slow but unmitigated disaster.

Taking a step back to “Core” Scrum

In software development today, virtually every high tech, innovation-based company is delivering products with some mix of agile values, Scrum ceremonies, Lean improvement efforts, and XP best practices.  While companies may call their process Agile, Scrum, Scrumban, Kanban, etc – let’s talk generically about “core” Scrum and why it succeeded where “waterfall” failed.

Our imaginary “Core” Scrum team is a small startup with a visionary leader who is a fantastic mix of technical proficiency, business acumen, and management skills.  We’ll call this person the Product Owner but in remember, this is the CEO, product manager, and sales-plus-marketing all at once.  For simplicity, everyone else in this company of about 12 is part of the software delivery team (all other roles like accounting are outsourced).  They are The Team, and one of them is the Scrum Master who keeps the process of delivery rolling smoothly, constantly challenging everyone to collaborate more.

That’s “Core” Scrum in a nutshell:  The Product Owner is roughly 50/50 split-focus between the Team and stakeholders, the Team only needs to converse with one voice of prioritization, and the Scrum Master keeps this one small group on-time, ever-learning, and un-impeded.  The CEO owns the company, its only product, and all stakeholder relationships (investors, customers, end users).  This is “pure” Product Ownership – the entrepreneur “lives and dies” by the sword of her decisions because the power, responsibility, and accountability for every promise and decision is firmly on her shoulders.

The purity achieved here is simple to understand:

the company role and its associated place in the superorganism’s Prestige Economy is perfectly aligned with the project role.

The Scrum Master manages no employees and builds culture, collaboration, and keeps the Product Owner’s relationship with The Team healthy and strong.  If this were a highly technically complex product, the ScrumMaster could be a very experienced architect who is can assist in code quality decisions, pair-programming to overcome tough coding challenges, and resolving any risks to the long-term sustainability of the code.  In an extremely technically complex engineering environment, it would make sense that this (dare I say) Architect is a thought-leader but not a people leader.  This Architect knows all of the code and is on speed dial for production issues.  The strength and trust it takes to successfully push the CEO to prioritize refactoring over new features, hardware investments versus new hires means the Scrum Master must be a right-hand-man to the CEO but have no agency dilemma or conflict of interest in making certain the CEO (Product Owner), the Team, and derivatively (via total process quality) the Product are at any given time healthy.

Naturally, we can assume a different but very valuable breed of Scrum Master is also possible.  If we imagine a software product where technical uncertainty is easily handled by an experienced team of engineers but the business rules are extremely complex, a business analyst may be the perfect Scrum Master insofar as Backlog Decomposition and the precise details of User Stories will require a business person with the Product Owner on speed dial who can resolve every business rule uncertainty.

Just like our anecdotal Product Owner, we see in each anecdotal Scrum Master, due to the nature of the product, the company role and the project role are perfectly aligned.

Scaling vs Scaled

This simple paradigm is compelling due to the clear accountability and laser-sharp focus  that makes it successful.  With the single, properly-sized team described above, it is easy to understand why it works and how emulate it.  Confusion tends to set in as the number of contributors and teams grow.

There is an important distinction to make between scaling this pattern and implementing the pattern at scale. 

Continuing our narrative about this successful “core” Scrum team, we can imagine the company grows organically as the product becomes increasingly successful.  Revenue is great, margins are fantastic, and more engineers join.  It becomes clear to the CEO (and Product Owner) that second product would be a perfect strategic fit.  The product, focused on different niche in a similar industry will leverage the skill set of the engineers, design patterns, and the libraries and APIs that have been built over time.  Stakeholders are excited, ready sign on the dotted line.  The engineers are thrilled.  As a group, they decide to split into two teams, each focused on their product.

This Scrum implementation has begun scaling.

The shared code and strong culture combined with the mature agility and engineering best practices allow the ScrumMaster to happily work with two teams.  Unfortunately, the CEO is now  splitting time roughly 20% stakeholders and 10% team on product #1 while 40% stakeholders and 30% team on product #2.  Days get longer and attention to the backlog is suffering.

The CEO is no longer effectively owning either product.

Her trusted colleague, the ScrumMaster talks through the risk of “Hero Scrum” and the need to delegate, and the risk of poor feedback or lack of actionable backlog when more engineers and another designer will be joining in the summer.  There is demand to have the APIs and an SDK consumed B2B.  The decision becomes clear – two experienced Product Owners are hired, one to manage the consumer apps Scrum Team and one to manage the B2B cloud platform. 

The CEO sees that leading the company’s strategy, defining new products, and the need to build a brand, while mentoring the Product Owners on great management of their categories and teams is her new “job role” and “project role” – it evolved organically, and the two still align perfectly. 

This is a happy company.  More products follow, and while not all of them are an instant success, the values, vision, and identity stay strong.  Camaraderie, disruptiveness, and culture of innovation keeps this company profitable at-scale, through a constant assurance that the job role and project role, whether a Jr. Developer or a Marketing Specialist, are always properly aligned.  People are asked to own “one big thing”, empowered to succeed, and held accountable.

Paternalism and Guild-based Hierarchies

If you work at a large company and this happy anecdote sounds ludicrously fictional, it is because implementing agile in a scaled environment – whether due to the success of an isolated team or a management decision to copy Silicon Valley – rarely looks like this.  Large enterprises in mature industries were born out of organization and management practices dating back to the British Empire and the industrial revolution, and function-based guild preservation that began in the Dark Ages. 

Blacksmith best practices evolved, certainly, but not so fast an entire practice community couldn’t keep up.  The capitalists in the industrial revolution could invest in a few big innovations, paternalistically demand new behavior from a new “guild”, and reap benefits for decades. 

Marketing, even as the internet bubbled, consumer product research and development despite the worldwide adoption of desktop computers, and a whole guild built around Information Technologies did not disrupt this proud history of dividing the troops into functional units held together by rules, history, and strong paternalistic leaders.

Transforming Project Roles While Preserving Job Roles

The United States Military is realizing, unit-based combat in an urban setting full of emerging demands and uncertain risk.  Cross-functional teams are being built tactically insert their blend of skills into situations that require empowerment and responsiveness.  The days of marching pikemen and flanking with cavalry are gone.

Enterprises are realizing the same is true of innovation-based product markets.  A level of guided group-think is needed to courageously build an innovative product for a still-emerging market segment.  The capacity to “lock everyone in a room” that you need, and risk market and technical uncertainty requires executive mandate and tenacious teams.  Limiting investment to two weeks of team effort at a time, fierce concentration, no politics, and freedom to experiment are essential.  This is a creative process that requires adventurousness and tenacity.  Let adults succeed and celebrate or fail and learn.  Otherwise management is simply holding back the potential of their most brilliant engineers.

To do this, one thing must happen above all else.  The job role must perfectly align with the project role.  If job descriptions align to guilds, as a talent “pool” of human “resources” to get allocated like widgets in a managerial accountant’s spreadsheet, the project – which is intrinsically finite will always suffer.  The job is linked to performance and salary. 

Predictably, people behave like a faceless number on a spreadsheet when you manage them (and pay them) that way.

The move to “agile” is in large organizations is nothing more than an attempt to move to a company that has established a culture of innovation as its sustainable competitive advantage.  The four cultural choices are simple to understand, but they inevitably fail without a strategic mandate from executive leadership, and the “blessing” to fail when overcompensation in the effort to change occurs.  As a leader, tell your people these four virtues are the key to success and back it up in your daily actions:

Collaboration Focus  Put all the right people in seats next to each other, tell them they have one goal: unlock your full potential by learning from and investing in your team as you solve tough problems.

Product Focus – A project is finite, a product is a living platform for an ongoing conversation.  Build a dialogue, tell a story, and leave a legacy.  Do you really want to control your budget and schedule, or do you want to change the world?

User Focus – The ideal information symmetry cycle:  The user Tweets a feature they want, the team codes it, knowing exactly what the Story means to the User, and the user has it in-hand within a month.  The further you alienate the producers from the consumers, the more wasteful and less innovative your organization will be.

Innovation Focus – Taking risks and learning from mistakes is mandatory.  Encourage it and live it. There is infinite content available and your well-formed team’s natural curiosity are their default state.  If they aren’t innovating, you’ve burned them and overburdened them.  Give them some slack and encourage their interests – you’ll be amazed what the unbridled human accomplishes.

Issues At-Scale:  Agency Dilemma

At scale, reorganization – not just redecorating – is going to be critical.  There will be politics to deal with.  It will take immense courage and backbone as a leader.  Middle managers will be your biggest problem until you change the seating chart and pick the right people for those seats.  Agency dilemma from the guild-based job hierarchy will ALWAYS impede the success of cross-functional teams.  Functional managers encourage non-collaborative activity.  Over-documentation.  CYA.  A lack of focus on the team and product. 

Why is this so prevalent? 

It is not simply the change management of restructuring, changing number of direct reports, flattening the organization – that is all incredibly well-known turf for large, established enterprises in mature industries.  The new political problem is two-fold and pragmatically simple:

1. Failing to have “tech” report to “business”

2. Failing to have “business” people report to “tech”

Unfortunately, the politics of putting previously separated guilds in charge one another is  not the root cause here.  You could put an abstract painter in a direct management position over a cross-functional software team so long as they had the skills to lead them to success and prestige.  Instead, it is a symptom of leadership not understanding the team-product-user relationship.  In “core” scrum described above, this was simple.  The start-up was built around it.

How you should restructure, once you “get” it, would be fairly simple: If the user has needs that are solved by a product that will need a team that must overcome technical uncertainty first and foremost – a more technical manager for that product team makes sense.  If the user has needs that are solved by a product that will need a team that must overcome market uncertainty first and foremost – a more business-savvy manager for that product team makes sense. 

In other words, when an old business problem can be solved by new technical innovation, let an engineer lead the cross-functional team.  When an old (enough) problem can be solved by technology by changing the complex business problem (think finance) – put a subject matter expert as the team manager. 

If the multiple products fit into a “category” where the users are likely to consume multiple products, scale to a director who can set strategy, build a brand, and ensure cohesion.  This person will likely be a mix of skills so significant that designating them “business” or “tech” simply makes no sense. 

Diffusion of Responsibility

This brings us full-circle back to the reason why organization restructuring needs to occur at all – multi-bossed employees are easily distracted.  Too many leaders goes hand-in-hand with sharing resources.  No one knows what any given employee is doing while no employee is terribly confident which leader to follow.  In a guild-based system, they fall back on their functional allegiances and their job description.

When you make an engineer (with experience taking new products to market) the direct manager of a cross-functional, self-contained product team that can collaboratively handle business+tech roles needed for a highly technical product – planning, design, engineering, quality, and marketing – that manager has a pulse on what everyone is doing and everyone knows who to go to when their workload gets too light.  The same is true if this manager is from a business background.  The end user is well-known, the backlog is simple to build, and the product is the professional focus of everyone in the room. 

This independence and focus is the building block of a culture of innovation.

Shared resources and functional guilds perpetuate agency dilemma, information asymmetry, and diffusion of responsibility.  Kill it by restructuring before it kills you.

Scaling Issues: Copying Enterprise Dysfunctions

To be thorough, this is not exclusively an issue faced by enterprises shifting to innovation and high-tech at-scale.  Growing from a startup to a mid-size company and beyond means personnel growth and collective skill-set via true talent acquisition.  However successful a small company was at innovation through collaborative, cross-functional problem-solving, pulling in new people is incredibly dangerous.  The temptation is fill in the top and middle with highly experienced managers and individual contributors.  Enough new hires with more than a few years experience inevitably bring with them the “baggage” of their guild-based past and the political self-protection of the toxic culture they left behind. 

If you are currently scaling, learn from the issues facing scaled transformation and protect your culture, mission, and values from the threat of new and toxic influences.  Grow teams into categories, categories into industries.  Agency dilemma, information asymmetry, and diffusion of responsibility are the inevitable dysfunctions of a company that loses its sense of identity by growing too fast through acquisitions. 

First of all, grow from your bench.  Being a small company is no excuse for constantly showing employees they will never progress in their career by hiring knowledge and leadership from the outside.  Second, when a subject matter expert can only be acquired, it makes no sense to put them in a leadership position as well – they need to spend their time educating the organization. 

To succeed in scaling a small culture of innovation, keeping every person at every level fully focused on their end user, their team, and their product is the only path. 

5 Reasons I Would Fire You

Originally posted April 2016. 

Disclaimer: I currently work solo on this blog and could only fire myself – so this isn’t veiled threat.  I have done my best to mentor individuals and lead teams aways from these dysfunctions; and disrupt processes that perpetuate them.  These are also part of my personal introspection process.  This is not an accusation of anyone  in particular.  Instead, these are traits we can all continuously work to improve.  On the other hand – “You’re so vain, I bet you think this song is about you.”  

The Top 5 Reasons I Would Fire You

Tech professionals on teams trying to innovate:  Speaking on behalf of managers, your peers, and individual contributors everywhere, these are the top five reasons you aren’t just a poor performer, you’re bringing down the people around you as well.


Reason #1 – You Default to One-Way Communication

Collaborative problem solving cannot happen without meaningful and timely feedback.  There is a time for group chat and a time for well-argued prose (email).  To avoid death-by-chat and long CYA email chains, you need to set clear expectations about when you need to focus and when you can discuss issues – and respect that prerogative in others. 

Whining about documentation, instructions, or a process as document brings you no closer to a better workplace experience for yourself, improved team health, or a product you can feel a lasting pride, prestige, or sense of legacy about.  Bring a solution to the table, own your responsibility for following up, and escalate to a scheduled meeting if needed.  Folding your arms and leaving work unfinished is childish.  You know you can do better – do it.

Mantra – There are no documentation problems, only communication problems.


Reason #2 – You Repeat the Same Words When I Say I Don’t Understand 

Speaking of childish, self-advocacy is an important milestone.  It requires enough vocabulary, understanding of abstract concepts, and recognition of similarities and differences to allow a child to not only imagine a future state that is desirable, but also solve the most likely path to attain it, and make a rational statement to an adult who can permit, empower, or provide.  My three-year-old daughter, forgivably, needs an enormous amount of assistance, and patience, when she attempt this.  As an adult, you should not.

As a leader, I will do my best to bridge the gap between your words and my words.  I will cue you when I am unable to build that bridge, repeat back to you what I understood you to say, and ask you to demonstrate or show me where and what you mean so that I have the context I need for a deliberate and logical decision.  I will do all of this without patronizing you, even when it is mentally exhausting for me.

Not everyone has learned to lead this way, and I admit I can be imperfect at it as well, so you absolutely need to learn to self-advocate.

That said, I cannot heroically be an adult on your behalf.  The real dysfunction that brings down team performance through your own sub-par performance is the continued repetition of the same words when I (or others) explicitly ask you to re-word the request, argument, or question.  You are obstinately anti-try-something-else.  You refuse to paraphrase, assist my incorrect understanding, or demonstrate the meaning of your words.  It is only through my strong personality and insistence that I convince you to show me exactly what the problem is so that I solve it rather than answering a question that sounds like utter nonsense out of context.  Unfortunately, even that is not always effective.  I can carry my pre-school daughter to the cabinet and let her pick the exact afternoon snack she wants.  I cannot “carry” you as an engineer into a realm of creative solutions where emerging technology and emerging market segments meet.

Mantra – Communication is the responsibility of the communicator.


Reason #3 – You Feel No Pride of Ownership Over Your Work

Having coached, worked with, or heard the complaints of hundreds of tech-focused professionals in various, I have found this can often be more a symptom of the dysfunction of an organization than the root cause of poor performance.  The tech industry today is too mentally demanding and excitingly disruptive to attract genuinely lazy people, looking for a free ride.  So when you start giving into distraction, procrastination, or laziness, my leadership spidey-sense goes off.  I will tell you the secret to motivating innovation-based technical teams – empower them to know the impact a line of code will have on an end user. 

Karl Marx’ philosophy describes this exact phenomenon in its examination of the individual worker’s separation and alienation from the product.  Superficially, the question seems quite simple:  Which is more rewarding, a carpenter who makes custom-installed wooden shutters, getting to know the customer, their home, and tastes in the process, or working in a factory running a machine that produces millions of shutters for a big-box store’s generic one-size-fits-all product line?

If you have lost pride of ownership over your work as a software professional, though, shame on you.  You have no excuse for complacence, apathy, or becoming disengaged.  Your skills are a premium product in a seller’s market.  Companies of every size will fight to win you to their side. With one idea and a few colleagues, you could start a company of your own in a heartbeat.

Now, let’s be adults here.  We all have to collaborate and negotiate.  When the majority or a manager makes a call that goes against your individual dissenting opinion, don’t stomp away and pout.  Losing pride of ownership over work, and settling into a free-rider paradigm brings down the team, the product, the end user, and your career.  You better woman-up or man-up and either do a great job that you can be proud of, work to change the organization that is stifling you and your peers, or move on.

Change takes courage, but our virtue is the outcome of our habits.  When you accept and justify your childish, dysfunctional, lazy, sub-par effort and excusing yourself through an external locus of control hurts no one more than you.

Mantra – Anything worth doing is worth doing well.


Reason #4 – You Hide Behind Uncertainty

Deconstructionism is a dangerous game, especially when you are part of a team that is teetering on the edge of a cliff overlooking the seas of chaos, moments from falling into market risk or technical risk that could engulf you.  Since I coach teams on how to become a room full of adults solving the pains of a real person through a collaborative, unified, inspired collective brilliance and sheer power of will, I have a radar for someone  who is hiding. 

You are playing a dangerous game.  You signed up for this, after all.  You wanted to be brilliant, in the thick of it, defining emergent market segments using emerging technologies – but the minute you lost faith in the cause, lost hope for your job security, or lost belief in yourself as a builder and creator of new tech that can change the user’s world… that was the moment the inherent uncertainty of our goals became apparent.  You shut down.  You got stuck.  You became intolerant of technical risk AND market risk and looked to your leaders to spoon-feed you.

At first, a good leader can give a big speech, host a team-building event, or roll up the proverbial sleeves to help.  When the team as a whole needs some slack but they still have their eye on the prize, I have a long list of tools and tricks to re-energize the whole team.  When an individual begins the process of deconstructionism, and moves every conversation into an infinite regress in which the certainty of any word or any intention or any risk is now more important than the product discovery process, that’s when a tough love heart-to-heart happens.  Agile demands small increments.  Innovation requires trial and error.  You must remain infinitely curious.  You must self-advocate for the size of the risks you take.  Escalate when time-to-feedback is hurting you.  Sturdy yourself and your tenacious attitude about the “failure” intrinsic to empirical discovery – otherwise you don’t belong in this work space.

Mantra – Fail fast to succeed sooner.


Reason #5 – You Give Up Before Attempting to Solve a Problem 

This issue if often comes hand-in-hand with insecurity toward uncertainty.  When it comes to coaching a product visionary in agile, this means whipping them with the importance of setting goals for the product, an end user to empathize with, and a pain to solve in the target user’s particular context.  Once that is in place, a team – as a whole – may need some encouragement that a 100% success rate is not the goal.  Innovative, defect-free software that fits the user’s needs is the goal.  As it turns out, some people fear failure too much to risk it.  If that’s you, make sure you are in the least innovative technical space possible.  Sink your teeth into a legacy system and never complain about the spaghetti code you manage again.  That slow-moving space is perfect if you prefer to play it safe.

Innovation may not be important to SOME people, but it is VERY important to the REST of US.  The courage to risk failure is essential to experimentation. 

The real issue, of course, is not the fear or the failure.  It is a lack of proper perspective that puts your short-term ego ahead of long-term viability.  It is a base rate logical fallacy in which you are ignoring the most important variables.  Pretend for a moment that we have a product for which any given User Story – which we’ll restrict to less than two weeks of effort to get from planning to production – has a 70% chance of success (completion in two weeks) due to technical uncertainty and 20% chance of success due to market uncertainty (i.e. “is it really what the end users need?”).  If you take the risk of a false-positive – succeeding in releasing a working product increment that the market doesn’t demand – as the only indication of your own failure, you are sure to be unhappy. 

Now, imagine a breathalyzer has a 5% probability of a false-positive.  A police officer pulls over drivers truly at random at a random time of day.  What is the probability that a driver who tests positive is actually drunk?  Guess what!  A dreadful 2% chance.  Luckily, officers are trained not to play the odds like that.  The time of day, the day of the week, the location selected, and driving behavior all weed out the risk of a truly random selection.  Then recognition of symptoms, through human interaction must give probably cause. 

When you stop trying to overcome technical risk or market uncertainty prior to even attempt to solve a problem, you’re like a cop who stops pulling over anyone due to the statistical uncertainty of a false positive.  If you attempt to solve 0% of the problems you face, you’ll come away with a 100% lack of solved problems. 

Tackle 100% of the tough challenges tenaciously, courageously, and look for an assist as needed.  Anything else makes success incredibly unlikely.  The market risk of success is hard enough.  Don’t ruin the odds further by quitting in the face of technical risk.

Mantra – You miss 100% of the shots you don’t take.


Grow Up or Move On

If these sound like you, work to grow as an individual or you are likely already on your way out the door.  If you, your peers, and even your manager exhibit these traits and the organization seems unlikely to change despite a heroic group effort – it’s time to move on.  Complacence, apathy, and passive aggression is terrible for your career.

I’ve taken to saying, “Some people just want to watch the world burn – the rest of us build it anyway.”  If you aren’t a builder, at least stop burning down what the rest of us will happily accomplish with you.