Agile 101: 3 Tips for Using Agile to Unlock Business Value

bml.png

Agile is not a process – it’s a mindset rooted in continuous learning by observing real world human behavior.

For a long time, software was built using waterfall, a long, sequential process that requires many handoffs between product, design, engineering, and QA.  A project goes from inception to requirement gathering to design to build to test and then deployment. All that could take months, and by the time the software is released, business priorities might have changed, or users might not like what they got.

Agile aims to remedy this by putting software into the hands of users faster and then measuring whether the changes are delivering the expected business outcomes.  If so, great, keep improving on what you have.  If not, no worries – you learned something about why not, and you only invested a few weeks to gain that insight.

Switching from waterfall to Agile isn’t easy.  But here are some tips to keep in mind.

Tip 1: Know the Roles

This is your “squad”:

Product Owner

The person responsible for ensuring the squad is constantly delivering business value through the product. This person often translates and prioritizes ideas from “the business” (CEO, strategy team, sales, marketing, etc) and customers for the squad who is actually producing the software.

Engineering

The folks who do most of the building – focused on how to deliver business value from a technical implementation perspective.

QA

The people who test changes before they go to users.  Testing strategies fall into 2 main categories: manual and automated, with much emphasis on automation as a more scalable/risk-reducing strategy.

Design

These folks translate stories into user journeys/experiences.  Typically they’re sharing their ideas via wireframes (for User Experience or UX designers) or visual comps (for User Interface or UI designers).

Scrum Master

This person’s role is to ensure the squad is efficiently and consistently delivering business value.  He or she will schedule all ceremonies (see below).

Subject Matter Experts

Not required, but sometimes it’s helpful to have SMEs on the squad to answer complex questions (for example, if you operate in a heavily regulated industry, you might want someone from compliance on the squad to approve changes quickly).

Tip #2: Commit to Frequent Production Releases

A key output of the process is shippable software.  It’s important to make always ship to production at the end of a sprint because:

  • Go/no-go meetings to decide whether to ship are painful and time-consuming.  More often than not, you’ll feel like you’re not ready and postpone, never knowing if you’re spending more time on something that’s not even going to deliver the business outcomes you’re expecting it to.  Shipping often lets you get feedback (qualitative or quantitative) from real users and eliminates the time needed for release planning (you always release).
  • The deadline creates a powerful forcing function.  As the sprint end date nears, the squad is forced to make scoping decisions and rally as a team to ensure there’s something to ship.

Most teams use 1, 2 or 3 week sprints to dictate how often they ship to production.

Tip #3: Follow the Ceremonies

There are only 5 meetings that should happen every sprint:

Backlog Grooming

A weekly hour-long session where the top of the backlog is discussed and estimated by the squad.  Prior to this meeting, the product owner should prioritize the backlog such that the top items represent the most meaningful ideas to deliver business value / move the product KPIs.

During the meeting, the product owner should present each ticket, starting with the top of the backlog and the Scrum Master should ask the squad to estimate (I prefer estimating via planning poker because it eliminates any bias in estimates but there are other techniques).  I’ve found asking for an estimate is the best way to force clarifying questions to come up from squad members – things like what users will this impact, what browsers are included, how will we know if we’ve succeeded (tie the story back to a KPI), etc.  Anything to clarify the scope of the story or what needs to be true in order to be successful.

Spring Planning

Assuming the top of your backlog is estimated, sprint planning is where the Scrum Master asks the squad to make a commitment to delivering specific stories/bugs in the next sprint.  Ideally the squad is just determining how much of the top of the backlog they think they can take on, but there might be scenarios

Key questions to ask during this meeting:

  • How much did we take on last sprint?  Did it feel like too much? Too little? Just right?
  • Are there any other factors in this sprint we should consider?  Considerable unknowns with some of the work?  Production support spikes we might anticipate?  Planned squad member vacations?

At the end of the meeting, the commitment should be clear to all, and the sprint should begin.  The product owner may want to communicate the commitment to stakeholders.

Daily Standup

This is a daily 10-15 minute meeting, typically in the morning but as long as it’s the same time every day, any time is fine.  Each squad member should answer the following questions:

  • What did you do yesterday?
  • What are you planning to do today?
  • What’s blocking you from doing what you planned to do today? (for example: I got pulled into a lot of meetings related to some other project at the company, I can’t test because the environment is down, I don’t understand what we’re trying to do, etc.)

Other squad members should listen for blockers in particular, but also items that might require some collaboration (for example: “oh, you’re working on that? I had some ideas, I’ll find you after standup”).  Scrum Masters should be making sure the squad is on track to deliver their sprint commitment (burn down charts are helpful for this) and that there is a game plan to remove any blockers that day.

Showcase

This is typically a 30-60 minute session open to the squad and all stakeholders to see what was shipped that sprint.  Squad members (including technology) should demo the changes, perhaps providing some color commentary or “behind the scenes” on what it took to implement.  This is a great place to test squad communication  – anyone should be able to get up at the showcase and explain the background/rationale for the change, along with demoing it.

After or during this meeting, stakeholders should provide feedback to the product owner. (ex. “looks great”, “wait, I didn’t realize that’s what we were gonna build – tell me more”, etc.).

Retrospective

This is typically a 30 minute meeting for the squad between the showcase and sprint planning.  The outcome of this session is to identify from a process perspective, what went well that sprint and what could be improved.  There are a few ways to do this:

  • Go around the room and ask each squad member what went well and what they would change
  • Ask folks to fill out a short form before this meeting, then identify themes and discuss
  • Ask the team to write down what went well on Post-Its and put them up on a wall.  Then do the same for what could be better and discuss each Post-It afterwards
  • Bring up the sprint burndown chart and discuss whether it looks right (ideally you’re claiming points evenly throughout the sprint – something is wrong if it looks like a cliff where all points are claimed on the last day of the sprint)

I’d recommend switching up the format of this ceremony periodically (not necessarily ever sprint) to keep this meeting fresh.

It’s really tempting to skip these ceremonies because “it feels like a lot of meetings” but if you’re doing them right, they’ll go by fast and you’ll understand the value of them.

How Jobs To Be Done Can Help You Get More Users To Switch To Your Product Or Service

If the concept behind Jobs To Be Done wasn’t real, we’d all drive the exact same car.

Jobs To Be Done (JTBD) is a relatively new framework for thinking about the value of your product.  The ideas is that people hire and fire companies to do a certain job for them, and that there is always an existing solution for doing that job.  Think of it like this, the job we hire a car to do is to get us from point A to B in a reasonable amount of time.  But if that was true, why are there so many makes and models of cars?  Because that’s not the real job to be done by a car – every car can do that.  Maybe for the wealthy, the job is looking good in public (luxury cars) or for parents the job is protecting their kids (safe minivans/SUVs) or for single guys the job is attracting women (sports cars).   JTBD aims to uncover these true motivations.

Here are 3 key differences between JTBD and traditional user research.

1. Recruiting

JTBD suggests talking to people who have hired or fired your product or service within the past 90 days, when the decision is still fresh in their mind.  This narrows down the number of people who will fit the bill, and if you’re a startup with no users yet (or no product), then you’ll have to talk to users who have hired or fired your competitors.  (which is a good way to validate who you’re competing with)

2. The Process of Uncovering Why

A JTBD interview is designed to uncover the story of how the person came to decide to hire or fire a product or service, and how it’s gone since making the decision.  See this template below:

jtbd-timeline.png

The general idea is to build a timeline from when the user first thought about changing solutions, to how she decided on a solution, to how she purchased the new solution, to how it’s going since purchase.

3. The Deliverables

In addition to developing the timeline above, the other outcomes of a JTBD interview will be

  • determining what the job is to be done (ex. for luxury cars, getting around town in style and comfortably, perhaps)
  • understanding the 4 forces that drove the user to make her decision and later evaluate that decision.  Specifically:
screen-shot-2012-10-29-at-7-16-58-pm.png

The idea here is to understand what’s prompting the user to think about changing from her current solution (for example, a pain point with the existing solution or a trusted source introducing an alternate solution), what’s attracting her to the new solution (hopefully yours), what worries her about switching, and what’s preventing her from making the switch?

Using this information can be very powerful, especially when marketing a new product. Just make sure to be explicit about how your product/solution is better than the current solutions people tell you they’re switching from.

Replacing Product Visions with Customer Journey Visions

 Homer Simpson car vision:  The Homer

Homer Simpson car vision: The Homer

Where do you see the product in X years?

The product vision exists to answer this question.  It helps communicate a sense of direction to stakeholders, both internal and external.  It’s often accompanied with mockups that took a lot of time to create.

The Issue with Product Visions

But is asking what the product looks like in 3 years even important?  To me, no way.  Product visions are a self-fulfilling prophecy.  They’re created by product leads who will want to make sure they move the product closer to their vision over time so they won’t look like they (a) don’t know how to predict the future, (b) can’t execute or (c) are bad product managers.  So they iterate towards that vision, regardless of whether it’s the right direction.  At least it’s a direction that stakeholders are familiar with, they think.

An Alternative Vision

So what is a product lead to communicate if not a product vision? To me, the best way to communicate a sense of direction to stakeholders is to help them imagine what the customer’s world will be like if the product is successful.  What do I mean by that?  Let’s look at some imaginary examples:

Amazon

Product Vision
A cross-platform shopping experience that lets customers search, compare and order millions of items by voice.

Customer Journey Vision
Imagine never having to leave your house again to go to the store.  No more parking lots, no more lines at the register.  Imagine ordering items from your sofa and opening your front door an hour later to see them there.

Tesla

Product Vision
A self-driving car with free WiFi that can be charged in less than 15 minutes.

Customer Journey Vision
Imagine being able to check email and read the news while your car drives you to work each morning.  Imagine reducing your carbon footprint and saving money on gas in a luxury, high-tech automobile.

Blue Apron

Product Vision
A flexible subscription, in-home cooking service with a mobile app that uses AI to recommend meals to customers.

Customer Journey Vision
Imagine not having to think about what to make for dinner.  Imagine everything you need to make a gourmet dinner in 30 minutes shows up at your doorstep each week.

The Homer

Product Vision
“Powerful like a gorilla, yet soft and yielding like a Nerf ball.”
A bubble dome car that can hold huge beverages and plays La Cucaracha when you honk.

Customer Journey Vision
Imagine being able to honk many horns when you’re mad.  Imagine being able to shut out screaming kids on road trips with the push of a button.

How to CREATE Experiences that Spur Users to Action

help-your-users-take-action-funnel.png

 

I worked with Dr. Steve Wendel, who is our Head of Behavioral Science.  He literally wrote the book on designing software for behavior change.  In that book he outlines his CREATE frameworkthat suggests there are 5 hurdles you need to overcome to get a user or prospective user to take an action, and that at each hurdle, you’re going to lose a few people (hence the funnel shape).  Let’s take a look at the funnel in greater detail.

Cue

You’ve gotta prompt your user to take the action you want – be it an email, push notification, or ad.  This is the one I think most product development squads forget.  They focus so much on building a great user experience that they forget how and why the user would come to their product in the first place.  (if you build it, they will NOT come)

Reaction

As you may have read in books like Blink, our minds use shortcuts to make instantaneous judgements in response to a cue.  You should be aware of how your audience might react to your cue.  For example, if you’re telling them you have the greatest budgeting app in the world, be aware of what people think about the word “budget” (mostly negative reactions, as it implies work or an unpleasant realization that they’re spending too much).

Evaluation

If you can get past the knee-jerk emotional response, then you have to get past a more rational cost-benefit evaluation.  If you’re asking them to switch to your product, this is the point in time in the Jobs to be Done framework where they might decide whether your product is superior to what they’re using today, and whether the switching costs will be worth it.

Ability

Your audience has to have the ability to take the action you’re asking them to take.  For example, if you send an email asking them to log in to your app and check on some changes but they’re in a cellular dead zone on the subway, they’re not logging in then (and chances are, they’re not going to remember to log in later, unless they open that email again).

Timing

Which brings us to the last step – even if the person can take the action, you have to convince them why NOW is the time to do so.  For example, in my line of work, getting younger employees to save for retirement is hard – there are more immediate financial goals like buying a house or paying off student loans that feel more urgent that something that’s 30 years away.

Here are a couple behavioral techniques that can help create urgency:

  • Scarcity: you might have seen Amazon do this with a message like “only 3 left in stock” under a product’s description.  Or with a limited number of beta invites for an upcoming app launch.
  • Deadlines: you may have seen this on TicketMaster – a clock that counts down saying that the price for those Bieber tickets you’re thinking about buying will only stay locked in for 3 more minutes.  Same idea with limited time offers.

Execution

This one is not on the visual, but the last step is actually taking the action.  This is where you give your user a virtual high five for taking an action that you both wanted her to.

Why Agile and Roadmaps Don't Mix

I’ve worked in Agile for 6 years now, having worked in waterfall at Accenture for 5 years prior to that. I’ve presented dozens of roadmaps. But now I’m on a mission to kill the phrase “roadmap”, at least internally, at work. Why? Because roadmaps and Agile don’t mix. Allow me to explain.

The Visualization

Ever presented a roadmap that looks like this?

roadmap.png


Of course you have. And when you do, your stakeholders see a Gantt chart/project plan. If you’re using agile, you probably used some rough estimation to come up with the timeline. Yet the visualization makes it hard to convey the uncertainty around the timeline. No matter how many asterisks you put on the slide, they will see this as a project plan.

The Expectations

So your stakeholders see this “project plan.” What do they expect? For you to deliver on it! They judge you, your squad, your parents, your value to the company on your ability to “stick to the plan”. But is delivering features “on schedule” really success? No way. High fives for delivering software features on time/on budget should be left in 2002 with waterfall.

What happens when you’re delayed? When great business opportunities present themselves? When you realize you want to iterate more on something based on feedback? You have to update your “project plan”. Bummer. Everyone was really excited about that thing at the end of your roadmap. Clients were expecting it. Senior execs built revenue projections off it. Someone from customer service Tweeted that it’s coming. Now they’re all scrambling to save face. And they hate you, product manager, for not doing your job! 

And you thought it’d be OK to update the roadmap because that’s the point of Agile right?

better Alternatives

There are a few alternatives I prefer to the Gantt chart roadmap:

1. Gantt Chart with Buffer

This is a minor tweak to the "project plan" view but at least have some buffer depicted on the roadmap.  Perhaps some empty months with a dotted box outline and a "?" suggesting that the teams need to reserve time for things like responding to customer feedback, production bugs, and new opportunities.

2. Kanban Style

Kanban boards are used to show the status of different work items (in the roadmap context, those would be research/validation work, design, or development).  You don't have to lose the timeline context on these boards - you can still indicate an ETA for each item so people have a general sense of when it'll be available (I'd use quarters instead of a specific month to provide flexibility).  Here's an example Trello board for Chuckwagon, an imaginary app that saves you time in picking recipes to make at home, grocery shopping and cooking:

Screen Shot 2018-04-12 at 12.21.58 PM.png

A couple things to note:

  • Ideas are being validated before they go into the design/build queue.  In this case, the Group Meal Plan ideas was scrapped because users didn't think their friends and family would want to make the same recipes as them.
  • Once released, there's analysis being done to identify whether a change is improving the KPI it was intended to improve.  In this case, the Waitlist Landing Page improved the acquisition KPI because it's collecting email addresses of potential users but the social sharing feature didn't, because few people ended up sharing the landing page link via Facebook, Twitter or LinkedIn.  By doing this analysis we're able to constantly learn and make sure the focus of the product development squads is on outcomes, not just output.

Microsoft also uses this concept for their public Office365 roadmap, although they don't use the same visual layout:

Screen Shot 2018-04-12 at 12.29.46 PM.png

3. Time Horizons

Here's an example from Slack's platform team that shows items bucketed by near term, mid term and long term, with no specific mention of what those "terms" mean.

Screen Shot 2018-04-12 at 12.32.28 PM.png

 

I like the Kanban style roadmap myself, because it provides a quick view of what's happening in product development but doesn't lose sight of outcomes and learnings.