Eat your defects as you go 

Defects are the garbanzo beans of the product backlog salad. You aren’t opposed to eating them in general, but if you aren’t purposefully getting some in every bite, they keep falling to the bottom of the bowl and you have a big pile at the end that you wish you could ignore. 

Backlog Prioritization Methods

This week’s learning focus: develop an approach around facilitating the great “How We Prioritize the Backlog” discussion that can be used as a workshop in lean-agile scaled transformations.  
While I have my own preferences and have heard a variety of approaches recommended, it seems the “how to tailor it to your context” is a missing piece.

So if you are part of a group with multiple Product Owners, Product Managers, and other important stakeholders involved in your prioritization decisions, here are the best links on the topic so far. Full write-ups on connected topics and pragmatic recommendations will follow!

Agile 42’s Lean Canvas Method
http://www.agile42.com/en/blog/2013/04/11/lean-project-canvas/

Pragmatic Marketing’s Why ROI Won’t Work
http://pragmaticmarketing.com/resources/why-prioritizing-your-agile-backlog-for-roi-doesnt-work

SAFe WSJF



http://scaledagileframework.com/wsjf

Blog Post that Combines the thoughts above, though it’s so academic it may not be actionable to agile first-timers
https://blogs.versionone.com/agile_management/2014/10/30/agile-prioritization-a-comprehensive-and-customizable-yet-simple-and-practical-method/

How do you prioritize you backlog?
andrewthomaskeenermba@gmail.com

Photo via Rework. Read it!!

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.

The Lost Product Owner

The Lost Product Owner

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

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

{inspirational anthem plays in here}

Let’s be real.

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

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

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

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

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

Photo via Jaxon Stevens

How the Sausage is Made

Conventional wisdom: “No one cares how the sausage is made.”  I’m sure you’ve heard this before as well. Maybe it gets followed up with more assumptions: “The consumer cares about the product.  They want the solution.” However, that’s not really true either. They care about their pain. The solution is irrelevant unless the pain is relieved. If you’re really great, you replace pain with pleasure, and build a lasting relationship that your customers are excited to tell others about.

The Sausage

So let’s talk about this proverbial sausage.  When you are hungry at a game and a sausage wrap stand is the only food or you’ll miss the entire game?  No. You probably don’t care about how the sausage gets made. You care about your hunger. You care about the solution. You care about the price. 

Luckily, we don’t live in the local monopoly conditions or restricted logistics of that example.  There are true artists of the craft, solving new pains everyday.

Have you seen how a master chef makes tantalizingly delicious and unique sausage from scratch?  If you love sausage, you do care how it’s made.  You would buy recipe books, watch reality shows, do factory tours, and attend sausage festivals. There is a huge difference between being an artist with a following versus a monolith with a secret. Which company are you building?  Naturally, I didn’t write this post to discuss sausage (though after talking about it so much I’d really love to fry up a batch now).  This is really about sharing your product backstory and software delivery methods. 

Think about a great chef. The kind that writes recipe books, heads up gourmet restaurant chains, blogs about food, hosts a show, and even gets invited as a guest to cook on other people’s shows.

Imagine Martha Stuart or Emeril Legasse teaching their audience about homemade sausage from scratch.  They smile and cook with their pre-measured bowls of colorful ingredients, hand-grinding the sausage.  The sight and sound of the fire, and sizzle of butter in the pan make you certain you’d want to eat not just any sausage – that sausage.  The great chefs care how the sausage was made whether you care or not. They make the best sausage they can and teach others to try their methods even if most people will never bother to make it the same way. 

So, even though what we are really discussing here is either 1) ”no one cares why your product was made” or 2) ”no one care how your software is developed” – I think that’s drastically incorrect. More importantly, when someone says “no one cares how the sausage is made” to me, I know it’s a symptom of something terrible in the prestige economy of the superorganism that could someday bring it to its knees, never to rise again. 

Now we can qualify that old saying…

“No one cares how a faceless factory makes boring sausage.”

Don’t let your factory remain faceless. No matter how boring the boots-the-ground element of your product delivery may seem, those are people who are representing you.  You can either take the Ice Road Truckers and brewery tour approach to your product delivery or you can hide it away. Even the most faceless factories have tour guides. They have a script, sure. This is a marketing opportunity for your customers who are most likely to give a referral. If they show up to see how the sausage is made, give them a taste of the experiments that you aren’t mass-publicizing yet. This let’s you find your early adopters.  That’s a special relationship that you should encourage, invest in, and keep personally engaged.

Go take a tour of a big beer factory and a small craft brewery, compare the two and imagine what a “brewery tour” of your software company would look like.  The big beer companies have a loyal fan base and brewery tours. The ingredients are well-known.  You can even try it at home.  Operational effectiveness, consistency and quality, and reliability are the big beer maker’s keys to success – not proprietary ingredients.

Don’t be afraid to demo upcoming features before they are finished.  Your opportunity to learn and from customer interviews during an alpha release cannot be understated – give them a tour before you make them work for you.  Don’t just make a website, make a fan page too.  Show people you care about what you build as much as they do. Make the digital delivery part of the human dialogue.  As it turns out, you can’t make people get interested in you by yelling “I’m interesting!”  Telling people your product is the best (today) doesn’t say much at all.  Showing them that real people are making sure the product will continue to get better, teaching them what you wish you knew 2 or 5 years ago about the pain you solved and how they can solve it too – then they might be interested. 

“No one cares what the ingredients in the sausage are if they can’t see and hear the artist who uses them, the special process for preparing and cooking it, and insights in why decisions were made.”

The individual lines of code you write aren’t proprietary. Maybe one or two shouldn’t be public knowledge for security reasons.  The rest are meaningless without the rest of the code base and all the people that create viable product-market fit.  Your accounting KPIs, eCommerce analytics, or SDLC aren’t that special on their own either. Your templates are common knowledge to anyone with experience. 

Your people – coming together to do something bigger than themselves -THAT’S special, and while you can lose that no one can steal that. I suspect there are some companies that would never approve a marketer posting a photo of coding-in-progress on Instagram for fear contents of the screen is proprietary. Yet, any developer would tell you that turning frameworks into a worthwhile platform people can reuse is incredibly challenging. No, nobody cares what your product planning meetings or your Scrum process is, unless the people who make it special are front-and-center.  You can make an official statement – like so many companies – that your people are your greatest asset; but when you hide your people and how they work from the public eye, the message is clear, not only to your people but to your customers as well: you don’t take any pride in the sausage-makers, so the sausage probably isn’t that special. 

This is the difference between posting on Twitter “My apple pie is made with 20 apples” versus a video explaining which apples to use and why, the process you use when you pick them out at the store, why you bought them where you did, etc. Teaching the generations coming up behind you makes you matter, not protecting a secret that isn’t even a secret worth stealing. 

“People don’t care how the sausage is made unless they trust you share their love of great sausage.”

The difference between having consumers and having an audience is sharing their pains, pleasures, fears, and passions. Don’t sell to people, mentor them. Don’t market to people, teach them. Is it possible that some people want to know how you make gumbo but not how the andouille sausage was made?  Absolutely.  That’s the line between retention and referral – if you say secret to great gumbo is making the sausage yourself, the real advocates who trust you as an artist and an expert will pay to learn your sausage-making methods.  The opposite is true too.  If you don’t share the passion or demonstrate your expertise, no one is going to listen.  They can spot you as a fake from a mile away.  They know sausage isn’t a priority for you and nothing you say about making sausage is worth sharing with their friends. 

“No one cares how you make the sausage if YOU don’t care how you make the sausage.”

This is probably the most on-point.  Teams who think no one cares how the software is made also don’t have much pride or faith that their process is worthwhile. Sometime the biggest challenge is just showing the engineers how great they are. As the leader, you have to be like a head chef: It’s not just that you love and take pride in the craft, it’s your time-in-the-fire and belief in the process itself that give people the confidence to follow you.  Sure, your customers may not want to sit and watch code being developed for hours on end, but throwing a montage, hosting meetups, YouTubing behind-the-scenes footage, and some exciting reality show commentary is something people love and look for as part of the complete package. That type of messaging let’s people know you care about the work it takes to solve their pain. By giving some visibility into how much diligence, care, and work is put into the next release, your customers can feel they were part of the experience and have a better appreciation why updates and new features can take awhile to release.

If you want the inspiration I had when I wrote this, go read these books:

Rework

Steal Like an Artist: 10 Things Nobody Told You About Being Creative

Show Your Work!: 10 Ways to Share Your Creativity and Get Discovered

Photo via The Digital Marketing Collaboration

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

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

The PERFECT Agile Process

THE PERFECT agile process for new product innovation achieves two things: everyone is intimately involved in creating something for a well-known archetypical user and everyone has scientific certainty that the next engineering feat and market risk is a hypothesis that merits experimentation and discovery.

Your agile process doesn’t do that?  I’m not shocked.

If you aren’t sure – how happy are you with answers to questions like:

  • How did you prioritize this feature over that one?
  • Do you really think people want this?
  • Are you sure this is what they asked for?

Most agile implementations are focused exclusively on maximizing the efficiency of 40hrs of develop labor-time.  Like optimizing a car factory for the performance of only one step in the assembly flow – that’s absolutely counter-productive.

Here’s the perfect Work-In-Progress flow:

Idea, hypothesis, commitment, construction, iteration, validation

To further smack the face of convention, I’ll add three claims:

You don’t need testers.

You don’t need estimation.

What we do need is the discipline to know we are building the right thing before we build it, then test that assumption objectively.  This means A/B releases sometimes, cohort analysis, and a clear understanding of the most important metric for each product.  This agile process combines all of my experiences with the concepts discussed in The Lean Startup by Eric Ries, and results in a Scrumban flow best suited for building a culture of innovation.

Let’s break it down:

1 – Idea (Pains to Solve)

The idea backlog is everything feature and improvement we feel reasonably certain will make the product more successful.  This is where we discuss the future.  These start as undocumented epics and end up split into user stories that can be objectively prioritized.

2 – Hypothesis 

An idea gets to the hypothesis stage once we have collaboratively estimated the impact of the feature.  This requires metrics and forecasting.  The work we do needs to be traced via innovation accounting.  If we don’t have an objective, realistic impact number that let’s us know if we built the right thing, we won’t be able to learn properly.  We need ensure we small-batch-ify the features into releasable stories small enough to be code complete in around two days.  The larger the story, the less likely our predictions are accurate.  This is like being the first person who invented cake.  Small changes in variables make the scientific method, even in an art like baking, successful.

3 – Commitment

Pretend there are 7 cards in the Hypothesis column.  Because we have numbers that relate to value and certainty, we can easily prioritize our backlog and complete “Sprint Planning” for the highest-impact cards.  This looks like a hackathon, so whiteboarding, pair-photoshopping, research, and hackathoning is completed.  When we are confident we are building the right thing and that we know how to build it, we commit to our users what is coming up next for them.

4 – Construction

We pull cards into construction while we are building them.  We are creating and coding, answering two questions as we go as new ideas come up.  Is this realization something essential to our hypothesis?  Can this wait until later?  We want the construction process to be collaborative and insightful. 

5 – Iteration

When we’re done coding, we review the working software as a group.  This isn’t manual testing, this is more along the lines of “Two likes and a dislike”.  If we see a defect or have an improvement, we ask the two questions for each thing – Is this realization something essential to our hypothesis?  Can this wait until later?  We want to remove “contaminants” from our experiment at this stage without changing the hypothesis.  For example, if a different shade of blue will improve readability so much that we think NOT changing it will invalidate the hypothesis, let’s change it.  If we think the user would like to choose the shade of blue, that’s a new idea and its added to the backlog.

6 – Validation

Our definition of done requires that we validate the hypothesis.  This is done with product metrics, social listening, and customer interviewing.  If we prove our hypothesis we should ask “Can we do more?” and brainstorm how to continue to reap the benefits of the new feature.  If we disprove our hypothesis, we know we didn’t build the right thing and our retrospective (and customer interviews) should ask “Why didn’t this feature achieve {hypthosis xyz}?” and “What did the user want instead?”

What we won’t do:

We are purposefully avoiding what I call “guild-based agile” – a process flow that encourages functionally-distinct steps and hand-offs.  I don’t want the engineers to optimize their coding output or designers to optimize their number of deliverables or analysts and testers optimizing their little area of concern.  I know that mini-waterfall makes you feel more productive.  I’ll help you show your work to the world in a way that makes that urge irrelevant.  I want well-rounded creators who build a relationship with the people who use our product.  The number of features added is less important than continuous innovation and deliberate empirical product development.

Now – Let’s challenge my claims:

You don’t need testers – In guild-based agile, where the step each card follows relates to a functional division, testers are the natural last step.  Here’s a flow I’d never use – Requirements, Creative, Estimation, Coding, Testing, Done.  The goal of a push-based workflow is for each step to maximize its own productivity.  For a creative person, this means designing a large batch of screens all at once, iterating on their imperfections, shipping them off, and avoiding distractions from developers who don’t understand the designs.  The same is true for each step in this dysfunctional process. 

The presence of a tester is the symptom of immense process waste.  A collaborative team creates with ideas, imagery, and code simultaneously.  Collective genius around a goal – We will solve pain X for user Y by building Z – is more valuable than individual contribution.  Guild-based agile encourages alienation and destroys creativity.  As the batch size grows, getting things done quickly becomes prioritized over questioning “Are you sure we built the right thing?”

Having every function encouraging each other with real-time feedback, focused on the user, reviewing the working software together, and taking pride in the product is far more effective.

You don’t need estimation – Remember when I said all the cards should be about two days of work or less?  Remember how the card isn’t done until market data is reviewed and the success of the card hypothesis is validated?  You don’t need estimation, because you can simply count the cards.  You can forecast based on cycle time.  From the time we have an actionable hypothesis, how long does it take know if it proven or disproven?  The WIP limit depends on the size of the team and should be empirically adapted.  The moment someone feels they don’t have a real sense of empathy for the user of a story or its unclear if you’ll know whether or not your work is valuable – slow down!

It’s true for every function, no matter how specialized the cross-functional team becomes.  Don’t make more designs once the hypothesis column is full, do marketing and surveys on what you have, walk through each build with the developer to discuss new ideas.  If the validation column is full, don’t code anything else – confirm if the right things are being built before building anything else.  I have a hypothesis, of course, but I’ll share that later.