Category: Lean UX

“Digital Transformation” Beyond the Hype

Leave a comment

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

That’s the juicy part.

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

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

I think that’s a great question in retrospect.

What we are actually transforming is information.

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

It’s that simple. 

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

10 Best Product Innovation Techniques

Leave a comment

Need to get a new app, web, or software product to market?  New to the game?  Here’s a handy Top 10 List of practices I’ve discovered along the way.  Instead of exhaustive explanations, Google any words below that are in bold and you will find a wealth of information.

  1. Live a little: Find a significant problem real people have.  Since this really isn’t a technique, go watch Seth Godin’s TED Talk – The Tribes We Lead
  2. Define a User Persona: Define who has the real problem with enough precision a stranger will understand you -For instance: “Women in their forties who get party planning ideas for their children’s birthday using Pinterest” and NOT just “Moms.”
  3. Is the group big enough to support a business model? Time to make a Lean Canvas and share it with a mentor or colleague you trust will give constructive feedback. Also check out How to use the Lean Canvas for App Planning
  4. Customer Interviews: Listen more.  Go to the place.  How are pains currently dealt with?  What is the inefficient current workaround or ineffective existing alternatives?
  5. Empathy Map: Pick an early adopter. Take their picture if they’ll let you.  That’s your new Hero Image.  Capture what she thinks, feels, sees, etc in the moment when the pain occurs.
  6. Pain-Driven Design Roadmap: The problem you want to solve relates to an overarching process or workflow that your target person already does. You should have witnessed this in all the steps above.  Create a prioritized roadmap of solutions based on the problems.  I use a variation of Lean Process Improvement described   Don’t get too attached to this lightweight plan, your goal is to disprove it.  Whatever you can’t disprove through experimentation gets to stay!
  7. User Story Mapping: Take the first item in your roadmap and break it into features. Put those Epics in the order a typical user will access them.  The break them into the tiniest imaginable User Stories you can.  Draw a line that gets rid of anything that isn’t absolutely necessary.  This is a great and tactical write-up via Atlassian’s blog: Guide to Agile User Story Maps
  8. Establish the One Metric That Matters: This will change over the life of the product. For a brand-new app, this might focus on “engagement” – For example, “How many users make it all the way to sending their first Tweet in Twitter?”  Make sure your MVP makes tracking that metric, as well as A/B testing and cohort analysis, possible.
  9. Scope out your Minimum Viable Product – keep cutting. You need so much less than you think.
  10. Experiment: Establish a baseline, be honest about your assumptions, and test the validity of each hypothesis.  If you don’t know much about delivering innovative products, check out Agile or DevOps and the Lean Startup for thought leaders and great ideas on getting better at innovation.

 

 

Identify Existing Alternatives

Leave a comment

Identify Existing Alternatives

When you’ve identified a pain that is shared by a sufficient group, don’t start solutioning yet!  There is actually another crucial step.  Identify the existing alternatives.  If a pain is already perfectly met, it may not make sense to add that new feature, create that new product, or start a new company.

Understanding Workarounds

With Emphatic, some existing alternatives were Tweeting just a photo of the book with a caption, typing notes or quotes manually while fumbling with the book, and (for the research paper student) Microsoft Word does have a tool to help with your citations.

Each of these cases are examples of a workaround, since none of them really solve the key pains – frustration and wasted time typing notes, citation grey areas, relying on my brain’s “file system” for tracking and relating insights over time.

If you have ever emailed a document to yourself, that was a workaround.  AirDrop is an amazing solution to the specific pain “I want these three photos shared from my iPhone to another device Apple device.”

To find workarounds, you need to take a gemba walk.  Go to the place where the pain occurs.  Observe, ask questions, listen.  The closer you are to the pain you need to solve, especially if it is as critical to you as it is to your customers.  This isn’t all user experience fluff.  The workarounds and nearly-good-enough products you see today are the “Threat of Substitution” part of Porter’s 5 Forces after the new feature/product/business exists.  If you make scissors and someone cannot find them or afford them, tearing the paper is a viable substitute.

Competitor Research

The usability and customer interview part of competitive research is both easier and harder than ever due to the internet.  Where there is pain that is significant and shared by a group of people, there is guaranteed to be a place on the internet where you can observe what has been said, what people advise each other to do, etc.  Don’t fall into the temptation of trusting this as the only insight you need.  You need to get involved in the discussion, ask open questions, and listen (even on an internet forum).

As it turns out, Emphatic does have a competitor.  Although I had searched for a direct solution to my pains and found nothing, this week while searching for a workaround I found Quotle.  This is very exciting.  You see, Quotle is exactly what I had initially thought I’d build to solve my pain before I read Rework and Running Lean. It is an OCR scanner for paper books that looks like Instagram. 

I had envisioned artistry and community and got a technical proof of concept. 

Unfortunately, that’s the disconnect that accumulates into a product/market misfit as a demand to alleviate a pain moves from the user through the stakeholders and Product Owners to the development team and back to the user.  More on that later:  in the mean time, download Quotle, try it out, and send me what works and what doesn’t work about it.  I’ll be asking the same of people at the library.

How to Validate the Problem Statement

Leave a comment

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.

That’s Solutioning!

Leave a comment

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 process, I 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

Leave a comment

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.

Agile Priorities: Keeping Documentation Lean

2 Comments

Agile Transformation

If you want your agile transformation to fail, allow the development team and all supporting functional teams to focus on the waterfall deliverables and dependencies to which they are accustomed.

In “Fixed Budget, Fixed Scope? Be Agile Anyway.”  I argued that agilists, especially newcomers, must understand that the Agile Manifesto is a statement of priorities – at times, tools and interactions, comprehensive documentation, contract negotiation, and following a plan are all part of the product that is created by the process that keeps your teams in business.

In software development, this is the exception rather than the rule.  

For “core” Scrum, the proverbial “one-team-in-a-garage”, this is pretty simple.  Everyone you need is in one room.  When scaled, a delivery organization is often “compound-complex” – it is “compound” when two or more independent functional knowledge areas must cooperate and “complex” when at least one knowledge area has dependency on another (these aren’t fancy concepts, just basic grammar).  The moment a delivery process moves beyond one-team-in-a-garage Scrum, there is compound-complex value stream:

The web team and mobile team will build a user-facing experience, while the middle tier team provides RESTful services, only after sales executes the contract and the Product Owner builds the backlog; meanwhile, UX, BA’s, and QA’s will provide documentation.

In this value stream, the “Wildly Important Thing” is the software that a user will consume in order to drive revenue.

Because Communities of Practice have their own traditions and methods of proving extrinsic value, shifting their priorities is much more difficult at scale.  Plan to change the physical distribution in order to overcome the functional “clumping” that Waterfall encouraged.  Moreover, agile transformation will require finding and eliminating the agency dilemma of managers who built their kingdoms around waterfall values.

Resolving Wasted Effort

If agile at scale has not improved company-wide quality and velocity, it is likely due to waste in the overarching process – you must remove any activity that does not drive value creation that a user consumes and the business will capture.  This is the central rule of the User Story – if it does not make a difference to the user (and occasionally the owner) it is wasted energy, a distraction.  You find this clearly stated, often, in Jeff Sutherland‘s various descriptions of “Bad Scrum” – without delivering working software that matters to the user an organization will be stuck in a self-reinforcing cycle of inefficiency and ineffectiveness.  No one is making a difference in the world, selfishness increases, velocity never improves, no software is delivered.

For a compound-complex process to stay agile, the Lean principles of Just-in-Time and Just-Enough to must be applied to all forms of documentation – business rules, persona descriptions, wireframes, UI designs, sliced assets,  value mapping, technical constraints, market conditions – all are a means to pleasing the user, not the end goal (software that a user values).  The User Story is the cornerstone of efficient, effective product delivery because it is a “reminder of a conversation” about a result from which a user will derive value.  For some teams, a set of wireframes can all but replace “cards”.  An image of a login screen is sufficient to drive the conversations a team needs to have about client-side validation, security requirements, and authentication method.

The Product is Everyone’s Deliverable

To move to next-level agile, at scale, an organization will need to blur its understanding of “business planning”, “requirements documentation”, and “UX Design”.  While there may be a need for full, distinct teams of experts at each of these disciplines, these approaches to defining what the software will be should converge on a single goal – building great software.  A popular article on Lean for UX, Lean UX: Getting Out Of The Deliverables Business leads with this statement:

Wireframes, site maps, flow diagrams, content inventories, taxonomies, mockups […] crystallized the value that the UX discipline brought to an organization. Over time, though, this deliverables-heavy process has put UX designers in the deliverables business — measured and compensated for the depth and breadth of their deliverables instead of the quality and success of the experiences they design. Designers have become documentation subject matter experts, known for the quality of the documents they create instead of the end-state experiences being designed and developed.

Having started my career as a Business Analyst, this is painfully resonant.  It is unfortunately easy for management move from training “the tools of the trade” – spreadsheets, slide decks, requirements documentation, technical specifications – to judging the tools independent of the software to be delivered.

Here are a few rules to follow to get UX, UI, and BA’s out of the deliverable business and into the well-formed team:

  1. Never say “final sign-off” regarding artifacts – whether working for internal stakeholders or external clients, if software is the deliverable, it is the only item requiring sign-off.  Every other artifact is is a tool for getting working software in the hands of users.  Make sure you are “responding to change” at the request of real users of working software – no amount of planning or documentation will survive contact with the user.
  2. UX/UI Refinement should mirror Backlog Decomposition – Prioritizing working software does not mean there is no product roadmap, it does mean that time and resources should only be invested in the software most likely to be built in the near future.  This starts as a process diagram of all possible Epics that could be built, and how the user gets to each of these features.  The upcoming 2 to 3 features should have relatively actionable wireframes.  The team should feel certain about the UI design of the current and next sprint.
  3. Create paradigms, not screens – the most important expectation to break is the annotated UI composition per screen.  Some screens absolutely benefit, many do not.  A well-formed team should have enough shared understanding of technical constraints, design paradigm, and business context that a conversation is sufficient to drive the whiteboard-to-working software process.  Wherever possible, establish a paradigm for a product is intuitive to build.  If it isn’t intuitive to the developer without extensive documentation, how likely is is it the user will find it intuitive?
  4. Document releases proactively, but in accordance with your level of certainty – If there is a product that will require knowledge hand-off, a support guide, or other formal documentation, maintain the tension between what makes sense to proactively document (so you don’t spend a full week post-release) while wary of what will change (likely anything more than a sprint in the future).

Following these rules, the software development process in an at-scale, compound-complex organization can focus on the user enjoying a working product.  Aligning vision and expectations along the agile priorities will remove fear of failure or criticism, increase team velocity, and result in the best possible products.  Then, your team, business, and enterprise can pursue kaizen – and the real magic can happen.

RSVP Now: ScrumAlliance Chicago Group Meeting May 12th

Scrum Chicago

FREEDOM – Using Scrum to Un-Impede Your FULL Potential

In parallel with this year’s Global Scrum Gathering in Phoenix, at our May User Group Meeting we will discuss “Freedom” and creating an environment that maximizes potential for yourself and others.

Next-iteration Scrum drives freedom from:
– The tyranny of the urgent
– Fear of making mistakes
– Business as usual
– Process rigidity

With an eye to the past, we will look at how to optimize current environments and adopt a forward-thinking approach to Scrum.

Eventbrite - FREEDOM - Using Scrum to Un-Impede Your FULL Potential

The one outcome you MUST achieve in Sprint Zero

2 Comments

Scrum, Lean UX, & Extreme Programming Sprint Zero:

The length of sprint “zero” for a new product and the (debatable) necessity of common sprint zero expected outcomes may vary, but there is one task that must be completed, or the full benefit of your Scrum and XP practices will suffer:

Complete setup of the repository and automated build server – and send a build.

This is a critical step in establishing team transparency and Product Owner accountability – frequently delivered builds, even with mid-sprint potentially un-shippable product increments – are the exclusive insight of the PO into the progress of the product.  It is the Product Owner’s responsibility to determine the worthiness of the stories delivered and whether additional iteration is necessary; delaying this feedback loop robs the PO of crucial insights and undermines the team’s ability to gain fast and honest feedback.

The longer the team waits to send the first build, whether due to a still-emerging architecture or lack of finalized copy and assets, the more perfection becomes the enemy of the good (or in this case, the deliverable).  Scrum requires transparency and accountability:  remove dysfunctional Hawthorne Effect as early as possible by setting the precedent – from Sprint Zero – that the build is delivered to QA and the Product Owner early and often.